Защищённые прокси — практичная альтернатива VPN

Я на Винде использую Proxifier для этого, там и правила можно гибко прописать.

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

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

VPN позволяет пользоваться не только браузером.

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

Вот чем:

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

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

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

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

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