OpenVPN på 443 fortfarande blockerat? Se vad nätet inspekterar

Port 443 ändrar numret, inte protokollets form. Om vägen inspekterar eller avslutar TLS är ett omslag och en korrekt värdrutt nästa tester.

Tunneln ansluter från en hemmaanslutning och fastnar i ett hotell- eller kontorsnät, och flytten av servern till port 443 ändrade ingenting. Det resultatet är vanligt nog att ha en form: porten var den enkla delen, och resten av beslutet tillhör allt som sitter mellan klienten och servern. Två frågor avgör de flesta fallen, och ingen av dem handlar om chiffersviter. Accepterar nätet en TLS-handskakning till den adressen, och behåller klienten en rutt till sitt eget omslag medan tunneln är uppe?

Handskakningen avslöjar mer än numret

En inbyggd VPN-lyssnare på TCP 443 talar sitt eget protokoll från det första paketet. En ClientHello har ett versionsfält, ett slumpvärde och en lista med tillägg, och en enhet som läser några hundra byte ser skillnaden utan att dekryptera något. Portnummer är billiga att uppfylla, och det är protokollets form som filtret faktiskt kontrollerar. Regler skrivs oftast också per protokoll, så en policy som inspekterar TLS säger ingenting om UDP.

En transparent proxy som kräver en giltig TLS-session släpper anslutningen under uppsättningen, ofta efter att TCP-handskakningen har slutförts. Den detaljen spelar roll senare, eftersom den betyder att klientloggen stannar när socketen är upprättad.

Inpackning av strömmen skapar två felpunkter

Ett TLS-omslag som stunnel återställer den förväntade formen: klienten ansluter till en lokal lyssnare, omslaget öppnar en riktig TLS-session till servern på 443, och ett andra omslag på servern skickar vidare de dekrypterade byten till VPN-demonen. Den yttre sessionen ser nu ut som vilken annan HTTPS-anslutning som helst. VPN-demonen på servern bör bara lyssna på loopback, eftersom ingenting utanför omslaget behöver nå den.

Tre separata saker måste stämma för den konstruktionen. Klientprofilen pekar på den lokala lyssnaren, servercertifikatet matchar namnet som klienten verifierar, och vidarebefordran på serversidan riktar sig mot porten som demonen faktiskt använder. Gör du fel på någon av dem dör anslutningen innan VPN-lagret nås. En certifikatavvikelse visar sig då som ett omslagsfel och inte som ett VPN-fel, och därför är det värt att läsa båda loggarna sida vid sida.

Rutten till omslaget är fällan

Så snart tunneln är uppe pekar standardrutten in i den, och den yttre TLS-sessionen behöver en väg som inte går in i tunneln som den bär. En vanlig VPN-klient skyddar adressen den ringer; en omslagen klient ringer sin egen loopback, så omslagets destinationsadress är osynlig för det skyddet.

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 exakta adresserna fyller du i själv, och rutten måste finnas under hela anslutningens livstid, inte bara vid start. Ett litet omslagsskript som lägger till rutten före klienten och tar bort den efteråt är pålitligare än ett memorerat kommando.

På Android är motsvarigheten till det undantaget en inställning per app: uteslut omslagsappen från tunneln så att dess egen trafik går ut över mobilanslutningen. Utan uteslutningen routas omslaget in i tunneln som det försöker bygga, och återanslutningsslingan ser ut som ett serverproblem.

Läs tidsförloppet innan du ändrar något

En session som dör efter samma intervall varje gång är en policysignatur och inte ett kryptografiskt fel, och långvariga flödesgränser ger exakt det mönstret. En anslutning som återställs direkt efter handskakningen tyder på en proxy som inte gillade certifikatkedjan.

Jämför certifikatutgivaren för en vanlig HTTPS-sajt från båda näten. Om utgivaren skiljer sig på det begränsade nätet, avslutar något TLS i mitten, och inget omslag överlever den avlyssningen oförändrat. Samma jämförelse säger dig om blockeringen riktar sig mot ditt servernamn eller mot varje TLS-session på den adressen.

Skriv ner det observerade beteendet: hur länge sessionen varade, om socketen öppnades, om omslaget loggade en handskakning. Var och en av dem snävar in nästa test.

Testa en variabel i taget

Kontrollera UDP först, eftersom vissa nät kastar det helt och ett UDP-fel inte säger något om 443. Prova sedan TCP 443 utan omslaget, därefter omslaget på 443. Läs klientloggen vid varje steg och stoppa så snart beteendet ändras.

Ändra ett element per försök. En ny port, ett nytt omslag och en ny chiffer i samma körning låter dig inte säga vilken av de tre som spelade roll.

Relaterade artiklar