OpenVPN a 443-on még mindig blokkolva? Nézze meg, mit vizsgál a hálózat

Az alagút otthoni vonalról csatlakozik, majd elakad egy hotel- vagy irodai hálózaton, és a kiszolgáló 443-as portra költöztetése semmit sem változtatott. Ez az eredmény elég gyakori ahhoz, hogy legyen formája: a port volt a könnyű rész, a döntés többi része pedig mindenhez tartozik, ami az ügyfél és a kiszolgáló között ül. Két kérdés dönti el a legtöbb esetet, és egyik sem a titkosítókról szól. Elfogad-e a hálózat egy TLS-kézfogást arra a címre, és tart-e az ügyfél útvonalat a saját burkolójához, amíg az alagút áll?

A kézfogás többet árul el a számnál

Egy natív VPN-hallgató a TCP 443-on az első csomagtól a saját protokollját beszéli. A ClientHello-nak van verziómezője, véletlen értéke és bővítménylistája, és egy eszköz, amely néhány száz bájtot olvas, minden visszafejtés nélkül felismeri a különbséget. A portszámokat olcsó kielégíteni, és a szűrő valójában a protokoll formáját ellenőrzi. A szabályokat általában protokollonként is írják, ezért a TLS-t vizsgáló házirend semmit sem mond az UDP-ről.

Egy átlátszó proxy, amely érvényes TLS-munkamenetet követel, a beállítás közben eldobja a kapcsolatot, gyakran azután, hogy a TCP-kézfogás befejeződött. Ez a részlet később számít, mert azt jelenti, hogy az ügyfélnapló a socket létrejötte után megáll.

A folyam beburkolása két hibapontot hoz létre

Egy TLS-burkoló, például a stunnel, visszaállítja a várt formát: az ügyfél egy helyi hallgatóhoz csatlakozik, a burkoló valódi TLS-munkamenetet nyit a kiszolgálóhoz a 443-on, a kiszolgálón lévő második burkoló pedig továbbítja a visszafejtett bájtokat a VPN-démonnak. A külső munkamenet most úgy néz ki, mint bármely más HTTPS-kapcsolat. A kiszolgálón futó VPN-démon csak loopbacken hallgasson, mert a burkolón kívül semminek nem kell elérnie.

Három külön dolognak kell összeérnie ehhez a felépítéshez. Az ügyfélprofil a helyi hallgatóra mutat, a kiszolgálótanúsítvány megfelel annak a névnek, amelyet az ügyfél ellenőriz, és a kiszolgáló oldali továbbítás azt a portot célozza, amelyet a démon valóban használ. Ha bármelyiket elrontja, a kapcsolat még a VPN-réteg elérése előtt meghal. Ekkor a tanúsítvány-eltérés burkolóhibaként jelenik meg, nem VPN-hibaként, és ezért érdemes a két naplót egymás mellett olvasni.

A burkolóhoz vezető útvonal a csapda

Amint az alagút feláll, az alapértelmezett útvonal bele mutat, és a külső TLS-munkamenetnek olyan útra van szüksége, amely nem lép be a szállított alagútba. Egy közönséges VPN-ügyfél védi a címet, amelyet tárcsáz; a burkolt ügyfél a saját loopbackjét tárcsázza, ezért a burkoló célcíme láthatatlan ennek a védelemnek.

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

A pontos címeket Ön tölti ki, és az útvonalnak a kapcsolat teljes élettartama alatt léteznie kell, nem csak indításkor. Egy kis burkolószkript, amely az ügyfél előtt hozzáadja, utána pedig eltávolítja az útvonalat, megbízhatóbb egy megjegyzett parancsnál.

Androidon ennek a kivételnek a megfelelője az alkalmazásonkénti beállítás: zárja ki a burkolóalkalmazást az alagútból, hogy a saját forgalma a mobilkapcsolaton keresztül menjen ki. A kizárás nélkül a burkoló abba az alagútba irányul, amelyet építeni próbál, és az újracsatlakozási hurok kiszolgálóhibának látszik.

Nézze meg az időzítést, mielőtt bármit módosít

Egy munkamenet, amely minden alkalommal ugyanazon időköz után hal meg, házirend-aláírás és nem titkosítási hiba, és a hosszú távú forgalomkorlátok pontosan ezt a mintát adják. Egy kapcsolat, amely közvetlenül a kézfogás után nullázódik, olyan proxyra utal, amelynek nem tetszett a tanúsítványlánc.

Hasonlítsa össze egy közönséges HTTPS-webhely tanúsítványkibocsátóját mindkét hálózatból. Ha a kibocsátó a korlátozott hálózaton más, valami a közepén lezárja a TLS-t, és egyetlen burkoló sem éli túl ezt az elfogást változatlanul. Ugyanez az összehasonlítás megmondja, hogy a blokk a kiszolgálónevét célozza-e, vagy minden TLS-munkamenetet azon a címen.

Írja fel a megfigyelt viselkedést: meddig tartott a munkamenet, megnyílt-e a socket, naplózott-e a burkoló kézfogást. Ezek mindegyike szűkíti a következő próbát.

Egyszerre egy változót teszteljen

Először az UDP-t ellenőrizze, mert néhány hálózat teljesen eldobja, és az UDP-hiba semmit sem mond a 443-ról. Utána próbálja a TCP 443-at a burkoló nélkül, majd a burkolót a 443-on. Minden lépésnél olvassa az ügyfélnaplót, és álljon meg, amint a viselkedés megváltozik.

Próbánként egy elemet változtasson. Egy új port, egy új burkoló és egy új titkosító ugyanabban a futásban nem engedi megmondani, melyikük számított.