Не удается пинговать Ubuntu VM после подключения к моему VPN-провайдеру.

На чтение 3 мин Опубликовано 13.01.2025

Вопрос или проблема

Моя установка требует, чтобы я запускал 2 виртуальные машины, которые являются выделенными VPN-серверами. Я должен передавать весь трафик LAN через vpn-туннель от моего маршрутизатора к моему strongswan VPN-серверу, который затем пересылает весь трафик на мой openvpn сервер, который отправляет все данные, предназначенные для интернета. Мне приходится так делать, потому что мой маршрутизатор не может подключаться к openvpn и использует только Ikev2 (Ipsec), из-за чего мне нужен сервер strongswan.

Я всё настроил, но всякий раз, когда я подключаю свой сервер Openvpn к своему поставщику VPN, я не могу проверить связь с сервером Strongswan VPN, что мне нужно, чтобы передавать весь трафик на сервер OpenVpn. Всё работает до подключения моего сервера OpenVPN к моему поставщику. Я выполняю команду ping с 10.0.70.10 на 10.0.80.10.

У кого-нибудь есть идеи? Есть ли более простой способ?

Вот моя конфигурация openvpn

client
dev tun
proto udp
remote xxx.xxx.xxx.xx xxxx
resolv-retry infinite
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping 15
ping-restart 0
ping-timer-rem
reneg-sec 0
comp-lzo no
verify-x509-name CN=XXX.com

remote-cert-tls server

auth-user-pass
verb 3
pull
fast-io
cipher 
auth 
<ca>
-----BEGIN CERTIFICATE-----

Ответ или решение

Проблема, с которой вы столкнулись, заключается в том, что после подключения OpenVPN сервера к провайдеру VPN вы теряете возможность пинговать сервер OpenVPN с сервера Strongswan. Это может быть вызвано различными факторами, связанными с маршрутизацией, конфигурацией фаервола или политиками безопасности в среде VPN.

Теория: Когда OpenVPN сервер устанавливает соединение с провайдером VPN, он, как правило, меняет маршрутизацию трафика через VPN-туннель. Это может привести к изменению таблиц маршрутизации, из-за чего локальное сетевое соединение между Strongswan и OpenVPN серверами может быть нарушено. Более того, часто при подключении к VPN провайдеру применяется политика ведения всего исходящего трафика через туннель, исключая прямые локальные соединения.

Пример: Например, если OpenVPN применяет маршрут по умолчанию (default route) через туннель, то попытки соединений из локальной сети к этому серверу могут игнорироваться или перенаправляться неверно. Аналогично, настройки фаервола могут блокировать ICMP пакеты (используемые для ping) по состоянию интерфейсов до или после установления VPN-соединения.

Применение:

Маршрутизация: Проверьте таблицу маршрутизации на OpenVPN сервере до и после подключения к VPN-провайдеру. Используйте команду ip route для проверки текущих маршрутов. Убедитесь, что путь из Strongswan (10.0.70.10) до OpenVPN сервера (10.0.80.10) правильно прописан и не попадает в "туннельные" маршруты.
Настройки фаервола: Убедитесь, что фаервол на OpenVPN сервере позволяет пакеты ICMP от Strongswan сервера. Используйте инструменты, такие как iptables для диагностики и временной деактивации правил фаервола:
```
sudo iptables -L -v -n
```
Управление политиками: Определите, может ли ваш OpenVPN провайдер поддерживать split-tunneling, что позволит маршрутизировать только определенный трафик через VPN, тогда как остальной трафик, в том числе и возвратное локальное подключение, будет обрабатываться в соответствии с локальными правилами.
Конфигурация OpenVPN: Проверьте конфигурацию OpenVPN на наличие директив, которые могут ограничивать соединения (например, redirect-gateway, который перенаправляет весь трафик через VPN). Возможно, потребуется дополнительная настройка.

Общий совет — создайте резервную копию текущих конфигураций и настройте трассировку для более детального анализа трафика. Это поможет в обнаружении, какая именно конфигурация сетевого пути вызывает проблемы с пингом между двумя внутриистемными VPN серверами.