Великий египетский фаерволл
В мире бушует пандемия, народ скупает туалетную бумагу и гречку в промышленных масштабах, а ИТ компании в большинстве своем переводят сотрудников на удаленку. Так поступил и мой работодатель — немецкая полугосударственная контора.
В основном проблем не возникло, но одна из наших сотрудниц с месяц назад, когда все выглядело еще не так страшно, поехала в отпуск к родне в Египет и благополучно застряла там из-за закрытия границ. Ну, сама-то здорова, рабочий ноут с ней — сидит себе на карантине и работает через VPN. Неделю работает, две… На третью неделю VPN перестал подключаться. Саппорт первой линии проверил банальности навроде перезагрузки — не помогло. Вторая линия стала диагностировать: соединение уходит в вечный таймаут на стадии TLS Handshake. Отключили локальный фаерволл — не помогло. Попробовали другую машину — не работает. Другого провайдера — не работает. На этом моменте саппорты сдались и радостно спихнули проблему на меня по старому доброму принципу «во всем виноват сетевик».
Смотрим в логи сервера: он вообще не видит попыток до него достучаться после ответа на initial packet. Забавно и довольно знакомо. Звоню сотруднице, интересуюсь, как у них там дела с правами человека вообще и свободой интернета в частности. Говорит, что дела хреново, интернеты же у них блокируют так, что верблюдам икается, а Роскомнадзор нервно курит в сторонке. Ага… Беглый гуглеж показывает кучу жалоб на аналогичные проблемы с VPN в Египте, начиная с 2017 года. Для завершения картины спрашиваю, бывала ли сотрудница на родине в последние годы дольше 2 недель — нет, говорит, не бывала. Пазл начинает складываться.
Поднимаем копию корпоративного VPN сервера на свободном белом IP — нет коннекта. Ожидаемо.
Меняем порт — нет коннекта. Это уже печальнее.
Меняем протокол — нет коннекта. Пазл сложился — перед нами DPI наподобие великого китайского фаерволла.
Сотрудница грустит, начальство жалобно просит «ты же русский хакер, сделай что-нибудь». Ну ладно… Расчехляем тяжелую артиллерию даркнета и вкорячиваем obfsproxy.
Для сервера (CentOS 7) это выглядит так:
~ 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Для клиента (MacOS) так:
~ 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 в автозагрузку вот этим «очевидным» способом (ненавижу маки). Я облегченно прощаюсь с нашей узницей пустыни и пишу письмо саппортам в духе «эта проблема решается вот так, но стабильность не гарантирую, и юзать этот workaround можно только если совсем нет другого выхода».
Судя по всему, в Египте имеет место быть особо хитрозадый DPI, который первое время не блокирует связь новым абонентам и/или трафик на новые хосты, относя таковые к условной категории «туристы». А после истечения некоего таймаута относит пользователя к категории «своих» и радостно режет трафик в угоду местным царькам.
