Почему у меня возникают проблемы с соединением в двух подсетях?

Я пытаюсь по беспроводной связи подключить домашнюю сеть моего соседа к моей. У каждого из нас есть свои собственные интернет-сервисы и подсети, которые мы хотим сохранить, но при этом иметь доступ к услугам между нашими подсетями. Для этого я приобрел два локатора M2 Ubiquiti NanoStation и настроил их в тестовой конфигурации, как показано на схеме:

Диаграмма сети

У меня есть один M2, подключенный к порту LAN на моем беспроводном маршрутизаторе ASUS. M2 имеет беспроводной режим, настроенный как "Точка доступа", и сетевой режим, настроенный как "Маршрутизатор". Интерфейсу lan0 назначено 192.168.5.50/24 (шлюз 192.168.5.1, dns 192.168.5.1), а wlan0 назначено 192.168.3.1/24. Он имеет статический маршрут, 192.168.2.0 через 192.168.3.2. С этого момента я могу успешно пропинговать два существующих хоста в моей сети, 192.168.5.10 и 192.168.5.13.

Другой M2, подключенный к сети 192.168.2.0/24, имеет беспроводной режим, настроенный как "Станция", а сетевой режим также настроен как "Маршрутизатор". Интерфейсу lan0 назначено 192.168.2.2 (шлюз 192.168.2.1, dns 192.168.2.1), а wlan0 - 192.168.3.2/24. Этот M2 имеет статический маршрут, 192.168.5.0 через 192.168.3.1.

Маршрутизатор ASUS в 192.168.5.1 передает DHCP и имеет статический маршрут, 192.168.2.0 через 192.168.5.50.

Ноутбуку на схеме назначен статический адрес 192.168.2.3. Во время тестирования он был подключен напрямую к "дальней стороне" М2. Я мог пинговать 192.168.2.2, 192.168.5.50 и 192.168.5.13 немедленно.

Вот где это начинает становиться странным.

При попытке SSH с 192.168.2.3 по 192.168.5.13 команда будет тянуться вечно, но я в итоге смог подключиться. Я выполнил команду с подробным выводом и обнаружил, что при аутентификации GSSAPI произошла ошибка из-за ошибки обратного просмотра DNS. Я добавил 192.168.5.1 в список распознавателей DNS на ноутбуке, что устранило эту проблему и позволило немедленно подключиться.

Тем не менее, я не смог SSH к 192.168.5.10 вообще. Я могу пропинговать его с ноутбука, но если я не добавлю статический маршрут вручную на хост 5.10 для 192.168.2.0 через 192.168.5.50, он не будет подключен. Странно то, что хосту в 192.168.5.13 не нужен этот статический маршрут; это соединяет независимо. Ноутбук на 192.168.2.2 не имеет никаких статических маршрутов, и нет никаких изменений, если статический маршрут добавлен.

Я могу пропинговать ноутбук с 192.168.5.13, однако вывод ping включает перенаправления ICMP.

  1. Как может получиться, что к 192.168.5.13 можно получить доступ без статического маршрута, а к 192.168.5.10 - нет?

  2. Разве вышеуказанный доступ не должен быть закрыт статической записью маршрута в 192.168.5.1?

  3. Есть ли недостающая конфигурация или неверная конфигурация? Я изучал варианты DHCP 141 и 249, будет ли это правильным решением проблемы?

1 ответ

Это звучит как проблема с фильтрацией обратного пути. Редактировать (как sudo) файл /etc/sysctl.conf на компьютере Debian убедитесь, что две строки следующие:

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

сохраните, перезагрузите машину, посмотрите, есть ли у вас проблемы. Если нет, то самый простой способ решить эту проблему - добавить следующее правило в брандмауэр Asus:

iptables -o ethN -j MASQUERADE

где ethN это имя интерфейса, к которому подключены ваши машины Centos и Debian. Это будет иметь преимущество в сохранении конфигурации на each пк, но боюсь у вас на асусе проприетарная прошивка, ничего подобного dd-wrt, openwrt, tomatoи так далее, я прав? В этом случае вам придется изучить FM, чтобы увидеть, существует ли вообще что-либо на этот счет. Или вы можете проверить, могут ли Ubiquities делать это (работают ли они на EdgeOS? Если это так, то вы, безусловно, можете применить приведенное выше правило).

Другие вопросы по тегам