OpenVPN på 443 framleis blokkert? Sjå kva nettet granskar
Port 443 endrar nummeret, ikkje forma på protokollen. Viss vegen granskar eller avsluttar TLS, er ei innpakning og ei rett vertsrute dei neste testane.
Tunnelen koplar til frå ei heimelinje og stoggar på eit hotell- eller kontornett, og flyttinga av tenaren til port 443 endra ingenting. Det resultatet er vanleg nok til å ha ei form: porten var den enkle delen, og resten av avgjerda høyrer til alt som sit mellom klienten og tenaren. To spørsmål avgjer dei fleste sakene, og ingen av dei handlar om siffer. Godtek nettet eit TLS-handtrykk til den adressa, og held klienten ei rute til si eiga innpakning medan tunnelen er oppe?
Handtrykket røpar meir enn nummeret
Ein innbygd VPN-lyttar på TCP 443 talar sin eigen protokoll frå den første pakken. Ein ClientHello har eit versjonsfelt, ein tilfeldig verdi og ei liste over utvidingar, og eit apparat som les nokre hundre byte kan sjå skilnaden utan å dekryptera noko. Portnummer er billeg å tilfredsstilla, og forma på protokollen er det filteret faktisk kontrollerer. Reglar blir oftast skrivne per protokoll òg, så ein politikk som granskar TLS seier ingenting om UDP.
Ein gjennomsiktig proxy som krev ei gyldig TLS-økt, slepp sambandet under oppsettet, ofte etter at TCP-handtrykket er fullført. Den detaljen tel seinare, fordi han tyder at klientloggen stoggar etter at sockelen er sett opp.
Innpakking av straumen skapar to feilpunkt
Ei TLS-innpakning som stunnel gjenopprettar den venta forma: klienten koplar til ein lokal lyttar, innpakninga opnar ei ekte TLS-økt til tenaren på 443, og ei andre innpakning på tenaren sender dei dekrypterte byta vidare til VPN-daemonen. Den ytre økta ser no ut som kvar annan HTTPS-samband. VPN-daemonen på tenaren bør berre lytta på loopback, fordi ingenting utanfor innpakninga treng å nå han.
Tre separate ting må stemma for den konstruksjonen. Klientprofilen peikar på den lokale lyttaren, tenarsertifikatet passar til namnet klienten stadfester, og vidaresendinga på tenarsida siktar på porten daemonen verkeleg brukar. Gjer du feil på ein av dei, døyr sambandet før VPN-laget blir nådd. Då viser eit sertifikatavvik seg som ein innpakningsfeil og ikkje ein VPN-feil, og difor er det verdt å lesa begge loggane side om side.
Ruta til innpakninga er fella
Så snart tunnelen kjem opp, peikar standardruta inn i han, og den ytre TLS-økta treng ein veg som ikkje går inn i tunnelen ho ber. Ein vanleg VPN-klient vernar adressa han ringjer; ein innpakka klient ringjer sin eigen loopback, så måladdressa til innpakninga er usynleg for det vernet.
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
Dei nøyaktige adressene fyller du ut sjølv, og ruta må finnast gjennom heile levetida til sambandet, ikkje berre ved oppstart. Eit lite innpakningsskript som legg til ruta før klienten og fjernar ho etterpå, er meir påliteleg enn ein hugsa kommando.
På Android er motstykket til det unntaket ei innstilling per app: utelat innpakningsappen frå tunnelen slik at eigen trafikk går ut over mobilkoplinga. Utan utelatinga blir innpakninga ruta inn i tunnelen ho prøver å byggja, og attkoplingsløkka ser ut som eit tenarproblem.
Les tidsforløpet før du endrar noko
Ei økt som døyr etter same intervallet kvar gong er ein politikksignatur og ikkje ein kryptografisk feil, og langvarige strøymingsgrenser gjev nett det mønsteret. Eit samband som blir nullstilt rett etter handtrykket, tyder på ein proxy som ikkje likte sertifikatkjeda.
Samanlikn sertifikatutgivaren til ein vanleg HTTPS-nettstad frå båe netta. Viss utgivaren er annleis på det avgrensa nettet, avsluttar noko TLS i midten, og inga innpakning overlever den avlyttinga utan endring. Den same samanlikninga fortel deg om blokkeringa siktar på tenarnamnet ditt eller kvar TLS-økt på den adressa.
Skriv ned åtferda du såg: kor lenge økta varte, om sockelen opna seg, om innpakninga logga eit handtrykk. Kvar av dei snevrar inn den neste testen.
Prøv éin variabel om gongen
Sjekk UDP først, fordi nokre nett slepp det heilt, og ein UDP-feil seier ingenting om 443. Prøv så TCP 443 utan innpakninga, deretter innpakninga på 443. Les klientloggen ved kvart steg og stogg så snart åtferda endrar seg.
Endra eitt element per forsøk. Ein ny port, ei ny innpakning og eit nytt siffer i same køyringa lèt deg ikkje seia kva av dei tre som talde.