OpenVPN na 443 stále blokovaný? Zkontrolujte, co síť prohlíží

Tunel se připojí z domácí linky a zasekne se v hotelové nebo kancelářské síti, a přesun serveru na port 443 nic nezměnil. Ten výsledek je dost častý na to, aby měl tvar: port byl ta snadná část a zbytek rozhodnutí patří všemu, co stojí mezi klientem a serverem. Většinu případů rozhodnou dvě otázky a ani jedna není o šifrách. Přijímá síť TLS handshake na tu adresu a udržuje klient trasu ke svému vlastnímu obalu, dokud je tunel nahoře?

Handshake prozradí víc než číslo

Nativní VPN listener na TCP 443 mluví svým vlastním protokolem od prvního paketu. ClientHello má pole verze, náhodnou hodnotu a seznam rozšíření a zařízení, které přečte několik stovek bajtů, rozdíl pozná, aniž by cokoli dešifrovalo. Čísla portů se dají uspokojit levně a tvar protokolu je to, co filtr skutečně kontroluje. Pravidla se obvykle píšou i po protokolech, takže politika, která prohlíží TLS, o UDP neříká nic.

Transparentní proxy, která trvá na platné TLS relaci, spojení během navazování zahodí, často poté, co TCP handshake skončí. Ten detail je důležitý později, protože znamená, že klientský log se zastaví po vytvoření socketu.

Obalení toku vytváří dvě místa selhání

TLS obal, jako je stunnel, obnoví očekávaný tvar: klient se připojí k místnímu listeneru, obal otevře skutečnou TLS relaci k serveru na 443 a druhý obal na serveru předá dešifrované bajty VPN démonu. Vnější relace teď vypadá jako kterékoli jiné HTTPS spojení. VPN démon na serveru by měl poslouchat jen na loopbacku, protože nic mimo obal se k němu nemusí dostat.

Pro ten návrh se musí sejít tři oddělené věci. Profil klienta míří na místní listener, serverový certifikát odpovídá jménu, které klient ověřuje, a přesměrování na straně serveru cílí na port, který démon opravdu používá. Spletete-li kteroukoli z nich, spojení umře dřív, než se dostane k VPN vrstvě. Nesoulad certifikátu se pak projeví jako chyba obalu, ne jako chyba VPN, a proto se oba logy vyplatí číst vedle sebe.

Trasa k obalu je past

Jakmile tunel naskočí, výchozí trasa míří do něj a vnější TLS relace potřebuje cestu, která nevejde do tunelu, který nese. Běžný VPN klient chrání adresu, na kterou volá; obalený klient volá svůj vlastní loopback, takže cílová adresa obalu je pro tu ochranu neviditelná.

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

Přesné adresy doplníte sami a trasa musí existovat celý život spojení, ne jen při startu. Malý obalový skript, který trasu přidá před klientem a po něm ji odebere, je spolehlivější než zapamatovaný příkaz.

Na Androidu je ekvivalentem té výjimky nastavení pro každou aplikaci: vylučte obalovou aplikaci z tunelu, aby její vlastní provoz odcházel přes mobilní spojení. Bez vyloučení se obal směruje do tunelu, který se snaží postavit, a smyčka opětovného připojení vypadá jako problém serveru.

Přečtěte si časování, než cokoli změníte

Relace, která umře po stejném intervalu pokaždé, je podpis politiky, ne kryptografické selhání, a dlouhodobé limity toku dávají přesně takový vzorec. Spojení, které se resetuje hned po handshaku, naznačuje proxy, které se nelíbí řetěz certifikátů.

Porovnejte vydavatele certifikátu běžného HTTPS webu z obou sítí. Pokud se vydavatel v omezené síti liší, něco ukončuje TLS uprostřed a žádný obal to odposlouchávání nepřežije beze změny. Stejné srovnání vám řekne, zda blok míří na jméno vašeho serveru, nebo na každou TLS relaci na tu adresu.

Zapište pozorované chování: jak dlouho relace vydržela, zda se socket otevřel, zda obal zalogoval handshake. Každý z těch údajů zužuje další test.

Testujte jednu proměnnou po druhé

Nejdřív zkontrolujte UDP, protože některé sítě ho zahazují úplně a selhání UDP o 443 neříká nic. Pak zkuste TCP 443 bez obalu, potom obal na 443. Čtěte klientský log v každém kroku a zastavte se, jakmile se chování změní.

Měňte jeden prvek na pokus. Nový port, nový obal a nová šifra v jednom běhu vás nechají bez odpovědi, který ze tří byl důležitý.