SOCKS5-прокси для OpenVPN: TCP-туннель или проксирование приложений?

Прокси передаёт поток, а не датаграмму. Сравните TCP-туннель за socks-proxy с перенаправлением redsocks и посмотрите, где каждый вариант ломается первым.

Сети, которые разрешают исходящий трафик только через прокси, — это место, где рабочий профиль внезапно умирает. Адрес прокси — наименее интересная переменная в этой поломке. Всё решает форма трафика, который прокси будет передавать, потому что эти прокси передают байтовый поток, а UDP-туннель им не является. Остаются две архитектуры, и ломаются они в разных местах.

Одно ограничение определяет схему

SOCKS5 действительно определяет режим UDP-ассоциации. Поддержка прокси в клиенте OpenVPN тем не менее построена вокруг потоков: socks-proxy документирован для профилей TCP, а у прокси HTTP CONNECT вообще нет пути для датаграмм. Одна строка документации решает архитектуру ещё до того, как вы откроете файл конфигурации.

Стало быть, вопрос не в том, какой прокси выбрать. А в том, станет ли туннель потоком или останется датаграммой и позволит чему-то другому взять на себя проксирование.

Вариант A: превратить туннель в поток

Для этого нужен сервер с TCP-слушателем и клиентский профиль, в котором указан прокси. Нужны обе части, и именно серверную сторону люди забывают:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Замените последнюю строку на http-proxy proxy.internal 8080, если прокси говорит по HTTP, и добавьте файл учётных данных, если он его требует. Прокси должен быть готов выполнить CONNECT на ваш порт VPN, а сервер должен отвечать по TCP; слушатель только на UDP эту попытку игнорирует. Выбор 443 — практичный ход, потому что многие ограничивающие сети разрешают его и почти ничего другого.

Цена — TCP поверх TCP. Один потерянный внешний сегмент останавливает каждый внутренний поток, использующий это соединение, поэтому восстановление, обычно независимое, становится общим. Настройка тоже занимает больше времени, а нестабильный внешний путь превращается в нестабильный туннель, а не в медленный.

Вариант B: оставить туннель в покое

Когда туннель должен остаться на UDP, настраивать что-либо нужно не в туннеле. Вместо этого исходящий TCP от приложений перенаправляется на локальный слушатель SOCKS, и приложения никогда не узнают, что прокси существует. В Linux это обычно redsocks плюс правило NAT REDIRECT в таблице nat.

Опять только TCP. Прокси только для HTTP вроде privoxy не может передавать произвольные протоколы, и эта схема не добавляет приложениям поддержку датаграмм.

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

Где ломается каждый вариант

Вариант A ломается, когда на сервере нет TCP-слушателя, когда прокси отказывает в цели CONNECT или когда внешний поток ограничен ниже того, что нужно туннелю. Первые два оставляют запись в журнале прокси; третий оставляет соединение, которое устанавливается и затем кажется неправильным. Прочитайте этот журнал перед правкой профиля, потому что он отделяет проблему прав от проблемы пропускной способности. Завершённый CONNECT переносит расследование внутрь туннеля.

Вариант B ломается для всего, что требует датаграмм, для протоколов, которых прокси не понимает, и молча на хостах, где правило перенаправления есть, но маршрутизация ведёт трафик мимо него.

Ни один вариант не меняет требование к устройству. Пакетам по-прежнему нужен узел TUN или TAP, прежде чем ядро их направит, поэтому процессу по-прежнему нужно разрешение на /dev/net/tun. Обёртка меняет то, что происходит после открытия этого узла, а не то, нужен ли он вам.

Докажите, какой путь вы построили

Смотрите на сокеты, а не на значок в трее. Процесс VPN должен держать установленное соединение с адресом прокси, а прокси должен был зарегистрировать цель, до которой его просили добраться:

ss -tnp | grep openvpn

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

Запишите транспорт и принимающий прокси в надёжном месте. Когда тот же профиль откажет в другой сети, эта заметка за секунды исключит или подтвердит прокси.

Похожие статьи