LINUX.ORG.RU
ФорумAdmin

Соединять сети между собой, каков алгоритм устранения неисправностей?

 , , , tcptraceroute


1

3

При настройки маршрутизации между сетями постоянно сталкиваюсь с тем, что это по началу не работает и я начинаю, проверять каждый узел:

1. cat /proc/sys/net/ipv4/ip_forward должно давать 1

2. таблица маршрутизации должна содержать

2.1. для сетей источника и приемника свой gw (для проверки команда route)

2.2. ip адрес gw должен быть доступен для узла, т.е. есть работающая сетевая карта в той подсети и маска подсети позволяет. (для проверки команда ifconfig)

3. отключаю firewall на узлах, что бы разобраться после.

Далее моя система иссякает, проблемы остаются.

Для проверки результата использую: ping, tcptraceroute, tcpdump.

Пытаясь каждый раз систематизировать свои знания, я очередной раз наталкиваюсь на то, что в следующий раз это не применимо.

Может поделитесь системой, описываю конкретную ситуацию: не проходит через узел, который находится в нескольких сетях, вот его route:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         WL-20BF85E6F780 0.0.0.0         UG    0      0        0 eth0
10.6.0.0        *               255.255.255.0   U     0      0        0 tun0
10.7.0.0        *               255.255.255.0   U     0      0        0 tun2
10.8.0.0        *               255.255.255.0   U     0      0        0 tun1
172.20.5.0      10.7.0.1        255.255.255.0   UG    0      0        0 tun2
192.168.0.0     10.6.0.1        255.255.255.0   UG    0      0        0 tun0
192.168.3.0     *               255.255.255.0   U     1      0        0 eth0
192.168.8.0     10.8.0.1        255.255.255.0   UG    0      0        0 tun1

с компа 192.168.0.141 (соединенная через сеть 10.6.0.0) видна вся сеть 192.168.3.0, но не видна 192.168.8.0 (соединенная через сеть 10.8.0.0)

Подскажите, ваш план действий в этой ситуации?



Последнее исправление: kpush (всего исправлений: 1)

с компа 192.168.0.141 (соединенная через сеть 10.6.0.0) видна вся сеть 192.168.3.0, но не видна 192.168.8.0 (соединенная через сеть 10.8.0.0)

Не понял.

dada ★★★★★
()

с компа 192.168.0.141 (соединенная через сеть 10.6.0.0) видна вся сеть 192.168.3.0, но не видна 192.168.8.0 (соединенная через сеть 10.8.0.0)

Нарисуйте схему. Типа таких: http://docs.oracle.com/cd/E19082-01/819-3000/images/ipplan.fig146.gif http://robertlathanh.com/wp-content/uploads/2009/09/2_subnets_2_segments.png http://www.shorewall.net/images/Network2009d.png

Визуализация топологии сети (если не можете представить ее в голове) сильно помогает.

strangeman ★★★★
()
Последнее исправление: strangeman (всего исправлений: 1)
Ответ на: комментарий от dada

в сети 192.168.0.0/24 есть шлюз (назовем его «8, 6, 7») которому доступна сеть 10.6.0.0/24 в этой сети есть еще один шлюз (назовем его 10.6.0.1), которому доступна сеть 192.168.3.0/24 c этим все нормально работает, как часы.

так же в сети 192.168.8.0/24 есть шлюз (это тот же «8, 6, 7») которому доступна сеть 10.8.0.0/24 в этой сети есть еще один шлюз (назовем его 10.8.0.1) которому доступна сеть 192.168.3.0/24 c этим то же все нормально работает.

теперь мне понадобилось, что бы компы с сети 192.168.0.0/24 видели и сеть 192.168.8.0/24 я прописал на шлюзах:

1. на 10.6.0.1 добавил путь к сетям 10.8.0.0/24 и 192.168.8.0/24

2. на 10.8.0.1 добавил путь к сетям 10.6.0.0/24 и 192.168.0.0/24

но никакие компы из сетей 192.168.0.0/24 и 192.168.8.0/24 не видят друг друга.

kpush
() автор топика
Ответ на: комментарий от kpush

в сети 192.168.0.0/24 есть шлюз (назовем его «8, 6, 7»)

так же в сети 192.168.8.0/24 есть шлюз (это тот же «8, 6, 7»)

понадобилось, что бы компы с сети 192.168.0.0/24 видели и сеть 192.168.8.0/24

Зачем идти лесом если по вашим словам шлюз «8, 6, 7» и так вхож в обе интересующие сети 192.168.0.0/24 и 192.168.8.0/24

vxzvxz ★★★
()
Ответ на: комментарий от vxzvxz

Зачем идти лесом если по вашим словам шлюз «8, 6, 7» и так вхож в обе интересующие сети 192.168.0.0/24 и 192.168.8.0/24

да я не хочу, но получается. Вхож он не на прямую, а через сети 10.6.0.0/24 и 10.8.0.0/24 соответственно.

kpush
() автор топика

Слева направо:

сеть 192.168.0
роутер А (с адресом .1 в следующей сети)
сеть 10.6.0
роутер В
сеть 10.8.0
роутер С (с адресом .1 в предыдущей сети)
сеть 192.168.8

Пингуется ли сеть 192.168.8 с роутера А?

frob ★★★★★
()
Ответ на: комментарий от kpush

Если везде отключён FW и работает IP forward, то либо
- на А проблема с маршрутом к 192.168.8,
- на С проблема с маршрутом к 10.6.0,
- и то и другое

Покажи routes на А и С.

frob ★★★★★
()
Последнее исправление: frob (всего исправлений: 2)
Ответ на: комментарий от frob

в общем то, мне хотелось бы узнать, правильная ли методика и кто как поступает.

В этом конкретном случае, я уверен, что заработает все. Вот таблици:

A

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.3.0     10.6.0.15       255.255.255.0   UG    0      0        0 tun0
10.6.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
10.8.0.0        10.6.0.15       255.255.255.0   UG    0      0        0 tun0
192.168.8.0     10.6.0.15       255.255.255.0   UG    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
C
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.3.0     10.8.0.12       255.255.255.0   UG    0      0        0 tun0
10.6.0.0        10.8.0.12       255.255.255.0   UG    0      0        0 tun0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.0.0     10.8.0.12       255.255.255.0   UG    0      0        0 tun0
192.168.8.0     0.0.0.0         255.255.255.0   U     0      0        0 br0

kpush
() автор топика
Ответ на: комментарий от kpush

в общем то, мне хотелось бы узнать, правильная ли методика и кто как поступает.

Я сейчас скажу одну вещь... Только не обижайтесь. Правильная методика включает в себя чтение учебника по маршрутизации в сетях TCP/IP и получение упорядоченных базовых знаний. После этого всё становится просто (если речь только про маршрутизацию, а не про какой-нибудь недонастроенный iptables в середине).

Cyril ★★
()
Ответ на: комментарий от Cyril

Правильная методика включает в себя чтение учебника по маршрутизации в сетях TCP/IP и получение упорядоченных базовых знаний. После этого всё становится просто

это понятно, хотелось бы поделится методикой обнаружения неисправностей. Я свою методику привел, она работает до некоторых моментов. А как поступаете Вы? не бросаетесь же снова перечитывать учебник для упрощения?

kpush
() автор топика
Ответ на: комментарий от Cyril

В этих учебниках написать использовать RIP/OSPF и не совать свои грязные ручки в таблицу маршрутов.

Вот только не написано как

vertexua ★★★★★
()
Ответ на: комментарий от kpush

Нет. Я просто знаю, где какие сети и маршруты должны быть прописаны и разбираюсь с узлом, на котором теряются данные - проверяя, всё ли и без ошибок ли прописано.

Cyril ★★
()
Ответ на: комментарий от vertexua

Это неправильные учебники. В правильных не советуют совать везде RIP или OSPF - а в тех случаях, когда советуют, описывают, как именно (давая предварительно те же базовые знания и по RIP, и по OSPF - и даже по другим протоколам иногда).

Cyril ★★
()
Ответ на: комментарий от kpush

Если адреса В — 10.6.0.15 и 10.8.0.12, значит с маршрутами всё в порядке. Посмотри в iptables.

Методика простая:
- формулируем проблему
- рисуем диаграмму
- выдвигаем гипотезу о причине сбоя
- предлагаем процедуру проверки гипотезы с описанием ожидаемых результатов
- проверяем и в зависимости от результата исправляем или возвращаемся назад к выдвижению новой гипотезы, с учётом вновь открывшихся обстоятельств.

frob ★★★★★
()
Ответ на: комментарий от frob

Методика простая:
- формулируем проблему
- рисуем диаграмму
- выдвигаем гипотезу о причине сбоя
- предлагаем процедуру проверки гипотезы с описанием ожидаемых результатов
- проверяем и в зависимости от результата исправляем или возвращаемся назад к выдвижению новой гипотезы, с учётом вновь открывшихся обстоятельств.

методика, хорошо описана, она очень понятна и проста я везде именно ее применяю хотелось в сторону сетей, наверное просто раскрыть какие гепотезы в какой последовательности строятся.

Мою по проверки узла, я попробую более обще изложить: 1. проверить включен ли форвардинг на уровне ядра 2. проверить какие сетевые интерфейсы и с какими масками есть в системе. 3. проверить таблицу маршрутизации, правильно ли (с учетом п.2) 4. отрубить на время firewall, что бы разобраться с ним, отдельно.

sudo iptables -nvL
Chain INPUT (policy ACCEPT 212M packets, 46G bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 573M packets, 404G bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 362M packets, 397G bytes)
 pkts bytes target     prot opt in     out     source               destination         
kpush
() автор топика
Ответ на: комментарий от kpush

раскрыть какие гепотезы в какой последовательности строятся.

Вот тут как раз и начинается «требует жертв».

Есть разница между «не пингуется», «пинги проходят через раз», «теряется 5-15% ответов», «каждое утро в 7 утра на 5 минут пропадает связь» или, как у моего клиента, «на каждый пинг приходит 5 одинаковых ответов».

frob ★★★★★
()
Ответ на: комментарий от frob

Есть разница между «не пингуется», «пинги проходят через раз», «теряется 5-15% ответов», «каждое утро в 7 утра на 5 минут пропадает связь» или, как у моего клиента, «на каждый пинг приходит 5 одинаковых ответов».

обычно не пингуется и все.

Мой пример заработал, проблема была в таблице route но C роутере. Там пути появились, в тот момент, когда я сюда их копировал. Т.е. traceroute с А на С затыкался именно из за этого. Спасибо, всем принявшим участие в обсуждении.

kpush
() автор топика

Любой мало-мальски серьёзный проект должен быть обеспечен документацией по своей сетевой инфраструктуре. Если смотреть по семиуровневой модели OSI, нужно всё: от физического до прикладного уровня. В TCP/IP некоторые уровни — не OSI, впрочем.

Infra_HDC ★★★★★
()

Это мало кто знает, но вместо того чтобы вкуривать в таблицу маршрутизации, есть хорошая команда, чтобы посмотреть куда пойдет запрос на соответствующий ip адрес.

# ip route get 10.94.200.2
10.94.200.2 dev eth1.457  src 10.94.200.1 
    cache  mtu 1500 advmss 1460 hoplimit 64
Yur4eg ★★
()

Если вам знаком tcpdump, то, ИМХО, логичнее всего начинать с него. Если нет прохождения пакетов (ping'ов), то сначала определяете интерфейсы, через которые этот пакет должен пройти, запускаете на каждый интерфейс по tcpdump'у с правильным фильтром (чтобы дампились только нужные пакеты) и смотрите. Так можно сразу найти проблемный узел сети.

А отключение firewall на маршрутизаторе дважды плохая идея. С одной стороны безопасность, а с другой, прохождение пакетов может быть завязано на их маркировку (-j MARK) и без правил в iptables пакет может пойти в неправильную таблицу маршрутизации или полосу пропускания (traffic shaping).

Если есть подозрения в сторону правил iptables, то можно для тестовых пакетов (ping'ов) создать "-j TRACE" правило и смотреть логи, или добавить в начало FORWARD и POSTROUTING правило "-j ACCEPT" с указанием "-s", "-d" и "-p" и потом смотреть счётчики этого правила.

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.