В мире бушует пандемия, люди скупают туалетную бумагу и гречку в промышленных масштабах, а большинство IT-компаний переводят сотрудников на удаленную работу.
Мой работодатель, немецкая полугосударственная компания, сделал то же самое.
В принципе проблем не было, но одна наша сотрудница месяц назад, когда все выглядело не так плохо, уехала в отпуск к родственникам в Египет и благополучно застряла там из-за закрытия границ.
Ну а сама она здорова, у нее с собой рабочий ноутбук — сидит на карантине и работает через VPN. Неделю работает, потом две.
На третьей неделе VPN перестал подключаться.
Первая линия поддержки проверяла мелочи типа перезагрузки - не помогло.
Второй строкой начал диагностировать: соединение уходит в вечный таймаут на этапе TLS Handshake. Отключил локальный фаервол - не помогло.
Мы попробовали другую машину – не помогло.
Другой провайдер - не работает. На этом моменте поддержка сдалась и радостно подтолкнула мне проблему по старому доброму принципу «во всем виноват сетевик».
Смотрим логи сервера: он не видит попыток достучаться до него после ответа на исходный пакет. Забавно и довольно знакомо.
Я позвонил сотруднику и спросил, как у них обстоят дела с правами человека вообще и свободой Интернета в частности.
Говорит, дела плохи, интернет у них настолько заблокирован, что верблюды икают, а Роскомнадзор нервно курит в сторонке.
Ага.
Быстрый гугл выявляет кучу жалоб на подобные проблемы с VPN в Египте, начиная с 2017 года.
Для полноты картины спрашиваю, была ли сотрудница в своей родной стране в последние годы более 2 недель - нет , она говорит, что нет. Пазл начинает складываться воедино.
Поднимаем копию корпоративного VPN сервера на свободный белый IP - нет соединения.
Ожидал.
Меняем порт - нет соединения.
Это уже печальнее.
Меняем протокол - нет соединения.
Пазл завершен — у нас есть DPI, как у великого китайского файрвола.
Сотрудник грустит, начальник жалобно просит: «Ты русский хакер, сделай что-нибудь».
Ну да ладно.
Давайте раскроем тяжелую артиллерию даркнета и установим obfsproxy. Для сервера (CentOS 7) это выглядит так:
Для клиента (MacOS) так:~ sudo pip install virtualenv ~ cd /etc/openvpn && virtualenv venv && source venv/bin/activate ~ sudo pip install obfsproxy ~ sudo -u openvpn /etc/openvpn/venv/bin/python /etc/openvpn/venv/bin/obfsproxy obfs3 --dest=127.0.0.1:1194 server 1.2.3.4:49416
~ brew install pip
~ pip install pyopenssl obfsproxy
~ obfsproxy obfs3 socks 127.0.0.1:8443Добавьте в конфиг OpenVPN на клиенте:
socks-proxy-retry
socks-proxy 127.0.0.1 8443Выгода.
OpenVPN в обертке obfsproxy не определяется локальными алгоритмами определения сигнатур, сессия взлетает, пинги растут, трафик идет, сотрудник доволен.
Остаётся только добавить в автозагрузку клиентскую часть obfsproxy с этим «очевидным» способом (я ненавижу Mac).
С облегчением прощаюсь с нашим пленником пустыни и пишу письмо в поддержку в духе «эта проблема решается так, но стабильности я не гарантирую, и использовать этот обходной путь можно только в том случае, если абсолютно нет никакой возможности».
другой выход».
Судя по всему, в Египте существует особенно хитрый DPI, который поначалу не блокирует связь с новыми абонентами и/или трафик на новые хосты, относя их к условной категории «туристов».
А по истечении определенного таймаута классифицирует пользователя как «своего» и радостно отсекает трафик в угоду местным королям.
Теги: #информационная безопасность #Сетевые технологии #Системное администрирование #vpn #openvpn #Египет #dpi
-
Как Выбрать Веб-Хостинг
19 Oct, 24 -
Логистика Видеоисследований И Планирования
19 Oct, 24 -
Дизайн, Продукт И Рок-Н-Ролл
19 Oct, 24 -
Обзор Блога № 48. Дневник Мальчика Леши
19 Oct, 24 -
Обновление Firefox 2.0.0.15
19 Oct, 24
