OpenVPN på 443 stadig blokeret? Se hvad netværket undersøger

Tunnelen opretter forbindelse fra en hjemmelinje og går i stå på et hotel- eller kontornetværk, og flytningen af serveren til port 443 ændrede intet. Det resultat er almindeligt nok til at have en form: porten var den nemme del, og resten af beslutningen tilhører alt det, der sidder mellem klienten og serveren. To spørgsmål afgør de fleste sager, og ingen af dem handler om cifre. Accepterer netværket et TLS-håndtryk til den adresse, og holder klienten en rute til sin egen indpakning, mens tunnelen er oppe?

Håndtrykket røber mere end nummeret

En indbygget VPN-lytter på TCP 443 taler sin egen protokol fra den første pakke. En ClientHello har et versionsfelt, en tilfældig værdi og en udvidelsesliste, og en enhed, der læser et par hundrede bytes, kan se forskellen uden at dekryptere noget. Portnumre er billige at opfylde, og protokollens form er det, filteret faktisk kontrollerer. Regler skrives også normalt pr. protokol, så en politik, der undersøger TLS, siger intet om UDP.

En transparent proxy, der kræver en gyldig TLS-session, dropper forbindelsen under opsætningen, ofte efter at TCP-håndtrykket er fuldført. Den detalje betyder noget senere, fordi den betyder, at klientloggen stopper, efter at socket er etableret.

Indpakning af strømmen skaber to fejlpunkter

En TLS-indpakning som stunnel genskaber den forventede form: klienten forbinder til en lokal lytter, indpakningen åbner en rigtig TLS-session til serveren på 443, og en anden indpakning på serveren videresender de dekrypterede bytes til VPN-dæmonen. Den ydre session ser nu ud som enhver anden HTTPS-forbindelse. VPN-dæmonen på serveren bør kun lytte på loopback, fordi intet uden for indpakningen behøver at nå den.

Tre separate ting skal passe sammen for det design. Klientprofilen peger på den lokale lytter, servercertifikatet matcher det navn, klienten verificerer, og videresendelsen på serversiden rammer den port, dæmonen faktisk bruger. Tager du fejl af blot én, dør forbindelsen, før VPN-laget nås. Et certifikatmismatch viser sig så som en indpakningsfejl i stedet for en VPN-fejl, og derfor er begge logs værd at læse side om side.

Ruten til indpakningen er fælden

Når tunnelen er oppe, peger standardruten ind i den, og den ydre TLS-session har brug for en vej, der ikke går ind i den tunnel, den bærer. En almindelig VPN-klient beskytter den adresse, den ringer til; en indpakket klient ringer til sin egen loopback, så indpakningens destinationsadresse er usynlig for den beskyttelse.

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

De præcise adresser skal du selv udfylde, og ruten skal eksistere hele forbindelsens levetid, ikke kun ved opstart. Et lille indpakningsscript, der tilføjer ruten før klienten og fjerner den bagefter, er mere pålideligt end en husket kommando.

På Android er ækvivalenten til den undtagelse en indstilling pr. app: udeluk indpakningsappen fra tunnelen, så dens egen trafik går ud over mobilforbindelsen. Uden udelukkelsen sendes indpakningen ind i den tunnel, den forsøger at bygge, og genopkoblingsløkken ser ud som et serverproblem.

Læs tidsforløbet, før du ændrer noget

En session, der dør efter det samme interval hver gang, er en politiksignatur og ikke en kryptografisk fejl, og langvarige flowgrænser giver præcis det mønster. En forbindelse, der nulstilles straks efter håndtrykket, tyder på en proxy, der ikke kunne lide certifikatkæden.

Sammenlign certifikatudstederen for et almindeligt HTTPS-site fra begge netværk. Hvis udstederen er anderledes på det begrænsede netværk, er noget ved at afslutte TLS midt i forbindelsen, og ingen indpakning overlever den aflytning uden ændringer. Den samme sammenligning fortæller dig, om blokeringen rammer dit servernavn eller hver TLS-session på den adresse.

Skriv den observerede adfærd ned: hvor længe sessionen varede, om socket blev åbnet, om indpakningen loggede et håndtryk. Hver af dem indsnævrer den næste test.

Test én variabel ad gangen

Tjek UDP først, fordi nogle netværk dropper det helt, og en UDP-fejl siger intet om 443. Prøv derefter TCP 443 uden indpakningen, så indpakningen på 443. Læs klientloggen ved hvert trin, og stop så snart adfærden ændrer sig.

Ændr ét element ad gangen. En ny port, en ny indpakning og en ny cipher i samme kørsel efterlader dig uden at kunne sige, hvilken af de tre der betød noget.