OpenVPN на 443 все още блокиран? Проверете какво проверява мрежата

Тунелът се свързва от домашна линия и засича в хотелска или офис мрежа, а преместването на сървъра на порт 443 не промени нищо. Този резултат е достатъчно често срещан, за да има форма: портът беше лесната част, а останалата част от решението принадлежи на всичко, което стои между клиента и сървъра. Два въпроса решават повечето случаи и нито един от тях не е за шифри. Приема ли мрежата TLS ръкостискане към този адрес и поддържа ли клиентът маршрут до собствената си обвивка, докато тунелът е вдигнат?

Ръкостискането издава повече от номера

Собствен VPN слушател на TCP 443 говори своя протокол от първия пакет. ClientHello има поле за версия, случайна стойност и списък с разширения, а устройство, което прочете няколкостотин байта, може да различи разликата, без да дешифрира нищо. Номерата на портовете се удовлетворяват евтино, а формата на протокола е това, което филтърът всъщност проверява. Правилата обикновено се пишат и по протокол, така че политика, която инспектира TLS, не казва нищо за UDP.

Прозрачен прокси, който настоява за валидна TLS сесия, прекъсва връзката по време на установяването, често след като TCP ръкостискането завърши. Тази подробност има значение по-късно, защото означава, че клиентският лог спира след установяването на сокета.

Обвиването на потока създава две точки на отказ

TLS обвивка като stunnel възстановява очакваната форма: клиентът се свързва с локален слушател, обвивката отваря истинска TLS сесия към сървъра на 443, а втора обвивка на сървъра препредава дешифрираните байтове към VPN демона. Външната сесия сега изглежда като всяка друга HTTPS връзка. VPN демонът на сървъра трябва да слуша само на loopback, защото нищо извън обвивката не трябва да го достига.

Три отделни неща трябва да съвпаднат за този дизайн. Клиентският профил сочи към локалния слушател, сървърният сертификат съвпада с името, което клиентът проверява, а препращането от страна на сървъра е насочено към порта, който демонът наистина използва. Сгрешете което и да е от тях и връзката умира, преди да се стигне до VPN слоя. Тогава несъответствието на сертификата се появява като грешка на обвивката, а не като VPN грешка, поради което и двата лога си струва да се четат един до друг.

Маршрутът до обвивката е капанът

Щом тунелът се вдигне, маршрутът по подразбиране сочи в него, а външната TLS сесия се нуждае от път, който не влиза в тунела, който тя носи. Обикновеният VPN клиент защитава адреса, който набира; обвитият клиент набира своя собствен loopback, затова адресът на местоназначението на обвивката е невидим за тази защита.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Точните адреси са за попълване от вас, а маршрутът трябва да съществува през целия живот на връзката, не само при стартиране. Малък скрипт обвивка, който добавя маршрута преди клиента и го премахва след това, е по-надежден от запомнена команда.

На Android еквивалентът на това изключение е настройка за всяко приложение: изключете приложението обвивка от тунела, за да излиза собственият му трафик през мобилната връзка. Без изключването обвивката се маршрутизира в тунела, който се опитва да построи, и цикълът на повторно свързване изглежда като проблем на сървъра.

Прочетете времето, преди да промените нещо

Сесия, която умира след един и същ интервал всеки път, е подпис на политика, а не криптографски отказ, и дълготрайните ограничения на потока дават точно такъв модел. Връзка, която се нулира веднага след ръкостискането, подсказва прокси, на което веригата от сертификати не е харесала.

Сравнете издателя на сертификата на обикновен HTTPS сайт от двете мрежи. Ако издателят е различен в ограничената мрежа, нещо прекратява TLS по средата и никаква обвивка няма да оцелее при този прихванат трафик без промяна. Същото сравнение ви казва дали блокът е насочен към името на вашия сървър, или към всяка TLS сесия на този адрес.

Запишете наблюдаваното поведение: колко дълго е траяла сесията, дали сокетът се е отворил, дали обвивката е записала ръкостискане. Всяко от тях стеснява следващия тест.

Проверявайте по една променлива наведнъж

Проверете първо UDP, защото някои мрежи го изхвърлят напълно и UDP отказ не казва нищо за 443. След това опитайте TCP 443 без обвивката, после обвивката на 443. Четете клиентския лог на всяка стъпка и спрете веднага щом поведението се промени.

Променяйте по един елемент на опит. Нов порт, нова обвивка и нов шифър в един и същи пуск не ви оставят да кажете кой от трите е имал значение.