Проблема с IPCop и OpenVPN (я не могу сделать мост)
У меня проблема с IPCop + zerina OpenVPN.
Мои сети, как на рисунке, хорошо настроены:
- IPCop действует как межсетевой экран между двумя каналами 192.168.100.0/24 и 192.168.200.0/24.
- OpenVPN работает с конфигурацией roadwarrior (client1 может пропинговать внутренний IP IPCop 192.168.100.0 через туннель OpenVPN).
Проблема в том, что client1 не может пропинговать server1, потому что IPCop+OpenVPN не пересылает трафик во внутренней локальной сети. Я не могу использовать ни один из двух режимов пересылки OpenVPN:
- Я не могу использовать решение OpenVPN TUN (маршрутизация): ланы изолированы, и мне некуда направлять
- Я не могу использовать решение OpenVPN TAP (мост) (возможно, в этом случае правильное решение), потому что IPCop не поддерживает мостовые соединения (не имеет bridge-utils и явно не поддерживает его).
Любое решение? Или я должен переместить сервер OPenVPN на другой внутренний сервер, который может соединяться (естественно настраивая IPCop, чтобы разрешить трафик OpenVPN на новый VPN-сервер). Есть ли более простое решение без услуг переезда?
3 ответа
Это
ipcop# ip route
10.159.19.2 dev tun0 proto kernel scope link src 10.159.19.1
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.2
10.159.19.0/24 via 10.159.19.2 dev tun0
192.168.200.0/24 dev eth1 proto kernel scope link src 192.168.200.2
ipcop# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.159.19.2 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 eth0
10.159.19.0 10.159.19.2 255.255.255.0 UG 0 0 0 tun0
192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
Я думаю, что проблема в том, что нет шлюза по умолчанию, поэтому нет места для маршрутизации трафика.
Таблица маршрутизации на клиенте есть
client1# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.159.19.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.159.19.1 10.159.19.5 255.255.255.255 UGH 0 0 0 tun0
192.168.100.0 10.159.19.5 255.255.255.0 UG 0 0 0 tun0
192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 vboxnet1
vboxnet1 действует как обычный интерфейс eth. Это интерфейс с client1 подключен к красной сети (192.168.200.0/24).
Единственная проблема заключается в том, что server1 не имеет маршрута для sendind ответа на client1, просто добавьте 192.168.100.2 в качестве маршрута для server1 в сеть 192.168.200.0, и server1 должен иметь возможность ответить на client1. добавление маршрута -net 192.168.200.0/24 gw 192.168.100.2
ОК, новая попытка Это то, что я думаю, происходит.
Пакеты от клиента имеют адрес источника 192.168.200.X, проходят через интерфейс TUN (правила маршрутизации клиента), VPN-серверы отправляют его по назначению, но ответ проходит через eth1, теряется. Вы должны попробовать и проверить все это с tcpdump,
Чтобы устранить эту проблему, вы, вероятно, можете установить источник в качестве адреса VPN, например, с помощью команды, подобной
ip route add 192.168.100.4/24 dev tun0 src 10.169.10.X
Тем не менее, это проблема с этой настройкой теста, не ожидайте, что такая же проблема с реальной вещью.