Есть опенвпн сервер (нет, wireguard не подойдет) на vps, все соединение с которым, включая рукопожатие, зашифровано заранее обговоренными ключами (tls-crypt-v2) и катится через 443/tcp (вообще удп в основном, пока работает). Обязательно должен работать iOS-клиент, соотвессна никаких ssh-туннелей и пр. Очень уж хочется построить из себя параноика, живя в России, за сим интересно: 1. Вики говорит, что еле2 умеет в блокировку esni. Насколько сам смог вкурить, esni != ech, потому что в первом случае в рукопожатии явно видно незашифрованную часть, хоть уже и без имени хоста, а вот во втором браузер с сайтом обмениваются всю дорогу мусором по каналу, из-за чего в принципе можно предположить, что там не сайт грузится, а что-то другое. Насколько часты в природе случаи "вот этого вот другого", чтобы если РКН решили бы забанить весь 443/tcp без явного ClientHello, снова пришлось бы чинить половину интернета и откатывать блокировку? 2. Раз опенвпн на сервере знает, что говорит ему клиент, подключаясь с правильным ключем, то не написал ли еще никто случаем какой-нибудь мультиплексер на стероидах, который бы отличал зашифрованный клайентхеллоу от приветствия опенвпна, чтобы на одном и том же порту и к впн меня подключать, и посторонним заглушку выбрасывать безобидную, кто с браузера зайдет?
Openvpn через tcp плохо работает. Работая на 443 порту ты не обезопасишься от определения типа трафика, сигнатура openvpn трафика отличается от https. Настрой сервер на любом udp порту и морочь себе голову, роскомпидорасы ещё долго будут сосредоточены на сайтах и крупных сервисах.
>какой-нибудь мультиплексер на стероидах, который бы отличал зашифрованный клайентхеллоу от приветствия опенвпна, чтобы на одном и том же порту и к впн меня подключать, и посторонним заглушку выбрасывать Вроде были такие решения, сам не пользовался и даже не помню названий, так как не интересовался, но что-то такое я встречал.
>>3804 Пишу ж как раз, что работает оно в основном на UDP, иногда TCP пробую, чтобы посмотреть, не сломались ли конфиги случайно. Структура разная, но на то и tls-crypt-v2, который в openvpn 2.5 добавили - wireshark больше не понимает, что я вообще переношу за трафик, а к серверу я могу подключаться с совершенно рандомных прокси и вообще не думать о том, сколько там кто времени потратит на его расшифровку.
>>3803 (OP) >2. Раз опенвпн на сервере знает, что говорит ему клиент, подключаясь с правильным ключем, то не написал ли еще никто случаем какой-нибудь мультиплексер на стероидах, который бы отличал зашифрованный клайентхеллоу от приветствия опенвпна, чтобы на одном и том же порту и к впн меня подключать, и посторонним заглушку выбрасывать безобидную, кто с браузера зайдет? Это надо терминировать TLS чтобы распознать протокол внутри него. Этим умеет заниматься Nginx, НО я полагаю, что с OpenVPN такой трюк не пройдёт т.к. он сильно повязан на TLS сессию, что значит, что нельзя терминировать TLS до OpenVPN сервера без уродских костылей, делящих сесурити на ноль.
>>3806 Я скорее про какие-нибудь патчи для опенвпн думал, чтобы сам опенвпн разбирался с этим Но такую дичь надо уже самому писать, лезть в исходники там >>3807 Посмотрел на сайте shadowsocks, не нашел подобного
>>3803 (OP) Думаю, твой вариант это OpenVPN через UDP завернутый в TLS или HTTP туннель. Мультиплексором c перенаправлением по url или basic auth могут выступать nginx, haproxy.
Примеры настройки обычно выложены в редми/вики на гитхабе.
Шифровать sni или нет не принципиально, мы ведь хотим выглядеть как легитимный траффик без мысли скрывать что-либо. Вариант dpi как в китае и анализом каждого коннекта с пробами нейросетью недостижим для РФ в ближайшем будущем. В случае серьезной движухи мы скорее пойдем по белорусскому сценарию, где будут в приоритете plain-http и p2p туннели - v2ray и psiphon соответственно, вплоть до белого списка по протоколам или адресам Советую тебе настроить несколько обходных путей и использовать наиболее быстрый, адаптируясь к реалиям, нежели замедлить себе интернет до уровня adsl.
В nekobox запускается outline В firefox прописан сокс5 до некобокса. И чекбокс "резолвить через сокс" пустой. В ОС linux настроен dnscrypt-proxy, google DOH. И илса резолвит через системный ДНС, т.е. у неё в настройках doh выключен.
И вот теперь интересное. При попытке открыть страницу PR_END_OF_FILE_ERROR. Однако, если просто поставить галочку "резолвить через сокс", страницы открываются. Подмена/прослушка DNS исключена - DOH работает исправно, резолв зашифрован, все страницы без прокси открываются ок. И днскрипт я юзаю лет 10 уже. Еще до запиливания доха юзал на предыдущем протоколе.
Дальше ещё интереснее. Если запустить вместо outline VLESS/XTLS-Reality в том же самом некобоксе. То независимо от того, резолвит через прокси или напрямую мимо прокси по DOH - все страницы открываются.
Выглядит так, будто провайдер грохнул аутлайн, но тригерится их фильтр только при наличии DNS запросов, даже через DOH. Но это как-то абсурдно, да и ТТК у меня не сильно увлекается таким. Там есть блокировки по SNI и IP. Хитрых по протоколам нет.
Я вчера обновлял лису и ядро ОС. Возможно сломали что-то. Было бы неплохо, чтобы отписались владельцы своих дистрибутивов.
Если прописывать https прокси вместо сокса, всё работает. Но это потому, что так в любом случае резолвит через туннель.
>>4119 Буквально несколько дней назад видел инфу, что ркн начал блокировать outline, по всей видимости, как-то его детектит. Возможно, проблемы связаны с этим. https://t.me/ctodaily/1739
>>4122 Очень маловероятно. Это был ограниченный эксперимент. А у меня на ТТК вообще DPI не работает. Блочат просто по sni и ip по списку ркн. Я погуглил. На всяких редитах и тд в самые разные годы есть отзывы, что галочка "резолвить через сокс5" помогает (от такой же ошибки в лисе). Но я не могу понять, почему так происходит. И почему это не влияет на vless... Браузер то одинаково обращается по соксу к некобоксу. Это уж далее идет инкапсуляция в разные протоколы. нихуя непонятно. как бы проблемы нет - ладно, пуст ьпо соксу резолвит. Хотя лучше было бы мимо туннеля, чтобы ДНС выдавал айпишинк в соотвесттвии с моим регионом (реальным), а не для страны, где ВПН работает.
>>4124 у друга настроен VPN из андроида через yota до дома. Дома продвинутый роутер стоит. И уже из дома ВПН идёт до ВПН сервера, но пропускает мимо туннеля то, что не заблокировано.
Ну и вот скорость из мобильного интернета домой и потом по проводам быстрее, чем напрямую через ВПН из мобильного. И самый прикол, что и задержки ниже.
>>4119 Всё, дошло до меня. Сегоня глянул в лог подключения и сразу прояснилось, в чём прикол.
Еще раз всё сухо изложу. Клиент nekobox, конфиг для outline, браузер firefox. В ОС настроен dnscrypt-proxy, используется единственный сервер google DOH, через него резолвят все программы и ОС. Если прописать в браузере адрес прокси 127.0.0.1:2080 до некобокса и оставить пустым чекбокс "отправлять dns запросы через прокси", то при открытии НЕКОТОРЫХ сайтов возникает ошибка в браузере PR_END_OF_FILE_ERROR. Если браузер резолвит не через dnscrypt, а через некобокс с галочкой "резолвить через прокси при использовании сокс5", тогда всё ок.
Я сначала не понял в чём дело, потому что через мой VLESS сервер всё открывается ок даже, если браузер резолвит через dnscrypt. А потом до меня дошло. У моего провайдера есть нативный ipv6 (без 6to4 и т.п.). Соответственно и днскрипт возвращает v6 адреса. И всё работало, как с прокси, так и без, пока я не добавил конфиг аутлайна. Потому что на том сервере с аутлайном просто нет ipv6.
Уже не первый раз попадаю на подобное. v6 не хотят внедрять никуда. А у меня он есть. Ну и каждый раз забываю, что я такой особенный.
>>4130 На андроиде всё равно TUN режим используется. Поэтому и резолвить будет через проксю. Но я заметил, что на свежем хуавей мейтпад при настройке DOH (просто добавил dns.google в "частный DNS") резолвит мимо прокси даже в режиме TUN. И вот тут уже поймут не только лишь все, если такая хуйня возникнет, как я описал с лисой и соксом. Симптомы будут те же - сайты с v6 не буду открываться. Но догадаться сложнее.
Но тогда просто убираешь DOH из настроек и резолвить начинает как положено через проксю. Правда тогда без прокси твои запросы становятся видны оператору. Можно, наверное это все учесть и настроить, надо подумать. Но вообще прокси без ipv6 не модно.
Мы тут с товарищем протестировали протокол naive. Он похож на vless/xtls, но в отличие от него добавляет слой шифрования. XTLS не шифрует и если трафик без TLS, то он в открытом виде и шурует. А у naive есть своё шифрование. При этом вроде как сделано по уму и tls in tls он не делает на хендшейках, а поэтому и не палится перед цензором двойным слоем шифрования. При актив пробинге как и vless прикидывается ВЕБ сервером и показывает веб страничку. Но ему нужен caddy, а под nginx он не умеет (vless наоборот под nginx). Юзает библиотеки хрома, чтобы максимально мимикрировать под веб трафик.
Хендшейки (и пинг) быстрее раза в 2-2,5, чем под VLESS. Скорость +/- одинаковая. Процессор naive жрет побольше.
Но есть проблема. UDP этот naive умеет тоьлко через протокол quick. А вот по базовому для него http/2 нихера. Но квик местами в рашке блочат на ростелекоме. Он мешает пидорасам фильтровать трафик. Поэтому если naive, то без udp. Всякие дискорды отваливаются. Но для браузера похуй.
Есть там на гитхабе не официальный пропатченый вариант форвард прокси для нави, который типа даст включить в клиенте некобокс udp в tlcp. Но его года два не обновляли и он уже мог просрать совместимость.
В общем два стула. На одном udp, но можно попалиться на трафике, который передается по http без tls или через торенты, т.к. нет слоя своего шифрования.
Ещё говорят, что есть ShadowTLS. Сначала ведет себя, как VLESS. Создает рукопожатие TLS, как браузер. Потом гонит зашифрованный трафик в носки. Вроде бы DPI по рукопожатию определяет, что это ОК. А дальше претензий к носкам нет, если они свежей версии без уязвимостей, которые были в первой версии.
Эта штука, и шифрует, как naive. И udp пропускает. Но всё же это неопределенный для провайдера трафик в потоке данных. Вряд ли забанят, так как сломают весь интернет. Но понять, что чтото не то, могут.
