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

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