Комментарии 52

А вы уверены, что прокси на себя берёт всё то, что с браузера летит? WebRTC это же только одна ипостася. Есть резолвинг странных имён, пуши и т.д.


Да что там, тупой ftp: на сайте может спалить браузер мимо прокси.
… А какие протоколы ещё ваш браузер умеет?

А вы уверены, что прокси на себя берёт всё то, что с браузера летит? WebRTC это же только одна ипостася. Есть резолвинг странных имён, пуши и т.д.
Да, уверен. В случае использования socks5 надо не забыть поставить галку remote dns.

Да что там, тупой ftp: на сайте может спалить браузер мимо прокси.
… А какие протоколы ещё ваш браузер умеет?
Можете привести пример?
Там у него PAC-файл недоступен вообще, как по мне это нормальное поведение. Неплохо, конечно, что они закрыли это, но я бы не стал ожидать чего-то другого. В предлагаемых мною настройках для HTTPS-прокси PAC-файл задаётся как Data URL и там ошибки такого класса исключены.

Что касается FTP, то никак он адрес не раскрывает, браузеры давно все работают в пассивном режиме протокола FTP. Главным образом чтобы не было вообще никаких потенциальных проблем с NAT-ом.

Я так понял, что если включён DOH, то браузер будет его использовать, чтобы резолвить адрес самого прокси, но далее резолвинг идёт как часть запроса к самому прокси.
Я на Винде использую Proxifier для этого, там и правила можно гибко прописать.
Жутко костыльное и кривое решение как по мне. Самое адекватное решение всё таки VPN и либо роут по умолчанию в тоннель, либо что-то отдельное в тоннель, а что-то в обход.
Знаю, использовал, и proxy auto config со шлюза раздавал для I2P. Но это не работает с приложениями, которые не поддерживают прокси и с протоколами тоже, кроме того на мобильных системах этого вообще нет, а вручную где то лазить это фу, хочется чтобы просто работало ;) Вот VPN это позволяет, на шлюзе по умолчанию просто настраивается маршрутизация чего надо куда надо и всё, клиентам вообще ничего знать не надо.
Badvpn тогда, а еще более лучшее решение — как шэдоусокс-клиента юзать аутлайнВПН (по сути там тоже бэдвпн для тунеллирования) и просто пускать его через апстрим-прокси обфускатор.
Да, Badvpn не плох, я его как то пробовал для человечной прозрачной отдачи I2P и Tor в локалку, но так и не получилось настроить волшебство с DNS, в итоге похоронил идею.

Собственно я вообще не сторонник прокси, VPN на порядки лучше и удобнее.
Зависит от целей и задач. Потоки лучше разделять и не смешивать.
Ну да, я теперь жду когда Tor browser в виде расширения будет доступен в Firefox, тема с прозрачной работой была похоронена так и не реализовавшись как требующая слишком сложной настройки.

Я бы добавил к преимуществам низкое потребление ресурсов а как следствие и электроэнергнии, целый день ходить со включённым OpenVPN весьма накладно для использования батареи, а вот с Outline дело обстоит намного лучше.

И ключевой(для меня) недостаток прокси — требуется его поддержка приложением. VPN позволяет пользоваться не только браузером.

И ключевой(для меня) недостаток прокси — требуется его поддержка приложением.
Не обязательно, есть прозрачные прокси. Мой ptw и rsp умеют такое из коробки, все остальные могут работать через transocks.

VPN позволяет пользоваться не только браузером.
У меня вот прямо сейчас запущены несколько разных мессенджеров, торрент-клиент и почтовый клиент. Все, кроме Viber, поддерживают прокси. Viber почему-то именно на десктопе не поддерживает, хотя на телефоне — да. Тем не менее его бы я как раз через удалённый сервер и не стал заворачивать, чтобы не было ненужных задержек при разговоре.

Скорее наоборот. Приложение должно поддерживать ВАРИАНТЫ. А прокси можно использовать глобально для всей системы. Не знаю как Windows, а вот в Linux — уж точно можно.


image

Ставится какая-нибудь настройка в gconf/dconf и, возможно, ставятся переменные среды *_proxy при запуске десктопных приложений. Совершенно не факт, что все ваши приложения будут это поддерживать, это же Linux :)

В Винде тоже есть глобальный прокси, вот только на системные службы самой Винды он почему-то не распространяется.
С настройками прокси проблема в Android, например. Глобально его можно настроить только для wifi-соединений, индивидуально — только в браузерах.
Есть разный сторонний софт для конфигурирования на системном уровне, но он весь требует рута, что не всегда возможно.
Вот чем:

  1. Поддержка HTTP/2 между клиентом и прокси, и между прокси и целевым веб-сервером.
  2. Есть возможность прятать 407ой ответ, чтобы не давать обнаруживать прокси.
  3. Есть аутентификация клиентов по сертификатам.
  4. Нет кэширования, ненужной буферизации ответов, добавления заголовков Via и X-Forwarded-For. Клиент через dumbproxy начинает получать ответ как можно более оперативно и его не нужно долго и внимательно конфигурировать, чтобы он просто «тупо» форвардил трафик без лишних действий. Он только под это заточен изначально. Проще настроить.
  5. Возможность развёртывания на почти любой платформе/ОС путём запуска единственного статически слинкованного исполняемого файла.


Иными словами, squid это вебкэш из эпохи, когда они были актуальны, а моё решение узкоспециализировано под задачу из поста. Но squid, конечно, имеет массу других возможностей, это большой «комбайн».

Интересно, каков процент людей, которым нужен именно vpn (например, полноценный вход в локалку в офисе), а не просто выход веб браузером (ну или ещё какой конкретной софтиной) через другую точку?

> Интересно, каков процент людей, которым нужен именно vpn
> (например, полноценный вход в локалку в офисе), а не просто
> выход веб браузером (ну или ещё какой конкретной софтиной)
> через другую точку?

Я только для этого VPN и применяю — для доступа в удалённую локальную сеть офиса на любые внутренние компьютеры этой сети по любым портам (vnc там к примеру, да хоть банальный пинг для проверки).

Я в офисной локальной сети на шлюзовом компьютере (FreeBSD) установил VPN-сервер mpd, к которому нормально подключаюсь из винды ейным VPN-клиентом, а из другой FreeBSD — тоже нормально подключаюсь к этому mpd программой ppp (написав для этого соответствующий раздел в /etc/ppp/ppp.conf для VPN-подключения).

Ищу способы подобного подключения к моему VPN-серверу с мобилы:

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

А сторонние VPN-клиенты (из гугловских Плей-маркетов там всяких) почему-то заточены только под какую-то там защиту чего-то да от кого-то. Хотя мне нужна не защита, а просто доступ к внутренним станциям удалённой локальной сети в офисе.
Штатный андроидный VPN-клиент хоть и подключается нормально и даже работает тоже нормально, но ставит пароль на разблокировку экрана.

Что Вы имеете ввиду?
Захожу в Андроиде сюда:
Настройки
Подключения
Другие настройки
VPN
В правом верхнем углу — знак «3 точки, расположенные вертикально»
Добавить профиль VPN

И после этого вижу (см. копию экрана ниже), что перед созданием учётной записи VPN меня пытаются заставить «выбрать тип безопасной блокировки экрана» с двумя вариантами:
ОК (после этого учётную запись VPN создать разрешат)
Отмена (создание учётной записи полностью отменяется)

Вот копия экрана:

image

Если я соглашусь выбрать «тип безопасной блокировки экрана», то созданный после этого VPN-клиент будет нормально подключаться к моему серверу VPN, используя указанные ему в настройках только адрес VPN-сервера, логин и пароль (и никаких там странных и непонятных сертификатов).

Но мне выбирать «тип безопасной блокировки экрана» не надо потому, что после этого блокировку экрана придётся делать не лёгким движением руки, а вводом пароля или какой-то другой мантры, что мне очень неудобно. Приходится отказываться от создания учётной записи VPN на мобиле.
Личные данные на смартфоне должны быть зашифрованы и сам смартфон должен блокироваться. Это стандарт информационной безопасности сейчас, особенно, если вы живете в России.
Это понятно, что за пользователя кто-то другой решил — как ему защищаться: ходить в маске или ставить пароль на экран. Свободы нет давно даже тут. Печаль. :-)
Ещё какая то софтина, их ведь много. Мне нужен мой DNS через тоннель, например, через который, например flibusta.lib резольвится и до сиз пор torrents.ru открывается ) Ну и прочие мелочи которые шлюз разгребает и не требует конских таблиц на устройствах.
Хорошая статья. Прочитал с большим удовольствием. Я бы еще дополнил местами, где можно приобрести недорогие хостинги под это, но это мое мнение.

Автору большое спасибо за статью!
В случае с прокси через TLS, такое соединение можно выдать за обычное HTTPS-соединение. В случае с VPN факт его использования виден даже пассивному DPI. Даже если это Wireguard.
Существуют VPN, которые работают так же через «обычный» TLS — например, SoftEther, AnyConnect/OpenConnect и SSTP и со стороны DPI видны как обычный HTTPS. С помощью некоторых трюков можно так же заставить отвечать вместо них безобидный веб-сайт, чтобы избежать active probing.
Нет целого класса проблем с внезапно прервавшимся VPN-соединением. В худшем сценарии VPN-соединение может прерваться и пользователь не заметит, что его трафик уже не защищён и/или он уже работает со своего «домашнего» IP-адреса.
Решается настройкой маршрутов — удаляется дефолтный роут в системе, прописывается дефолтный роут на шлюз внутри VPN, и отдельный маршрут до VPN-сервера. Тогда при падении туннеля доступ во внешнюю сеть прекращается полностью до возобновления соединения.
Первый способ заключается в том, чтобы использовать аутентификацию клиентов по сертификатам ещё на этапе TLS-рукопожатия. Это самый стойкий метод, и это действительно корректная причина, по которой любой обычный веб-сервер мог бы отвергнуть клиента.
Не нашел в вашей инструкции по конфигурированию клиентов dumbproxy ничего про клиентские сертификаты, можно подробнее?
Существуют VPN, которые работают так же через «обычный» TLS — например, SoftEther, AnyConnect/OpenConnect и SSTP и со стороны DPI видны как обычный HTTPS. С помощью некоторых трюков можно так же заставить отвечать вместо них безобидный веб-сайт, чтобы избежать active probing.
Вопрос только в том, как это сделать.

Я экспериментировал с SSTP и ставил перед сервером haproxy, который в начальном состоянии маршрутизирует входящее соединение на веб-сервер (который тоже встроен в haproxy). При поступлении особого запроса (который извне не читаем из-за TLS) он запоминает адрес клиента и дальше маршрутизирует соединения от него на SSTP-бэкенд. Получилась примерно такая конфигурация:

frontend sstp
bind 10.19.0.5:443 ssl crt /etc/haproxy/example.com.combined.pem
acl allowed src,map_ip(/etc/haproxy/wl_map.txt) 1
use_backend sstp-server if allowed
default_backend sstp-decoy

backend sstp-decoy
server decoy 127.0.0.1:41720 send-proxy-v2

frontend sstp-decoy
bind 127.0.0.1:41720 accept-proxy
mode http
http-request set-map(/etc/haproxy/wl_map.txt) %[src] 1 if { path /mysecretlocation }
http-request deny deny_status 400

backend sstp-server
server sstp 127.0.0.1:4433

Решение всё равно получается неполноценное, потому что если активные пробы осуществляются с того же адреса, с которого приходит клиент, то всё равно можно будет увидеть начало диалога SSTP после того, как клиент пошлёт секретный запрос. Но, тем не менее, это уже кое-что и такой сервер будет работать со стандартным SSTP в винде. Чтобы это работало полноценно, такое переключение должно происходить в рамках одного соединения, а со стандартными клиентами SSTP такого добиться не получится.

И даже если это всё проделать, на выходе получится тормозной VPN, работающий через один TCP-коннект.

Решается настройкой маршрутов — удаляется дефолтный роут в системе, прописывается дефолтный роут на шлюз внутри VPN, и отдельный маршрут до VPN-сервера. Тогда при падении туннеля доступ во внешнюю сеть прекращается полностью до возобновления соединения.
Да, эта проблема решаемая. Кроме этой, есть ещё проблема с DNS leak, в особенности на винде: VPN-клиент добавляет свои DNS-серверы, но винда может пройтись по всем сконфигурированным DNS-серверами, посылая запрос мимо туннеля в DNS-сервер в локальной сети. А у прокси всех этих проблем просто нет.

Не нашел в вашей инструкции по конфигурированию клиентов dumbproxy ничего про клиентские сертификаты, можно подробнее?
Сначала нужно сгенерировать сертификаты для клиентов. Я обычно использую свой же quickcerts. Затем на сервере нужно указать параметры -cert, -key, -cafile, где сертификат и ключ — любой ваш сертификат для TLS, а cafile — сертификат CA, которым выпущены серты для клиентов. Кроме этого, нужно выставить параметр -auth в значение cert://
Далее есть два варианта:
  • Установить клиентский сертификат прямо в браузер и дальше настройка как обычно. У меня в Firefox и вроде бы даже в Chrome это работало, но я наблюдал кое-какие странности в поведении браузеров.
  • Запустить steady-tun или ptw на клиенте, указав в нём клиентский сертификат и адрес сервера, а браузер уже настроить на подключение к локальному порту steady-tun или ptw как к обычному HTTP-прокси без TLS.
Я экспериментировал с SSTP и ставил перед сервером haproxy, который в начальном состоянии маршрутизирует входящее соединение на веб-сервер (который тоже встроен в haproxy). При поступлении особого запроса (который извне не читаем из-за TLS) он запоминает адрес клиента и дальше маршрутизирует соединения от него на SSTP-бэкенд.
Я делал примерно так же, использовал https-нокер, который применял правила фаервола, и переадресовывал входящие подключения на 443 с заданного IP на локальный порт VPN-сервера в течении 15 секунд, чего было достаточно для установления соединения. Если все юзеры провайдера вместе с DPI не сидят за одним NAT'ом, либо же active probing происходит не мгновенно сразу же, то эта схема получается весьма надежной.
Из других вариантов:
— линуховый sstp-сервер можно запускать в режиме no-ssl, а TLS-подключение принимать тем же stunnel, и давать отлуп клиентам с неподходящим сертификатом;
— дождаться повсеместного введения TLS1.3 с eSNI и разруливать всё nginx'ом с ngx_stream_ssl_preread_module — и тогда «секретом» будет имя хоста, коннекты к правильному хостнейму перекидываются на VPN, остальным показывается сайт-заглушка; со стороны имя хоста не видно, т.к. зашифровано.
И даже если это всё проделать, на выходе получится тормозной VPN, работающий через один TCP-коннект.
SSTP у меня между городком в Поволжье и VPN-сервером в восточной Европе вполне спокойно выжимал 30-40 мегабит в обе стороны, чего более чем достаточно для повседневных нужд.
AnyConnect/OpenConnect после успешной аутентификации по HTTPS умеет устанавливать DTLS-линк (UDP) для более эффективного транспорта. DTLS со стороны выглядит, опять же, вполне безобидно, он, например, используется в WebRTC.
Кроме этой, есть ещё проблема с DNS leak, в особенности на винде: VPN-клиент добавляет свои DNS-серверы, но винда может пройтись по всем сконфигурированным DNS-серверами, посылая запрос мимо туннеля в DNS-сервер в локальной сети.
Тоже чинится довольно просто — на дефолтном интерфейсе ставим в качестве DNS либо некорректный адрес в локалке, либо IP-адрес dnsmasq внутри VPN-подсети (фиг знает, будет ли через него резолвится, но по крайней мере во внешнюю сеть запрос не уйдет), к VPN подключаемся по IP, либо прописываем его имя в hosts.
дождаться повсеместного введения TLS1.3 с eSNI и разруливать всё nginx'ом с ngx_stream_ssl_preread_module — и тогда «секретом» будет имя хоста, коннекты к правильному хостнейму перекидываются на VPN, остальным показывается сайт-заглушка; со стороны имя хоста не видно, т.к. зашифровано

уже сейчас часть этого можно реализовать с помощью Shadowsocks, v2ray и Nginx (без eSNI, т.к. его не хотят еще пилить в Go).
О чем вы говорите, автор тестит голый СС и думает что он плохо работает, какой в2рей
Без eSNI это не имеет смысла — хостнейм передается в открытом виде, и следовательно active probing по нему же и стукнется. Или вы еще какое-то звено не упомянули в своей цепочке?
v2ray, например, насколько я помню, умеет заворачиваться в websockets — вот это очень хороший вариант выходит, плюс можно даже немного понаглеть и задействовать cloudflare :)
> Гибкость. Проще настроить избирательное проксирование.
> Использование прокси можно ограничить конкретными приложениями

Возможность использования прокси только для конкретных протоколов (обычно, как это изначально и было в старину, для http) является нщё и недостатком по сравнению с vpn. Ведь через vpn подключается канал связи по любым протоколам (это же очень удобно), а прокси предоставляет доступ только по некоторым протоколам.

А какой прокси клиент посоветуете? на андроид, чтоб без сложных настроек, рута нет .

На андроиде есть клиент HTTPS-прокси Drony, который имитирует VPN и может заворачивать все TCP-соединения любых приложений через прокси. Но он не очень удобный, его муторно настраивать и я пока так и не понял, как заставить его не отправлять DNS-запросы напрямую.

Есть ещё системная настройка прокси в Андроиде, но это вариант нерабочий по сути: какие-то приложения будут посылать какую-то часть трафика через прокси, что-то будет идти напрямую.

Лучшее, что доступно на андроиде и нормально работает — это VPN-клиент Wireguard. Возможно, если у меня наберётся достаточно материала, я напишу пост про то, как можно использовать Wireguard и получить дополнительные преимущества по скорости как у прокси путём прозрачного проксирования TCP-соединений на сервере Wireguard.
Ваергард не соответствует вашему критерию «устойчивости к DPI» от слова совсем. Вы определитесь, вам или устойчивость и обфускацию надо, или что-то еще. Потому что ваергард, это не про то.
Я и не говорил, что соответствует, в статье ровно обратное написано. Просто лучше вариантов нет.

Как это нет, когда все есть и вполне успешно работает, без какой-либо необходимости изобретать велосипед. И даже имеет огромное коммьюнити.

Я упоминал это в статье, но если Вы не читали, то вот: github.com/net4people/bbs/issues/22

Что же касается shadowsocks с v2ray-плагином — в режиме HTTP он так же подвержен активным пробам, потому что сторонний наблюдатель так же сможет воспроизвести то, что видел в открытых фрэймах вебсокета.

В режиме HTTPS всё вроде бы неплохо, но возникает вопрос: а зачем сам shadowsocks в этой схеме, если сокрытие начала диалога возложено на TLS? Вот он и есть как раз велосипед, в итоге, который сам по себе провалился с точки зрения цензуроустойчивости, но может использоваться под TLS. А под TLS и стандартный HTTP-прокси отлично работает, который в браузерах из коробки поддерживается.

Я конечно читал, вот только это не актуально для России. Для Китая — да, для России — нет. Это китайцам приходится прорываться сквозь Золотой щит, это у них прокси обнаруживаются с помощью зондирования и блокируются. У нас такой проблемы нет. У вас несколько надуманная модель угроз.
А что, если я скажу, что вы со своими прокси не защищены от атак сопоставлением? Тогда нет смысла в любом вашем методе, ведь с помощью пакета Яровой вас все равно вычислят.
По поводу зачем вообще в схеме shadowsocks? Так только из-за удобства. Вы мобильные клиенты написали под свои решения или предлагаете в Android сидеть из под shell? А в iOS?

Я конечно читал, вот только это не актуально для России. Для Китая — да, для России — нет. Это китайцам приходится прорываться сквозь Золотой щит, это у них прокси обнаруживаются с помощью зондирования и блокируются. У нас такой проблемы нет. У вас несколько надуманная модель угроз.
Ну значит тогда в России и shadowsocks не нужен, так получается?

А что, если я скажу, что вы со своими прокси не защищены от атак сопоставлением?
Сказать-то легко, доказать трудно.
Вы не поняли: речь шла о связке shadowsocks+v2ray, вы же ее назвали «велосипедом». Сам shadowsocks отлично и шифрует, и мультиплексирует, и скорость не режет, и работает на всех платформах.
Так про мобильные клиенты: есть или нет? Получается какое-то половинчатое решение у вас.
Сказать-то легко, доказать трудно.

Докажите наличие active probing в России.
Вы не поняли: речь шла о связке shadowsocks+v2ray, вы же ее назвали «велосипедом». Сам shadowsocks отлично и шифрует, и мультиплексирует, и скорость не режет, и работает на всех платформах.
Так про мобильные клиенты: есть или нет? Получается какое-то половинчатое решение у вас.
Сам он не отлично шифрует и легко провалился. А при зависимости от TLS он и не нужен как протокол. Да, клиенты shadowsocks на телефоны сейчас есть, для HTTPS-прокси тоже есть, но плохие. Тем не менее, это не отменяет ущербности shadowsocks как протокола.

Докажите наличие active probing в России.
Я такого утверждения не делал, но при этом не считаю правильным дожидаться, когда active probing появится. А Вам своё заявление подкрепить нечем, я так понимаю?
Я такого утверждения не делал

Значит и смысла никакого нет заворачивать прокси в TLS.
Сам он не отлично шифрует и легко провалился

Легко — это проработав 4 года без блокировки в Китае?
Тем не менее, это не отменяет ущербности shadowsocks как протокола.

Конечно, ss ущербен, именно поэтому им пользуются до сих пор по всему миру, да, прикрутив плагин для TLS в Китае.
У нас такой проблемы нет.
Вы забыли слово «пока». "Пока нет".
Что же касается shadowsocks с v2ray-плагином — в режиме HTTP он так же подвержен активным пробам, потому что сторонний наблюдатель так же сможет воспроизвести то, что видел в открытых фрэймах вебсокета.


Можно использовать симпл-обфс с включенным фейловером на локальный nginx.

Вопрос в другом. Если вас активно тыкают палочкой в ручном режиме, вам уже ничего не поможет.

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

Shadowsocks в данной связке выступает как прокси — роутит ваш трафик между клиентом и сервером, имея минимальный оверхед. Чисто теоретически можете через в2рей-плагин хоть опенВПН пускать, хоть данте, только нафига? А сам по себе в2рей-плагин это просто враппер для трафика.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.