Wstunnel + Nginx

Мне попадалась статья, которая сейчас разбросана по разным углам Интернета, но первоначально, похоже была опубликована на Хабре. https://habr.com/ru/post/415977/
В конце статьи описан метод создания туннеля с помощью wstunnel и Nginx. Что вы думаете насчет этого метода. Есть ли похожие реализации, но лучше описанного?
Похоже весь трафик в этом случае будет заворачиваться в туннель. Можно ли завернуть в туннель трафик только к определенным сайтам?

Да, программа v2ray поддерживает туннелирование через множество протоколов: TLS/HTTP2, QUIC, WebSocket. V2ray-клиенты есть под все основные десктопные и мобильные ОС.

V2ray штатно поддерживает эту возможность, но если речь об обычных прокси, то можно использовать, например, файл автоконфигурации, внутри которого написать необходимые правила. Правда, работать будет не во всех программах.

Я вот чего не могу понять. Если просто взять Nginx, настроить его как reverse proxy, соединиться с ним по https и попробовать зайти через него на какой-нибудь заблокированный example.com. sni этого example.com все равно будет виден dpi?

Если вы имеете в виду настройку а-ля man-in-the-middle, т.е. с перешифровкой трафика средствами nginx, то ваш домашний провайдер будет видеть только трафик с тем SNI, к какому домену у вас привязан прокси, а сам nginx будет совершать запросы до example.com со SNI example.com.

Если вы настроили nginx локально, на своём компютере, то так работать не будет: провайдер будет видеть запросы от nginx к example.com.

Нет конечно, не локально. Имеется в виду сервер (VPS) где-то в Интернете. Настройка man-in-the-middle это нетривиальная задача или все можно сделать штатными средствами Nginx?

Не знаю, не настраивал nginx в режиме reverse proxy через HTTPS. Должно быть просто.

Я не особо разбираюсь во всех этих технологиях. Я скорее, как говорят, обычный пользователь ПК. Но если бы все так было легко, почему же тогда этим методом почти никто не пользуется? Ведь все выглядит идеально в теории. Блокировку по IP обойти можно, SNI не виден, соединение по https, то есть оно ничем не примечательно. Нужные сайты можно прописать в hosts, как это сделано было на Рутрекере и остальной трафик пойдет напрямую. Даже соответствующие dns-запросы никуда не идут. Однако же, все изобретают свой велосипед, свои виды обфускации, пытаясь замаскировать трафик под https. В общем, мне кажется это слишком просто, чтобы быть правдой. :slightly_smiling_face:

Это требует корректной настройки, причем от сайта к сайту она может быть разной, и работает только для настроенных сайтов, а не для всех разом.

В статье по вашей ссылке в первом сообщении описывается способ настройки полноценного прокси, но с туннелированием в Websocket, с целью маскировки. Это не то же самое, что реверс-прокси. При желании, можно и OpenVPN через Websocket настроить, и любое другое ПО.

reverse proxy подразумевает, что сервер с nginx также должен выполнять роль удостоверяющего центра, подобно The Great Cloudwall, а в обозреватель должен быть добавлен корневой сертификат УЦ. И даже это далеко не гарантирует связности. TLS очень сложен и крайне глубоко интегрирован в обозреватели, чтобы несовпадение хоть одного параметра не застопорило загрузку, и не стоит забывать, что на reverse proxy придётся позаботиться не только об HTTP, но и например, о проксировании настоящего WebSocket трафика. Ну и конечно, на nginx вы должны настроить eSNI, чтобы скрыть итоговое назначение. В связи с этим, проход через WebSocket выглядит на порядок интереснее, но принципиально не обязателен до тех пор, пока работают и обыкновенные прокси вроде Antizapret.