Почему у меня возникают проблемы с соединением в двух подсетях?
Я пытаюсь по беспроводной связи подключить домашнюю сеть моего соседа к моей. У каждого из нас есть свои собственные интернет-сервисы и подсети, которые мы хотим сохранить, но при этом иметь доступ к услугам между нашими подсетями. Для этого я приобрел два локатора 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.
Как может получиться, что к 192.168.5.13 можно получить доступ без статического маршрута, а к 192.168.5.10 - нет?
Разве вышеуказанный доступ не должен быть закрыт статической записью маршрута в 192.168.5.1?
Есть ли недостающая конфигурация или неверная конфигурация? Я изучал варианты 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? Если это так, то вы, безусловно, можете применить приведенное выше правило).