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

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

У меня есть две сети и маршрутизаторы (обе на Advanced Tomato от Shibby), организованные следующим образом:

  1. Резервная сеть маршрутизатора (192.168.1.1/24)
    1. WAN-Xfinity
    2. LAN - небольшое количество клиентов. Важно, что основной сетевой маршрутизатор является клиентом в этой сети.
    3. Сетевые интерфейсы
      1. br0 - локальный. Маршрутизатор имеет IP 192.168.1.1
      2. eth0 - Xfinity
      3. eth2 - Беспроводная сеть - это сеть, к которой резервная сеть подключена как беспроводной клиент.
  2. Основная сеть маршрутизатора (192.168.2.1/24)
    1. WAN - оптоволокно
    2. LAN - Подключен к точкам доступа Mesh-сети. Почти все устройства в доме подключены через эти точки доступа Mesh-сети к основной сети. Особенно важны мой локальный NAS и хосты служб, например Plex, принтеры и игровой рабочий стол.
    3. Балансировка нагрузки. Этот маршрутизатор является «беспроводным клиентом» на резервном сетевом маршрутизаторе и имеет функцию Multi-WAN с включенной балансировкой нагрузки.
    4. Сетевые интерфейсы
      1. br0 - локальный. Маршрутизатор имеет IP 192.168.2.1
      2. eth0 - Оптоволокно
      3. eth2 - клиент в резервной сети с IP 192.168.1.81

Как это работает: Пока клиент находится в основной сети, система работает хорошо. Они могут получить доступ к NAS, принтеру и т. д. Они также могут получить доступ и пинговать любого клиента в резервной сети.

Проблема:

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

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

  1. Я попробовал добавить следующую переадресацию iptables в резервную сеть
    iptables -I INPUT -i br0 -j ACCEPT
    iptables -I FORWARD -i eth2 -d 192.168.2.0/24 -j ACCEPT
    iptables -I FORWARD -i br0 -d 10.9.8.0/24 -j ACCEPT
  1. Включение пересылки IP-пакетов в КАК резервной, так и в основной сетях. Запускecho 1 > /proc/sys/net/ipv4/ip_forward

  2. Добавить IP-маршрут ip route add 192.168.2.0/24 via 192.168.1.81

Проблемы

К сожалению, это не работает. Когда я пытаюсь пинговать 192.168.2.1 с моего резервного сетевого маршрутизатора, я получаю ошибку - Unable to ping From 192.168.1.1 icmp_seq=1 Redirect Host (New nexthop 192.168.1.81).

Думаю, я накосячил с iptables. Я не совсем понимаю, что я там делаю. Если кто-то может помочь, буду очень признателен.

решение1

Я попробовал добавить следующую переадресацию iptables в резервную сеть

Правила FORWARD, похоже, не соответствуют описанию вашей сети:

  • Пакеты, поступающие на eth2 резервного маршрутизатора (т.е. поступающие с основного маршрутизатора), будут иметь 192.168.2.0/24 в качестве своегоисточник,не пункт назначения; и аналогично, пакеты, отправленные на 192.168.2.0/24, будут выходить из eth2, а не входить в него (т.е. если это -d, то так и должно быть -o eth2).

    Если визуализировать пакеты в обоих направлениях, то должно получиться что-то вроде этого:

    Адрес источника адрес доставки Интерфейс ввода Интерфейс вывода
    192.168.1.0/24 192.168.2.0/24 →br0 eth2→
    192.168.2.0/24 192.168.1.0/24 →eth2 br0→

    Вы можете добавлять правила только с помощью -sи -dили с помощью интерфейсов и т. д. Я бы посоветовал посмотреть на счетчики пакетов в списке правил iptables, чтобы проверить, выполняются ли правила.совпалолюбыми пакетами.

  • Сеть 10.9.8.0/24, похоже, нигде не задействована.

  • Правило INPUT не имеет значения, поскольку ни один из ваших пакетов не является «входом» для маршрутизатора — это имело бы место только в том случае, если бы вы пинговали маршрутизаторсобственныйадрес.

    Например, если вы пингуете основной маршрутизатор, это будет "forward" для резервного маршрутизатора и "input" для основного маршрутизатора. Но если вы пингуете одного клиента с другого, это классифицируется как "forward" для всех задействованных маршрутизаторов (и "input" только для самого клиента).

Хотя это необходимо, это обычно должно быть шагом после добавления маршрутов, а не до. Всегда помните, что IPtables контролирует только то, являются ли пакетыдопустимыйбыть направленным в определенном направлении, но не контролируетгдеих следует пересылать — сначала это решает таблица маршрутизации, а затем вы настраиваете правила iptables FORWARD в соответствии с этим.

Включение пересылки IP-пакетов в КАК резервной, так и в основной сетях путем запуска echo 1 > /proc/sys/net/ipv4/ip_forward

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

При попытке выполнить ping-запрос на 192.168.2.1 с моего резервного сетевого маршрутизатора возникает ошибка: «Невозможно выполнить ping с 192.168.1.1 icmp_seq=1 Redirect Host (New nexthop 192.168.1.81)».

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

Фактическая ошибка заключается в отсутствии ответов, что, скорее всего, вызвано либо «резервным» маршрутизатором,илиправила брандмауэра «главного» маршрутизатора блокируют пакеты в этом направлении.

Используйте tcpdump ( tcpdump -n -i ... "icmp"), чтобы проверить, куда приходят и куда уходят пакеты:

  • Достигают ли ониосновнойИнтерфейс eth2 маршрутизатора?
    • Если это не так, значит резервный маршрутизатор не пересылает их (возможно, неверны iptables или таблица маршрутизации).
    • Если да, то достигают ли они также интерфейса br0 основного маршрутизатора?
      • Если этого не происходит, то основной маршрутизатор не пересылает их (у него уже есть локальные маршруты для пункта назначения, поэтому его правила iptables не разрешают это).
      • Если они достигают br0: пытается ли клиент ответить?
        • Если этого не произошло, то его может блокировать собственный брандмауэр клиента.

Связанный контент