Мы используем серверы OpenVPN AS, которые доступны и работают через общедоступный IP-адрес. Но некоторым нашим клиентам не разрешен доступ к нашему VPN-серверу напрямую (из-за какого-то неприятного администратора брандмауэра - не спрашивайте ...). Чтобы обойти эту проблему, мы разработали установку, которая создаст шлюз в виртуальной среде, который будет выполнять простой NAT для перенаправления всех входящих подключений на наш VPN-сервер.
NAT работает правильно (tcpdump на сервере показывает те же пакеты, которые покидают наш шлюз). Наши текущие маршруты iptables следующие (INPUT, FORWARD и OUTPUT по умолчанию установлены на ACCEPT):
iptables -t nat -A PREROUTING -p udp --dport 1194 -j DNAT --to-destination $vpn_srv
iptables -t nat -A POSTROUTING -j MASQUERADE
Я знаю, что может потребоваться дополнительная настройка, но пока VPN-сервер не отвечает на пакеты, которые он обязательно получает, нам не нужно улучшать правила.
Каждый раз, когда пакет прибывает на сервер VPN, сервер производит следующий вывод журнала:
2012-12-31 13:03:29+0000 [-] OVPN 1 OUT: 'Mon Dec 31 13:03:29 2012 TLS Error: incoming packet authentication failed from 123.123.123.123:35077'
2012-12-31 13:03:31+0000 [-] OVPN 1 OUT: 'Mon Dec 31 13:03:31 2012 Authenticate/Decrypt packet error: packet HMAC authentication failed'
Итак, я полагаю, что нам нужно указать серверу VPN принимать и отвечать на перенаправленные пакеты от этого хоста. Как мы это делаем?
Примечание. Все серверы (сервер VPN и шлюз NAT) являются общедоступными.
Редактировать:
Нет идей? Я знаю, что сервер OpenVPN можно запустить за брандмауэром (простой NAT, как в любой домашней сети). Чем моя установка отличается от той?
Изменить (10.01.2013):
Мы бы попробовали любое решение, которое позволяет перенаправлять трафик VPN от «шлюза» на наш сервер VPN. Предпочтительно использовать шифрование, потому что кажется, что брандмауэр сканирует определенные пакеты vpn, которые будут сброшены.
Если у вас есть клиент с сетевым брандмауэром, который блокирует трафик OpenVPN через DPI и / или какой-то анализ шаблонов, то я не уверен, что вы можете что-то с этим поделать, если не использовать OpenVPN. Я не уверен, что понимаю, как использование дополнительного шлюза и NAT (я полагаю, в вашей неклиентской сети?) Должно хоть немного помочь.
Вместо этого вы можете попробовать использовать функции OpenSSH SOCKS или tun (4). (При условии, что по каким-то странным причинам заблокирован только OpenVPN, но не ssh.)
Функциональность SOCKS поддерживается всеми основными реализациями ssh (ее часто называют «динамической переадресацией портов»), и она позволит вашему клиенту подключаться и аутентифицироваться через SSH с -D1080 вариант, а затем укажите localhost:1080 как прокси-сервер SOCKS5 в веб-браузере. Очень прост в настройке (никаких изменений на стороне сервера не требуется, если у пользователя уже есть доступ по ssh), и в целом отлично работает (я использую его все время из общедоступных сетей).
В качестве альтернативы, если вы используете систему UNIX, вы можете настроить tun(4) через OpenSSH тоже. Это относительно новая функция, и она требует дополнительной настройки по сравнению с проксированием SOCKS, которое практически уже включено по умолчанию, но это также хороший вариант, в зависимости от того, что вы ищете.
Есть два других порта для пересылки, это 443 и 943, как указано в Вопросы-Ответы из OpenVPN:
Какие порты мне нужно открыть в брандмауэре для сервера доступа?
Краткий ответ: TCP 443, TCP 943, UDP 1194
И, если это не сработает и все IP-адреса являются общедоступными, вы можете попытаться удалить MASQUERADE и разрешить установление соединения с P-t-P, проходящего через ваш шлюз.
Если ничего из этого не помогает, вам может потребоваться предоставить дополнительную информацию, такую как выдержки tcpdump, даже о журналах отладки.