Сложная проблема маршрутизации с Linux, Quagga и OpenVPN
Настройка
У меня есть сервер 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), он отвечает нормально.
Я действительно надеюсь, что я проясняю, поскольку это довольно сложная проблема. Я буду рад предоставить дополнительную информацию по вашему запросу.
3 ответа
Я использовал "client-config-dir", который позволил мне указать маршрут за каждым клиентом с помощью команды "iroute".
После этого VPN-сервер протолкнул маршрут для всех этих подсетей ко всем остальным клиентам, и он работал нормально.
Что я нахожу странным, так это то, что таблицы маршрутизации клиента никуда не указывают (0.0.0.0). Это нормально для локальных сетей, но для 10.2.10.1, который проходит через туннель, это может быть проблемой.
Я бы подумал, что маршрута по умолчанию, указывающего через VPN-туннель, было бы достаточно для того, чтобы клиенты могли выполнять маршрутизацию к другим клиентам (если это позволяет концентратор VPN), без необходимости запуска демонов маршрутизации на индивидуальные клиенты.
Глядя на таблицу маршрутизации, я подозреваю, что проблема заключается в том, что "следующий переход", переносимый в обновлениях маршрутизации, недоступен для клиента, и вместо игнорирования маршрута он устанавливает его с неизвестным следующим переходом.
Что произойдет, если вы деактивируете Quagga и вместо этого просто используете маршрут по умолчанию, указывающий через VPN-туннель?