Комментарии 52
А вы уверены, что прокси на себя берёт всё то, что с браузера летит? WebRTC это же только одна ипостася. Есть резолвинг странных имён, пуши и т.д.
Да что там, тупой ftp: на сайте может спалить браузер мимо прокси.
… А какие протоколы ещё ваш браузер умеет?
А вы уверены, что прокси на себя берёт всё то, что с браузера летит? WebRTC это же только одна ипостася. Есть резолвинг странных имён, пуши и т.д.Да, уверен. В случае использования socks5 надо не забыть поставить галку remote dns.
Да что там, тупой ftp: на сайте может спалить браузер мимо прокси.Можете привести пример?
… А какие протоколы ещё ваш браузер умеет?
\mydomain.com\for\ie, это что я с ходу придумать могу. Покопался, 5 лет назад FF перепосылал запрос без прокси, если прокся не доступна (https://bugzilla.mozilla.org/show_bug.cgi?id=1207798)
Кстати, а DOH уважает прокси или нет?
Там у него PAC-файл недоступен вообще, как по мне это нормальное поведение. Неплохо, конечно, что они закрыли это, но я бы не стал ожидать чего-то другого. В предлагаемых мною настройках для HTTPS-прокси PAC-файл задаётся как Data URL и там ошибки такого класса исключены.
Что касается FTP, то никак он адрес не раскрывает, браузеры давно все работают в пассивном режиме протокола FTP. Главным образом чтобы не было вообще никаких потенциальных проблем с NAT-ом.
Я так понял, что если включён DOH, то браузер будет его использовать, чтобы резолвить адрес самого прокси, но далее резолвинг идёт как часть запроса к самому прокси.
Что касается FTP, то никак он адрес не раскрывает, браузеры давно все работают в пассивном режиме протокола FTP. Главным образом чтобы не было вообще никаких потенциальных проблем с NAT-ом.
Я так понял, что если включён DOH, то браузер будет его использовать, чтобы резолвить адрес самого прокси, но далее резолвинг идёт как часть запроса к самому прокси.
Я на Винде использую Proxifier для этого, там и правила можно гибко прописать.
Жутко костыльное и кривое решение как по мне. Самое адекватное решение всё таки VPN и либо роут по умолчанию в тоннель, либо что-то отдельное в тоннель, а что-то в обход.
Про глобальный прокси в Винде не слышали?
Знаю, использовал, и proxy auto config со шлюза раздавал для I2P. Но это не работает с приложениями, которые не поддерживают прокси и с протоколами тоже, кроме того на мобильных системах этого вообще нет, а вручную где то лазить это фу, хочется чтобы просто работало ;) Вот VPN это позволяет, на шлюзе по умолчанию просто настраивается маршрутизация чего надо куда надо и всё, клиентам вообще ничего знать не надо.
Badvpn тогда, а еще более лучшее решение — как шэдоусокс-клиента юзать аутлайнВПН (по сути там тоже бэдвпн для тунеллирования) и просто пускать его через апстрим-прокси обфускатор.
Я бы добавил к преимуществам низкое потребление ресурсов а как следствие и электроэнергнии, целый день ходить со включённым OpenVPN весьма накладно для использования батареи, а вот с Outline дело обстоит намного лучше.
И ключевой(для меня) недостаток прокси — требуется его поддержка приложением. VPN позволяет пользоваться не только браузером.
И ключевой(для меня) недостаток прокси — требуется его поддержка приложением.Не обязательно, есть прозрачные прокси. Мой ptw и rsp умеют такое из коробки, все остальные могут работать через transocks.
VPN позволяет пользоваться не только браузером.У меня вот прямо сейчас запущены несколько разных мессенджеров, торрент-клиент и почтовый клиент. Все, кроме Viber, поддерживают прокси. Viber почему-то именно на десктопе не поддерживает, хотя на телефоне — да. Тем не менее его бы я как раз через удалённый сервер и не стал заворачивать, чтобы не было ненужных задержек при разговоре.
Ставится какая-нибудь настройка в gconf/dconf и, возможно, ставятся переменные среды *_proxy при запуске десктопных приложений. Совершенно не факт, что все ваши приложения будут это поддерживать, это же Linux :)
В Винде тоже есть глобальный прокси, вот только на системные службы самой Винды он почему-то не распространяется.
Чем ваша реализация лучше squid-ssl?
wiki.squid-cache.org/Features/HTTPS#Encrypted_browser-Squid_connection
wiki.squid-cache.org/Features/HTTPS#Encrypted_browser-Squid_connection
Вот чем:
Иными словами, squid это вебкэш из эпохи, когда они были актуальны, а моё решение узкоспециализировано под задачу из поста. Но squid, конечно, имеет массу других возможностей, это большой «комбайн».
- Поддержка HTTP/2 между клиентом и прокси, и между прокси и целевым веб-сервером.
- Есть возможность прятать 407ой ответ, чтобы не давать обнаруживать прокси.
- Есть аутентификация клиентов по сертификатам.
- Нет кэширования, ненужной буферизации ответов, добавления заголовков Via и X-Forwarded-For. Клиент через dumbproxy начинает получать ответ как можно более оперативно и его не нужно долго и внимательно конфигурировать, чтобы он просто «тупо» форвардил трафик без лишних действий. Он только под это заточен изначально. Проще настроить.
- Возможность развёртывания на почти любой платформе/ОС путём запуска единственного статически слинкованного исполняемого файла.
Иными словами, squid это вебкэш из эпохи, когда они были актуальны, а моё решение узкоспециализировано под задачу из поста. Но squid, конечно, имеет массу других возможностей, это большой «комбайн».
Интересно, каков процент людей, которым нужен именно vpn (например, полноценный вход в локалку в офисе), а не просто выход веб браузером (ну или ещё какой конкретной софтиной) через другую точку?
> Интересно, каков процент людей, которым нужен именно vpn
> (например, полноценный вход в локалку в офисе), а не просто
> выход веб браузером (ну или ещё какой конкретной софтиной)
> через другую точку?
Я только для этого VPN и применяю — для доступа в удалённую локальную сеть офиса на любые внутренние компьютеры этой сети по любым портам (vnc там к примеру, да хоть банальный пинг для проверки).
Я в офисной локальной сети на шлюзовом компьютере (FreeBSD) установил VPN-сервер mpd, к которому нормально подключаюсь из винды ейным VPN-клиентом, а из другой FreeBSD — тоже нормально подключаюсь к этому mpd программой ppp (написав для этого соответствующий раздел в /etc/ppp/ppp.conf для VPN-подключения).
Ищу способы подобного подключения к моему VPN-серверу с мобилы:
Штатный андроидный 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 создать разрешат)
Отмена (создание учётной записи полностью отменяется)
Вот копия экрана:
Если я соглашусь выбрать «тип безопасной блокировки экрана», то созданный после этого VPN-клиент будет нормально подключаться к моему серверу VPN, используя указанные ему в настройках только адрес VPN-сервера, логин и пароль (и никаких там странных и непонятных сертификатов).
Но мне выбирать «тип безопасной блокировки экрана» не надо потому, что после этого блокировку экрана придётся делать не лёгким движением руки, а вводом пароля или какой-то другой мантры, что мне очень неудобно. Приходится отказываться от создания учётной записи VPN на мобиле.
Настройки
Подключения
Другие настройки
VPN
В правом верхнем углу — знак «3 точки, расположенные вертикально»
Добавить профиль VPN
И после этого вижу (см. копию экрана ниже), что перед созданием учётной записи VPN меня пытаются заставить «выбрать тип безопасной блокировки экрана» с двумя вариантами:
ОК (после этого учётную запись VPN создать разрешат)
Отмена (создание учётной записи полностью отменяется)
Вот копия экрана:
Если я соглашусь выбрать «тип безопасной блокировки экрана», то созданный после этого VPN-клиент будет нормально подключаться к моему серверу VPN, используя указанные ему в настройках только адрес VPN-сервера, логин и пароль (и никаких там странных и непонятных сертификатов).
Но мне выбирать «тип безопасной блокировки экрана» не надо потому, что после этого блокировку экрана придётся делать не лёгким движением руки, а вводом пароля или какой-то другой мантры, что мне очень неудобно. Приходится отказываться от создания учётной записи VPN на мобиле.
Ещё какая то софтина, их ведь много. Мне нужен мой DNS через тоннель, например, через который, например flibusta.lib резольвится и до сиз пор torrents.ru открывается ) Ну и прочие мелочи которые шлюз разгребает и не требует конских таблиц на устройствах.
Хорошая статья. Прочитал с большим удовольствием. Я бы еще дополнил местами, где можно приобрести недорогие хостинги под это, но это мое мнение.
Автору большое спасибо за статью!
Автору большое спасибо за статью!
Существуют 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.
дождаться повсеместного введения TLS1.3 с eSNI и разруливать всё nginx'ом с ngx_stream_ssl_preread_module — и тогда «секретом» будет имя хоста, коннекты к правильному хостнейму перекидываются на VPN, остальным показывается сайт-заглушка; со стороны имя хоста не видно, т.к. зашифровано
уже сейчас часть этого можно реализовать с помощью Shadowsocks, v2ray и Nginx (без eSNI, т.к. его не хотят еще пилить в Go).
О чем вы говорите, автор тестит голый СС и думает что он плохо работает, какой в2рей
с eSNI было бы идеально, но еще нет стандарта
> Гибкость. Проще настроить избирательное проксирование.
> Использование прокси можно ограничить конкретными приложениями
Возможность использования прокси только для конкретных протоколов (обычно, как это изначально и было в старину, для http) является нщё и недостатком по сравнению с vpn. Ведь через vpn подключается канал связи по любым протоколам (это же очень удобно), а прокси предоставляет доступ только по некоторым протоколам.
> Использование прокси можно ограничить конкретными приложениями
Возможность использования прокси только для конкретных протоколов (обычно, как это изначально и было в старину, для http) является нщё и недостатком по сравнению с vpn. Ведь через vpn подключается канал связи по любым протоколам (это же очень удобно), а прокси предоставляет доступ только по некоторым протоколам.
А какой прокси клиент посоветуете? на андроид, чтоб без сложных настроек, рута нет .
На андроиде есть клиент HTTPS-прокси Drony, который имитирует VPN и может заворачивать все TCP-соединения любых приложений через прокси. Но он не очень удобный, его муторно настраивать и я пока так и не понял, как заставить его не отправлять DNS-запросы напрямую.
Есть ещё системная настройка прокси в Андроиде, но это вариант нерабочий по сути: какие-то приложения будут посылать какую-то часть трафика через прокси, что-то будет идти напрямую.
Лучшее, что доступно на андроиде и нормально работает — это VPN-клиент Wireguard. Возможно, если у меня наберётся достаточно материала, я напишу пост про то, как можно использовать Wireguard и получить дополнительные преимущества по скорости как у прокси путём прозрачного проксирования TCP-соединений на сервере Wireguard.
Есть ещё системная настройка прокси в Андроиде, но это вариант нерабочий по сути: какие-то приложения будут посылать какую-то часть трафика через прокси, что-то будет идти напрямую.
Лучшее, что доступно на андроиде и нормально работает — это VPN-клиент Wireguard. Возможно, если у меня наберётся достаточно материала, я напишу пост про то, как можно использовать Wireguard и получить дополнительные преимущества по скорости как у прокси путём прозрачного проксирования TCP-соединений на сервере Wireguard.
Ваергард не соответствует вашему критерию «устойчивости к DPI» от слова совсем. Вы определитесь, вам или устойчивость и обфускацию надо, или что-то еще. Потому что ваергард, это не про то.
Я и не говорил, что соответствует, в статье ровно обратное написано. Просто лучше вариантов нет.
Как это нет, когда все есть и вполне успешно работает, без какой-либо необходимости изобретать велосипед. И даже имеет огромное коммьюнити.
Я упоминал это в статье, но если Вы не читали, то вот: github.com/net4people/bbs/issues/22
Что же касается shadowsocks с v2ray-плагином — в режиме HTTP он так же подвержен активным пробам, потому что сторонний наблюдатель так же сможет воспроизвести то, что видел в открытых фрэймах вебсокета.
В режиме HTTPS всё вроде бы неплохо, но возникает вопрос: а зачем сам shadowsocks в этой схеме, если сокрытие начала диалога возложено на TLS? Вот он и есть как раз велосипед, в итоге, который сам по себе провалился с точки зрения цензуроустойчивости, но может использоваться под TLS. А под TLS и стандартный HTTP-прокси отлично работает, который в браузерах из коробки поддерживается.
Что же касается shadowsocks с v2ray-плагином — в режиме HTTP он так же подвержен активным пробам, потому что сторонний наблюдатель так же сможет воспроизвести то, что видел в открытых фрэймах вебсокета.
В режиме HTTPS всё вроде бы неплохо, но возникает вопрос: а зачем сам shadowsocks в этой схеме, если сокрытие начала диалога возложено на TLS? Вот он и есть как раз велосипед, в итоге, который сам по себе провалился с точки зрения цензуроустойчивости, но может использоваться под TLS. А под TLS и стандартный HTTP-прокси отлично работает, который в браузерах из коробки поддерживается.
Я конечно читал, вот только это не актуально для России. Для Китая — да, для России — нет. Это китайцам приходится прорываться сквозь Золотой щит, это у них прокси обнаруживаются с помощью зондирования и блокируются. У нас такой проблемы нет. У вас несколько надуманная модель угроз.
А что, если я скажу, что вы со своими прокси не защищены от атак сопоставлением? Тогда нет смысла в любом вашем методе, ведь с помощью пакета Яровой вас все равно вычислят.
По поводу зачем вообще в схеме shadowsocks? Так только из-за удобства. Вы мобильные клиенты написали под свои решения или предлагаете в Android сидеть из под shell? А в iOS?
Я конечно читал, вот только это не актуально для России. Для Китая — да, для России — нет. Это китайцам приходится прорываться сквозь Золотой щит, это у них прокси обнаруживаются с помощью зондирования и блокируются. У нас такой проблемы нет. У вас несколько надуманная модель угроз.Ну значит тогда в России и shadowsocks не нужен, так получается?
А что, если я скажу, что вы со своими прокси не защищены от атак сопоставлением?Сказать-то легко, доказать трудно.
Вы не поняли: речь шла о связке shadowsocks+v2ray, вы же ее назвали «велосипедом». Сам shadowsocks отлично и шифрует, и мультиплексирует, и скорость не режет, и работает на всех платформах.
Так про мобильные клиенты: есть или нет? Получается какое-то половинчатое решение у вас.
Докажите наличие active probing в России.
Так про мобильные клиенты: есть или нет? Получается какое-то половинчатое решение у вас.
Сказать-то легко, доказать трудно.
Докажите наличие 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рей-плагин это просто враппер для трафика.
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Защищённые прокси — практичная альтернатива VPN