У меня есть сервер OpenVPN, который действует как центральный маршрутизатор. Он настраивается командой «топология подсети». Клиенты - это узлы Debian Linux, и к каждому из них напрямую подключена одна (или несколько) подсетей.
Цель состоит в том, чтобы любой клиент, подключенный к VPN, мог получить доступ к подсетям, подключенным друг за другом клиентом.
Чтобы распространять информацию о маршрутизации, мы установили Quagga на клиентах и на сервере. Это отлично работает с демоном OSPF. Маршрутизация включена на всех клиентах и на сервере.
Таблица маршрутизации на сервере следующая:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.2.10.1 10.8.0.4 255.255.255.255 UGH 20 0 0 tun0
192.168.100.0 10.8.0.4 255.255.255.0 UG 20 0 0 tun0
192.168.1.0 10.8.0.4 255.255.255.0 UG 20 0 0 tun0
Подсеть, к которой я хочу получить доступ, - 192.168.100.0/24. Соответствующий шлюз отвечает отлично, и я могу нормально к нему подключиться.
Я не думаю, что это будет полезно, но вот часть таблицы маршрутизации клиентов:
10.2.10.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Пинг от сервера (10.8.0.1) к любым узлам (включая интерфейс клиента VPN) в подсети 192.168.100.0/24 завершается ошибкой. Если я tcpdump интерфейс tun на VPN-клиенте, я не вижу соответствующего пакета. Если я tcpdump интерфейс tun на сервере VPN, я вижу, что пакет, о котором идет речь, отправляется.
Настоящая неприятная вещь заключается в том, что когда я отслеживаю маршрут до действительного IP-адреса в подсети 192.168.100.0, он не обнаруживает никаких переходов (должен быть только один). Если я трассирую маршрут непосредственно до следующего перехода (10.8.0.4), он отвечает нормально.
Я действительно надеюсь, что я прояснил, поскольку это довольно сложная проблема. Буду рад предоставить дополнительную информацию по вашему запросу.
В итоге я использовал «client-config-dir», который позволил мне указать маршрут за каждым клиентом с помощью команды «iroute».
После этого я попросил VPN-сервер протолкнуть маршрут для всех этих подсетей всем другим клиентам, и он работал нормально.
Я бы подумал, что маршрута по умолчанию, указывающего через туннель VPN, было бы достаточно для клиентов, чтобы иметь возможность маршрутизировать к другим клиентам (если это позволяет концентратор VPN), без необходимости в демонах маршрутизации, работающих на индивидуальные клиенты.
Глядя на таблицу маршрутизации, я подозреваю, что проблема в том, что «следующий переход», переносимый в обновлениях маршрутизации, недоступен для клиента, и вместо того, чтобы игнорировать маршрут, он устанавливает его с неизвестным следующим переходом.
Что произойдет, если вы деактивируете Quagga и вместо этого просто воспользуетесь маршрутом по умолчанию, указывающим через туннель VPN?
Что мне кажется странным, так это то, что таблицы маршрутизации клиентов никуда не указывают (0.0.0.0). Это нормально для локальных сетей, но для 10.2.10.1, который проходит через туннель, это может быть проблемой.