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

Мережі, які дозволяють вихід лише через проксі, — це місце, де робочий профіль раптом помирає. Адреса проксі — найменш цікава змінна в цій невдачі. Усе вирішує форма трафіку, який проксі передаватиме, адже ці проксі передають байтовий потік, а 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

Потім зверніться до місця призначення, яке може обслужити лише тунель, і до імені, на яке може відповісти лише розв'язувач тунелю. Завершене з'єднання через проксі з мертвим тунелем зазвичай означає, що віддалена сторона так і не запропонувала транспорт, названий у вашому профілі.

Запишіть транспорт і приймальний проксі в надійному місці. Коли той самий профіль зазнає невдачі в іншій мережі, ця нотатка за секунди виключить або підтвердить проксі.