OpenVPN på 443 fortsatt blokkert? Se hva nettet undersøker

Tunnelen kobler til fra en hjemmelinje og stopper på et hotell- eller kontornett, og flyttingen av serveren til port 443 endret ingenting. Det resultatet er vanlig nok til å ha en form: porten var den enkle delen, og resten av avgjørelsen tilhører alt som sitter mellom klienten og serveren. To spørsmål avgjør de fleste sakene, og ingen av dem handler om sifre. Godtar nettet et TLS-håndtrykk til den adressen, og holder klienten en rute til sin egen innpakning mens tunnelen er oppe?

Håndtrykket røper mer enn nummeret

En innebygd VPN-lytter på TCP 443 snakker sin egen protokoll fra den første pakken. En ClientHello har et versjonsfelt, en tilfeldig verdi og en liste over utvidelser, og en enhet som leser noen hundre byte, ser forskjellen uten å dekryptere noe. Portnumre er billige å tilfredsstille, og formen på protokollen er det filteret faktisk kontrollerer. Regler skrives også vanligvis per protokoll, så en policy som undersøker TLS sier ingenting om UDP.

En gjennomsiktig proxy som krever en gyldig TLS-økt, slipper forbindelsen under oppsettet, ofte etter at TCP-håndtrykket er fullført. Den detaljen teller senere, fordi den betyr at klientloggen stopper etter at sockelen er satt opp.

Innpakning av strømmen gir to feilpunkter

En TLS-innpakning som stunnel gjenoppretter den forventede formen: klienten kobler til en lokal lytter, innpakningen åpner en ekte TLS-økt til serveren på 443, og en andre innpakning på serveren sender de dekrypterte bytene videre til VPN-daemonen. Den ytre økten ser nå ut som enhver annen HTTPS-forbindelse. VPN-daemonen på serveren bør bare lytte på loopback, fordi ingenting utenfor innpakningen trenger å nå den.

Tre separate ting må stemme for den konstruksjonen. Klientprofilen peker på den lokale lytteren, serversertifikatet passer til navnet klienten verifiserer, og videresendingen på serversiden sikter på porten daemonen faktisk bruker. Gjør du feil på én av dem, dør forbindelsen før VPN-laget nås. Da viser et sertifikatavvik seg som en innpakningsfeil og ikke som en VPN-feil, og derfor er det verdt å lese begge loggene side om side.

Ruten til innpakningen er fellen

Så snart tunnelen kommer opp, peker standardruten inn i den, og den ytre TLS-økten trenger en vei som ikke går inn i tunnelen den bærer. En vanlig VPN-klient beskytter adressen den ringer; en innpakket klient ringer sin egen loopback, så måladressen til innpakningen er usynlig for den beskyttelsen.

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 nøyaktige adressene fyller du ut selv, og ruten må finnes gjennom hele levetiden til forbindelsen, ikke bare ved oppstart. Et lite innpakningsskript som legger til ruten før klienten og fjerner den etterpå, er mer pålitelig enn en husket kommando.

På Android er motstykket til det unntaket en innstilling per app: utelat innpakningsappen fra tunnelen slik at egen trafikk går ut over mobilforbindelsen. Uten utelatelsen blir innpakningen rutet inn i tunnelen den prøver å bygge, og gjenoppkoblingsløkken ser ut som et serverproblem.

Les tidsforløpet før du endrer noe

En økt som dør etter samme intervall hver gang, er en policysignatur og ikke en kryptografisk feil, og langvarige strømgrenser gir nøyaktig det mønsteret. En forbindelse som tilbakestilles rett etter håndtrykket, tyder på en proxy som ikke likte sertifikatkjeden.

Sammenlign sertifikatutstederen til et vanlig HTTPS-nettsted fra begge nett. Hvis utstederen er annerledes på det begrensede nettet, avslutter noe TLS i midten, og ingen innpakning overlever den avlyttingen uten endring. Den samme sammenligningen forteller deg om blokkeringen sikter på servernavnet ditt eller hver TLS-økt på den adressen.

Skriv ned atferden du så: hvor lenge økten varte, om sockelen åpnet seg, om innpakningen logget et håndtrykk. Hver av dem snevrer inn den neste testen.

Test én variabel om gangen

Sjekk UDP først, fordi noen nett slipper det helt, og en UDP-feil sier ingenting om 443. Prøv så TCP 443 uten innpakningen, deretter innpakningen på 443. Les klientloggen ved hvert steg og stopp så snart atferden endrer seg.

Endre ett element per forsøk. En ny port, en ny innpakning og et nytt siffer i samme kjøring lar deg ikke si hvilken av de tre som talte.