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. Читајте го дневникот на клиентот на секој чекор и запрете штом однесувањето се смени.

Менувајте еден елемент по обид. Нова порта, нова обвивка и нова шифра во едно пуштање ве оставаат без можност да кажете која од трите беше важна.