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

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

Не понял.

с компа 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

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

в сети 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 не видят друг друга.

в сети 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

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

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

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

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

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

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

нет, сеть 8.0/пингуется только с B

А traceroute на каком сдыхает?

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

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

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

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

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

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

traceroute сдыхет именно на B

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

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

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

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

Всех отметившихся в треде попрошу заглянуть и сюда когда будет время

Лучший способ подготовиться к собеседованию по Networking

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

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

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

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

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

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

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

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

Мою по проверки узла, я попробую более обще изложить: 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         

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

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

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

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

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

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

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

Это мало кто знает, но вместо того чтобы вкуривать в таблицу маршрутизации, есть хорошая команда, чтобы посмотреть куда пойдет запрос на соответствующий 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

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

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

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