Как использовать OpenVPN через ограничительный брандмауэр?

Как использовать OpenVPN через ограничительный брандмауэр?

В настоящее время я пытаюсь настроить OpenVPN на персональном VPS, для подключения в первую очередь через чрезмерно ограничивающий брандмауэр. Все настройки, упомянутые ниже, работают при использовании через разумно защищенное брандмауэром соединение.

Я пытался:

  1. OpenVPN работает на стандартном порту
  2. OpenVPN работает на порту 443 (я запускаю OpenVPN вручную из командной строки на VPS и вижу, что сервер сообщает о почти немедленном закрытии соединения, предполагаю, что это результат DPI на брандмауэре)
  3. STunnel, работающий на порту 443, для доступа к OpenVPN и обхода DPI. Это наиболее успешный способ, который позволяет устанавливать соединение и доступ в Интернет через VPN в течение ~10-20 секунд, прежде чем соединение будет принудительно закрыто.

Могу ли я попробовать сделать что-то еще?

решение1

Обрывы соединений после определенного времени иногда указывают на ограничение типа байт в секунду. Попробуйте посмотреть, работает ли замедление вашего VPN-подключения. Также, если у вас настроен OpenVPN для UDP, попробуйте TCP (443 UDP может быть заблокирован, тогда как 443 TCP может остаться незамеченным).

Посетите известный сайт, который использует SSL, и проверьте сертификат. Затем сделайте то же самое дома. Если они не совпадают, то ваше местоположение использует прозрачный HTTPS SSL-прокси и может фактически видеть ваш HTTPS-трафик.

Возможно, что-то, что не является портом 443, не отслеживается так пристально. Попробуйте 22.

Это может показаться глупым, но попробуйте сделать это через порт 80 и посмотрите, что получится. Вы также можете попробовать настроить HTTP-туннель между вами и VPS, чтобы трафик выглядел как HTTP-запросы.

Если вы чувствуете себя сумасшедшим, попробуйтейод.

решение2

Думаю, я знаю, почему метод Stunnel ведет себя так. Это потому, что вы устанавливаете «статический маршрут» для сервера Stunnel. Позвольте мне объяснить это. Когда вы подключаетесь к серверу OpenVPN, он изменяет вашу таблицу маршрутизации и направляет все ваши пакеты через VPN, за исключением пакетов OpenVPN. На самом деле OpenVPN добавит маршрут для IP-адреса вашего сервера. Но когда вы используете Stunnel для подключения к вашему серверу OpenVPN, вы подключаете OpenVPN к интерфейсу loopback, и нет никакого маршрута к вашему серверу за пределами вашего VPN, поэтому пакеты Stunnel хотят пойти на сервер, и они идут на ваш VPN, а ваши пакеты VPN идут на Stunnel :)

Поэтому вам нужно добавить маршрут к IP-адресу вашего сервера, который выходит за пределы вашего VPN (вашего домашнего маршрутизатора).

А для проблемы с методом порта 443 я хочу сказать, что, возможно, ваш брандмауэр использует SPI или DPI и может легко создавать различные пакеты openvpn из пакетов https (ssl). Так что лучший способ - использовать stunnel, или, если брандмауэр блокирует пакеты ssl, лучше использовать obfsproxy или fteproxy, чтобы обойти его.

(знаю, что пост слишком старый, но я искал ответ на ту же проблему несколько недель, поэтому хотел поделиться тем, что я узнал по этому поводу)

решение3

Ответ Резы Аскари был точным ответом на третий вопрос. Это происходило как на моем компьютере Linux, так и на Android.

На компьютере, перед подключением к OpenVPN через

sudo openvpn --config configFile.ovpn

Вам следует добавить правило для удаления сервера Stunnel из туннеля OpenVPN.

sudo /sbin/ip route add stunnel_ip via default_gateway_ip

Затем подключитесь к вашему серверу OpenVPN. Когда закончите, вы можете удалить это правило:

sudo /sbin/ip route del stunnel_ip

Чтобы упростить задачу и не забыть, создайте скрипт оболочки, который добавит правило и запустит OpenVPN. Когда OpenVPN завершит работу, правило будет удалено:

sudo /sbin/ip route add stunnel_ip via default_gateway_ip

sudo openvpn --config configFile.ovpn

sudo /sbin/ip route del stunnel_ip

На Android используйте клиент «OpenVPN for Android» от «Arne Schwabe» и «SSLDroid» от «Balint Kovacs».

Затем в клиенте OpenVPN исключите «SSLDroid» из профиля VPN, проходящего через Stunnel.

Я бы с удовольствием проголосовал за ответ или комментарий Резы, но это правило оценки репутации помешало мне.

решение4

В дополнение к ответу LawrenceC я хотел бы добавить, что исходящая защита от DDoS-атак slow loris и других «низкоскоростных и медленных» DDoS-атак, исходящих из этой сети, принудительно закроет сеансы по истечении определенного периода времени.

Как упоминалось ранее, это также может быть вызвано ограничением объема трафика, но есть и другая причина, по которой может существовать такое ограничение: ограничение пропускной способности на устройство является тривиальным с сегодняшними (2021 г.) технологиями и больше не использует тайм-ауты сеансов для его реализации, но защита от исходящих DDoS-атак также может отключать сеансы, отправляющие постоянный поток данных с использованием протокола, поведение которого по своей сути спорадично, особенно если трафик содержит пакеты, которые либо слишком однородны, либо слишком фрагментированы, чтобы соответствовать поведению легитимных сеансов HTTPS (именно так выглядят многие атаки DDoS типа Flood).

За последние годы межсетевые экраны с отслеживанием состояния прошли долгий путь, и предотвращение именно такого поведения стало одной из главных задач в контексте предотвращения утечки данных, а также защиты от DDoS-атак, которую я только что перечислил.

Достижение этой цели сегодня с помощью хорошо построенного межсетевого экрана потребует гораздо большего, чем просто советы о том, какие конфигурации использовать.

Связанный контент