Лес рубят - щепки летят
Тут в журнале Хакер пишут, что российские провайдеры начали блокировать openvpn. Эк они проснулись-то. Проблемы с openvpn периодически возникают (особенно у мобильных провайдеров) уже несколько лет. И как правило, через день-другой разрешаются и все начинает работать.
Всё - это доступ к корпоративным или частным vpn, независимо от того где находится сервер - в Москве или во Франкфурте (у меня сейчас подняты две VPN - одна с сервером там, вторая с сервером сям). Когда в Думе принимали законы о блокриовках VPN там все же подумали, и использование VPN для доступа к локальным сетям оставили легальным. Запрещено только предоставлять доступ неопределенному кругу лиц к заблокированным ресурсам (т.е. торговать VPN).
Но похоже что провайдеры толкуют закон расширительно. И с VPN ситуация такая же, как с BitTorrent. В принципе по протоколу BitTorrent раздаётся уйма вполне легального контента. Который его правообладатель разрешил раздавать (или непосредственно организует раздачу) - дистрибутивы Linux, архивы Wikipedia и так далее. Но сотовым операторам это не интересно. Им проще заблокировать эти легальные раздачи упирая на то, что большая часть раздаваемого по торрентам контента нарушает копирайт. В англосаксонском праве для этого случая есть понятие "significant non-infringing uses". И если эти значительные случаи есть, запрещать весь протокол нельзя.
Но в общем надежды на то что UDP/1194 у нас будет продолжать свободно ходить у меня как-то мало. В связи с этим возникает вопрос, а какие варианты доступа к своей своему серверу стоит иметь в качестве резервных, какие сломают с наименьшей вероятностью.
Первое что приходит в голову - это openvpn over TCP. Конечно, медленнее, чем UDP, но лучше чем ничего. Если использовать порт 443, то отличить opevpn от https можно только путем Deep Packet Inspecition. Оборудование у провайдеров для этой цели, конечно, есть, но может поленятся они гонять через него нетрасграничный траффик (это спасет доступ офисной сети, но не мой сервер в Германии)
Мне известны три способа совместить HTTPS-сервер с OpenVPN сервером на одном порту:
- Директива port-share в конфиге openvpn
- директива ssl_preread в конфиге nginx (я, правда, терпеть не могу fronted-proxy-переросток от Сысоева, и исползую Апач)
- Отдельная утилита sslh
Вот жалко что последний вариант мне был неизвестен когда я работал в компании с фашиствующими админами. Он позволяет через корпоративные прокси, где открыт только 443 порт ходить не только по https, но и по ssh, opevpn, tinc и xmpp.
Думаю, а не пора ли уже у себя на сервере это настроить На всякий случай, чтобы, если потребуется можно было через чужую прокси ходить. Кстати, не исключено что tinc окажется ниже радаров. Вот что wireguard не будут блокировать я не верю, ибо модный и молодежный. А про tinc может и забудут
Еще для приема разных TLS-based соединений на одном порту есть полезная вещь sniproxy. Она, правда, не про разные протоколы, а про разные хосты.
На мой взгляд для удаленной работы одним из наиболее логичных вариантов является использование вместо VPN отдельно https-прокси с авторизацией для доступа к внутренним веб-ресурсам, и отдельно ssh proxy jump для доступа к машинам локальной сети по ssh. (возможно стоит еще отдельную RDP proxy завести. Хотя стоит еще попробовать вариант - зайти на винду по ssh, пробросив туда порт 3389, а уже по этому пробросу идти xfreerdp). Использовать для корпоративных веб-ресурсов sniproxy я бы, пожалуй. не рекомендовал, поскольку как правило в интранетах полно наколеночных ресурсов и проприетарных поделок вроде gitlab и jira, которые сильно уязвимы к атакам из сети. Поэтому отсечение нехороших людей посредством авторизации на входной прокси - дело полезное.
Хотя в свое время я sniproxy использовал именно так - у меня был веб-сервер на домашней машине и prayer webmail на Banana PI, работавшей входным роутером. И один достижимый извне IP адрес. Поэтому я запросы распределял по хостнеймам с помощью sniproxy.
В этом случае, если вдруг почему-то не будет работать доступ к вебу через веб-прокси, то можно ходить через ssh dynamic port forwarding, а если не будут пускать на 22 порт, то есть anytermd Конечно, anyterm это дыра в безопасности шире Черного Моря, но что же делать, когда больше делать нечего?
Еще есть конечно интересный способ - пускать openvpn (в tcp-режиме) через stunnel. Тогда никакая DPI не отличит его от HTTPS-а. Только статистика по продлжетельности соединения и все такое. Но сбор статистики это по-моему уже таржетированная атака. А мы пока что занимаемся законной деятельностью - удаленной работой. И если нам мешают, то нечаянно, по принципу "лес рубят - щепки летят".
С другой стороны openvpn over tcp и так тормозит безбожно. А если еще один уровень TLS сверху накрутить... Может быть через TLS-трубу лучше pppd пускать? Либо в варианте SSTP, либо как-то наколеночно. Правда по-моему из реализаций SSTP в комплекте дистрибутива идет только softether. А у меня разглядывание его исходников в свое время вызвало рвотный рефлекс. Зато он поддерживает много разных протоколов. И если на сервере включить все, а на клиенте тыкаться по очереди по мере уменьшения производительности, то какой-нибудь да заработает.
(wireguard, ipsec и l2tp не упомянтуты потому что их резать на уровне провайдера еще проще, чем openvpn).
X-Post from DW