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

Прежде всего, хочу сказать, что я НЕ инженер по сетям, и мои знания в области сетей довольно ограничены, и что бы то ни было, это в основном теория и меньше практика – так что, пожалуйста, простите меня, если вопрос глупый / тривиальный или если вся настройка ужасно и мучительно неправильно сделана.

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

Так что в основном два роутера цепочкой (или коммутатором), где Router01 подключен к модему и назначает IP-адреса DHCP клиентам, а Router02 фактически является клиентом, получающим IP от Router01 как [ 10.0.0.110 ], при этом имея собственный DHCP, назначающий адреса 192.168.1.xxx другим клиентам, и собственный LAN IP [ 192.168.1.199 ] и шлюз как Router01 с [ 10.0.0.1 ]

Изначальной причиной для такой настройки с двумя роутерами является то, что Router02 имеет клиент VPN – который не должен быть доступным для клиентов сети [ 10.0.0.xxx ] Router01, это значит, что только клиенты Router02 должны иметь доступ к этому VPN соединению.

Фактически, эта настройка несколько хорошо работает большую часть времени для большинства целей (за исключением обычного совместного использования Windows / сети / DNS и разрешения имен хостов, что всегда является проблемой). НО – для меня есть одна проблема, которая сводит меня с ума – это то, что я могу пинговать / получать доступ к клиентам и машинам от Router02 — к –> Router01 – но НЕ наоборот.

Это работает в одном направлении и не работает в другом.

Не только это не работает – если я нахожусь на 10.0.0.xxx и пытаюсь пинговать 192.168.1.199, который [ Router02 ], я вдруг вижу, что ответ на пинг приходит от 192.168.1.2 (всегда, независимо от того, какой адрес я пингую), который, насколько я знаю, является адресом, который ДАЖЕ НЕ СУЩЕСТВУЕТ на Route02 не DHCP (вне диапазона) и не иначе.
Если я подключаюсь к Router02 – никаких проблем я могу получить доступ ко всем сервисам, серверам NAS, принтерам, совместному использованию, виртуальным машинам, устройствам IoT и т.д. на 10.0.0.xxx.

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

Тогда я подумал, что могу добавить статическую маршрутизацию – на любом из роутеров, а также на обоих – но это тоже не помогло (Фактически, в нескольких пробах и ошибках я действительно создал несколько бесконечных циклов, которые почти замкнули маршрутизаторы, и только жесткий сброс FW и перепрошивка NVram помогли)

Для справки – таблица маршрутизации на Router01 сейчас такая :

Destination     Gateway         Genmask         Flags    Metric Ref    Use Type Iface
100.72.0.1      *               255.255.255.255 UH       0      0        0 WAN0 ppp0
10.0.0.0        *               255.255.255.0   U        0      0        0 LAN  br0
192.168.1.0     *               255.255.255.0   U        0      0        0 MAN0 eth0
192.168.1.0     10.0.0.110      255.255.255.0   UG       1      0        0 LAN  br0
default         100.72.0.1      0.0.0.0         UG       0      0        0 WAN0 ppp0
default         192.168.1.1     0.0.0.0         UG       1      0        0 MAN0 eth0

А на Router02 :

Destination LAN NET     Subnet Mask         Gateway         Flags   Metric      Interface
default                 128.0.0.0           198.18.64.1     UG          0           tun0
default                 0.0.0.0             10.0.0.1        UG          0           WAN
1.1.1.2                 255.255.255.255     198.18.64.1     UGH         0           un0 // <-- Если вы действительно читаете это, вы, вероятно, сейчас чешете голову и думаете, почему сетевая маска 255.255.255.255 (/32) - ну да, я тоже.
10.0.0.0                255.255.255.0       *               U           0           WAN
10.0.0.1                255.255.255.255     10.0.0.1        UGH         0           WAN
88.216.2.165            255.255.255.255     10.0.0.1        UGH         0           WAN // <-- Не имею представления, что это и почему появилось - вероятно, связано с VPN
128.0.0.0               128.0.0.0           198.18.64.1     UG          0           tun0
192.168.1.0             255.255.255.0       *               U           0       LAN & WLAN
198.18.64.0             255.255.240.0       *               U               0       tun0 WAN // <-- Не имею представления, что это и почему появилось - вероятно, связано с VPN
    

Я также прочитал несколько вопросов на Network Engineering SE, которые могут быть связаны с настройками двух роутеров, например, этот или этот или этот и несколько других – но честно говоря, мои знания в области сетей настолько минимальны, что это не очень помогло мне понять проблему, и более того – кажется, что оборудование класса потребителя там не обсуждают [ ?? ] и меня перенаправили сюда.

Так что, в основном, я готов сдаться на этой настройке и просто мириться с частыми, например, каждые два часа изменением соединения Wi-Fi, но в качестве последнего средства я подумал, возможно кто-то здесь сможет мне помочь.

если нужно дополнительная информация, я с радостью добавлю/отредактирую, что необходимо.
Заранее спасибо

Это работает в одном направлении и не работает в другом.

“Работает в одном направлении” часто вызывается тем, что на Router02 все еще включен NAT, который маскирует (SNAT-ing) все исходящие пакеты так, чтобы они казались поступающими от 10.0.0.110, а не от фактических адресов 192.168.1.x.

Это то, что делает Router02 по умолчанию, так как его прошивка предполагает, что его интерфейс ‘WAN’ будет подключен непосредственно к интернету.

Таким образом, искомое устройство 10.0.0.y никогда не видит адресов 192.168.1.x – оно получает запрос на пинг и отправляет ответ на 10.0.0.110, что является трафиком одной подсети – и пакеты этой же подсети вообще обходят Router01, его таблица маршрутизации даже не рассматривается.

Таким образом, NAT скрывает проблемы маршрутизации (в некотором смысле, это именно то, для чего он был разработан). С отключенным NAT это не работало бы ни в одном направлении, так как вы бы могли отправлять пакеты, но не получать ответы. (Но я думаю, что это хорошая идея отключить NAT в любом случае, чтобы получать более последовательные результаты.)

Другая причина “Работает в одном направлении” — это брандмауэр Router02. Опять же, прошивка Router02 была сделана с предположением, что его интерфейс ‘WAN’ будет подключен к интернету, и соответственно применяет строгие правила брандмауэра, блокирующие все неожиданные входящие пакеты: оно допускает входящие ответы только когда они соответствуют “активному потоку”, блокируя “новые” запросы.

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

Ваш Router01 имеет два маршрута, которые соответствуют другой сети:

Destination     Gateway         Genmask         Flags    Metric Ref    Use Type Iface
192.168.1.0     *               255.255.255.0   U        0      0        0 MAN0 eth0
192.168.1.0     10.0.0.110      255.255.255.0   UG       1      0        0 LAN  br0

Оба имеют одинаковую сетевую маску / длину префикса (одинаково специфичны), поэтому используется тот, у которого ниже ‘метрика’. В вашем случае, маршрут с наименьшей метрикой ведет не к Router02, а к вашему модему на eth0. 2-й маршрут (который вы добавили) правильный, но из-за более высокой метрики остается неиспользуемым.

Я предполагаю, что под Тип: MAN0 прошивка ASUS-WRT подразумевает “сеть управления” – по крайней мере, это имеет чуть больше смысла в данном контексте, чем “сеть городского района”.

(Аналогично, по какой-то причине у вас есть две дефолтные маршруты через ppp0 и eth0, хотя у eth0 более высокая метрика и он остается неиспользуемым, но я полагаю, что он вообще не должен быть там – если вы используете PPPoE, то у вас должен быть только дефолтный маршрут через интерфейс PPPoE туннеля, а не напрямую на Ethernet.)

Не только это не работает – если я нахожусь на 10.0.0.xxx и пытаюсь пинговать 192.168.1.199, который [ Router02 ] я вдруг вижу, что ответ на пинг приходит от 192.168.1.2 (всегда, независимо от того, какой адрес я пингую), который, насколько я знаю, является адресом, который НЕ СОЩЕСТВУЕТ на Route02

Скорее всего, 192.168.1.2 это ваш роутер ASUS. Он считает 192.168.1.0/24 локальной подсетью на интерфейсе eth0 (соответствующий маршрут не имеет ‘шлюза’), поэтому он непосредственно делает ARP-запросы для запрашиваемого 192.168.1.199 – и когда не получает ARP-ответ, его ОС дает фальшивый ICMP “Host Unreachable” программе ping.

Между тем 192.168.1.1, вероятно, ваш модем.

А на Router02 :

Router02 не нужен никакой статической маршрутизации, поскольку у него уже есть интерфейс, непосредственно подключенный к подсети 10.0.0.0/24 (интерфейс ‘WAN’), и, следовательно, автоматически имеется маршрут 10.0.0.0/24.

интересно, почему сетевая маска 255.255.255.255 (/32)

Это довольно обычный маршрут для этого одного IP-адреса. Я полагаю, что его настроил ваш VPN для принудительного направления туда DNS-трафика.

Маски маршрутов не совсем то же самое, что маски подсетей: маршрут может охватывать несколько подсетей, или половину подсети, или что угодно от ‘древнего маршрута’ /0 до ‘одного адреса’ /32. (Обычное правило “зарезервировано первое и последнее” не применимо к маршрутам; оно применяется только к подсетям, назначенным интерфейсу.)

88.216.2.165

Это маршрут к вашему VPN-серверу. Поскольку ваш VPN-клиент устанавливает новый ‘дефолтный’ маршрут (или два маршрута /1, но та же идея), обычно это также включает трафик к собственному IP-адресу VPN-сервера – и это привело бы к бесконечному циклу. Поэтому программное обеспечение VPN-клиента добавляет специальное исключение для адреса VPN-сервера, маршрутизируя его через исходный шлюз. Снова он имеет сетевую маску /32, потому что нужно охватывать только этот один адрес.