Комментарии 54
Официальный виндовый клиент OpenVPN Connect не поддерживает опцию socks-proxy. Желающим обфусцировать openvpn под виндой можно использовать community edition клиента.
Сервера, к которым организуется доступ, работают на Linux, на Windows встречаются только клиенты.
Так я же и пишу, что официальный клиент на Windows не поддерживает опцию socks-proxy.
Туннель строится между серверами на Linux. Клиенты ничего не знают про туннель. Они подключаются к ресурсу, не ведая, как все проложено.
Это называется site-to-site vpn. Можно использовать этот термин, чтобы не было путаницы :)
Не обязательно. Посмотрите на картинку, которая идет главной к статье. Там изображена топология звезда. Куча серверов, один из которых находится за границей. Вот его соединение и туннелируется. Клиенты при этом подсоединяются к vpn серверу как полноценные пиры. Это не site-to-site. Но для site-to-site все описанное тоже работает.
Вот его соединение и туннелируется.
Проблема в том, что в наше время защищать надо не только VPNы в заграницу, и но даже внутри страны - потому что "всё то же самое" случается, что давит любой VPN-трафик без разбору, в заграницу он или на другой конец города.
О как. А какой провайдер так делает? И есть опыт, что происходит с блокировкой vpn, построенного на ipv6?
Этот провайдер называется РКН, т.к. вряд ли провайдер сможет управлять установленными у него ТСПУ ;) А "поиграться" названная трёхбуквенная контора может на любом провайдере, к которому водрузила твои четырёхбуквенные устройства. Может они там вообще дайсы кидают, выбирая, на каком операторе очередной эксперимент с VPNами провести?
Про IPv6 не сталкивался, не знаю, а вот с ситуацией, когда концы VPN были в одном городе, но у разных провайдеров - да.
Но вообще о таком говорили уже давно, тут, например https://habr.com/ru/news/738790/
Так что то, что рядом человек писал про openvpn-клиента про Windows с поддержкой socks-proxy, в какой-то ситуации может иметь значение, на случай если совпадёт и одновременно с проблемой "поломается" удалёнка.
Я сам далеко не в РФ, поэтому не все понятно с первого слова. Хотя серверов хватает там. И что вы думаете реально, что какой-то черный ящик от этих товарищей может стоять в разрыве транспортной сети и переваривать через интегрированный dpi 100Гбит? Прямо реально в разрыве и режиме реального времени?
А про ipv6 я не просто так спросил. Мы же все понимаем, что делать тоже самое на ipv6 - это дублировать ресурсы для этого протокола. Ну ладно, в начале можно не ждать много трафика, но лет через 5 для Москвы и Спб - вполне... Что-то мне кажется, что про ipv6 никто пока всерьез не думает))
Я сам далеко не в РФ, поэтому не все понятно с первого слова.
А, ок, буду пояснять некоторые локальные мемы :)
И что вы думаете реально, что какой-то черный ящик от этих товарищей может стоять в разрыве транспортной сети и переваривать через интегрированный dpi 100Гбит? Прямо реально в разрыве и режиме реального времени?
Не может, а должен. Просто РКН не на всех "хватило" - т.к., в отличии от СОРМ (буквы русские) или "PRISM of Yarovaya" (которая по задумке должна писать вообще весь трафик провайдера, в отличии от СОРМ, который пишет избранных), эти железки по изначальной задумке даёт РКН, провайдер только обеспечиваем им место в стойке, подключение к сетям, и электричество. Хотя пробегали сообщения, что РКН пытается заставить некоторых провайдеров такое оборудование покупать за свой счёт.
На счёт "чёрного ящика" - так тот же СОРМ, хоть и куплен провайдером, тоже для него "чёрный ящик", что там товарищ майор смотрит со своего пульта через него - оператор связи не знает.
В то же время механизмы блокировок, использовавшиеся провайдерами до конца 2019г, или на кого (пока) не хватило ТСПУ - там да, там сами провайдеры блокируют по реестру, получаемому от РКН. И если провайдер хотя бы видит содержимое этого реестра, то что там вливают в ТСПУ со стороны РКН - нет.
Отличие "Ростелекома" от других провайдеров тут разве что в том, что ему принадлежит производитель такого оборудования.
Ну еще можно почитать https://habr.com/ru/articles/546422/ или вот тут https://habr.com/ru/news/559068/ , что особо доставляет лулзов - РКН по ошибке замедлил Microsoft.com как раз в момент, когда народ срочно качал фикс для дырки в Exchange...
А про ipv6 я не просто так спросил. Мы же все понимаем, что делать тоже самое на ipv6 - это дублировать ресурсы для этого протокола.
Сам не сталкивался, так что тут лучше у народа спросить, как там дела с IPv6 на практике, но в теории и его тоже "может".
Так что смотрим, что там у китайцев, и ожидаем того же самого от Чебурнета... Причём из-за ошибок или специально (никто ж не признается) - не только для зарубежного трафика, но и внутри страны (хотя бы потому, что могут "перепутать" трафик, выходящий за сеть провайдера, с трафиком, выходящим из страны).
Спасибо вам за развернутый ответ. Я раньше думал, что все эти "черные ящики" подключаются через port mirroring и на сам трафик в режиме реального времени не влияют (чего должно хватать для их целей). И отдавать какие-то команды провайдеру, кого блокировать, кого нет. Типа такого: трафик получили, через свое облако прогнали, сделали выводы, json на api провайдера отправили.
Загонять весь vpn в ss туннели - это конечно грустно(.
Я раньше думал, что все эти "черные ящики" подключаются через port mirroring и на сам трафик в режиме реального времени не влияют (чего должно хватать для их целей).
"Раньше" было действительно не так - блокировки по реестру провайдеры делали сами, СОРМ и "Призма Яровой" - действительно миррор. Конкретные технологии блокировки "по реестру" были на усмотрение провайдера, там есть разные технологии в зависимости от того, какой collateral damage провайдер считал допустимым и насколько хотел вкладываться технически в эти блокировки. Вкладываться в DPI хотелось не всем ;)
Плюс есть еще "коробки" для мониторинга "а не забил ли оператор связи на блокировки?".
То же, о чём мы говорим - появилось в конце 2019г.
Загонять весь vpn в ss туннели - это конечно грустно(.
Ну или как минимум резервировать основной VPN по подобной схеме, на случай "перебиться день-два, пока РКН свои косяки исправит". И если исходить из гипотезы "просто перепутали кроссграничный трафик с межпровайдерским" - то и всякие XRay, XTLS, Cloak и прочее надо подтягивать, с учётом отличий в зависимости от того, в РФ или за рубежом находятся концы VPN.
У него нет внешних ovpn клиентов.
У него есть локальная сеть в условной Москве, и вторая локальная сеть в условном Дублине.
Есть задача связать их в единую сеть при помощи ovpn, избежав ковровых бомбардировок.
Я понял это так.
Коллеги, а почему бы не использовать технологию port forwarding внутри ssh соединения, а сам openvpn запустить с data-ciphers none ?
Так можно. Нужно нарастить схему обвязками, которые будут восстанавливать туннель при падении. И нужно понимать, что ssh - это протокол управления, ему не нужна высокая скорость, отсюда можно словить сюрпризы, вроде max 128 кбит\с в провайдерском Qos.
Да, речь идет не о полном туннелировании вообще всей VPN сети, а только закордонных серверов. Соответственно настройки шифрования везде будут и будут одинаковые.
А как же бэкапы по scp ?
Лично для себя нагородил огород
openvpn client -> ssh port forwarding -> socks5 (dante) -> udp openvpn server
когда мтс начал баловаться с блокировками чистого openvpn причем на офисной выделенке 100мбит
померил спидтестом дало скорость 105мбит (я думаю сжатие добавило) остался доволен
Да на айфон такое не запилишь, поставил xray сервер, а на мобилки V2BOX
Провайдерский Qos приоритизирует трафик. Он может быть настроен как угодно. Ограничение по скорости для выделенного типа трафика - это часть Qos. И шейпинг для managment packets - это реальность. А когда по этой нарезанной полосе полезут большие объемы трафика - этого следует ожидать следующим шагом.
Интересно было бы почитать, как сделать аналогичное с wireguard-тоннелями.
О, статья на удаление по последнему приказу минцифры)
Что там по приказу, не развернете мысль подробнее?
Хабру будет проще не соблюдать этот маразматичный бред. Потому что Хабр без годных статей по сетям и VPN - это будет уже не тот Хабр. Большинство читателей тут айти сообщество, даже если Хабр заблокируют, они всё равно найдут способ открыть и почитать.
сохранил в pdf, спасибо
Кстати, snapd не очень хорошо (мягко говоря) работает в Docker, что делает сложным апгрейд протокола по этой инструкции.
А кто-то понимает, белый список протоколов там используется или чёрный? Если "испортить" (например, xor-нуть) payload Ethernet-фрейма, пропустят или заблокируется?
Я думал над этим вопросом. Dpi не дешифрует трафик, а пытается его категорировать в соответствии с обнаруженными артефактами. Внедрять белый список протоколов - утопично. Есть же динамически назначаемые значения. Можно обвалить кучу полезных сервисов, в том числе около государственных. Я думаю, что xor даст положительный результат. Если реализуете, пришлите ссылку на проект, будет интересно с ним ознакомиться.
Я правильно понимаю, что для клиентов на их устройствах, помимо openvpn клиента, придется еще и shadowsocks клиент использовать?
То-есть 2 приложения, вместо одного запускать.
Ведь socks-proxy 127.0.0.1 3000 это мы ссылаемся сами на себя в настройках openpvn.
Или я что-то недопонял?
Не верно. Вся сеть работает на openvpn: сервера, клиентские машины, мобильный доступ. Один из серверов вынужден жить за границей. Чтобы в случае массовых блокировок он случайно под них не попал, его vpn (от этого железного сервера до openvpn сервера у нас в центральном офисе) засунут внутрь ss туннеля. Т.е. ss туннель постоянно работает между этими двумя серверами и обеспечивает отказоустойчивость доступа посредством openvpn.
Вся виртуальная локалка выстроена на openvpn. Клиенты не ведают, где и как проходят туннели. Но мое решение задумано для защиты закордонных серверов от отсоединения, как на главной картинке схематично нарисовано.
Ss нам дает обфускацию. На картинке видно, как выглядит трафик. tun2tap ни разу не использовал, но это не для этого же (это когда вам очень нужно попасть в L2 туннель, а мобила умеет только с L3 туннелем работать). Описанное в статье решение enterpris-ом не назовешь, но работает стабильно и должно пережить глобальный потоп, простоя в работе быть не должно.
У нас не было проблем с сетью сегодня, мониторинг регулярно следит за доступностью. Но на дальнем востоке клиентов правда тоже нет). А что за оператор отличился?
Конкретно проверял Yota и Tele2
1 раз было в сентбяре и вот вот 1 раз в октябре
фильтровались все впны (pptp/l2tp/ikev2/openvpn) внутри РФ
Не важно сервер на VPS внутри страны или на домашнем IP у абонента РТК.
При этом на местном кабельном интернет провайдере фильтра не было.
Фильтр на yota/tele2 пропал примерно в 10:30 по Мск
А по поводу tun2tap я именно для того же и собирался использовать.
То-есть вместо sslocal клиента, использовать tun2tap клиент который сразу подключается к ssserver и выводит это в тунельный интерфейс, в который мы уже можем маршрутизировать нужный трафик.
А то мне кажется по вашему способу нагрузки будет больше.
Сначала тунелится через shadowsocks, а потом еще и openvpn повторно это тунелится внутри shadowsocks.
Shadowsocks-туннелирование корпоративного VPN