Hjälper TCP 443 egentligen? Bara om servern lyssnar där

TCP 443 är en reservväg med en förutsättning, inte en förklädnad som slinker en tunnel förbi vilket filter som helst. Den hjälper när leverantören redan publicerar en TCP-lyssnare på den porten och vägen tål en anslutning som står öppen i timmar. Den misslyckas, vanligen som tidsgräns, när något av de två saknas, och tidsgränsen säger sällan vilket. Att avgöra om du ska byta kräver tre frågor, och bara en av dem handlar om portnumret.

Ett portnummer är inte ett transportlöfte

En port namnger en ändpunkt; TCP gör den till en ordnad byteström; OpenVPN avgör vad som färdas inuti den strömmen. En webbserver på samma nummer använder en helt annan applikationsuppställning, så delningen av port 443 får de två att se lika ut för ett filter och inget mer. Numret är en ledtråd som ett filter läser, inte en egenskap som ändrar vad paketen innehåller. Att behandla dem som samma sak eftersom de delar en port är felet bakom det mesta av förvirringen här.

Mellanliggande enheter fattar sällan ett enkelt tillåt-eller-avvisa-beslut om en port. Många granskar de första byten, några fäster en destination, och några återställer anslutningar som står öppna för länge. Därför kan samma profil fungera från ett nät och gå i tidsgräns från ett annat, och därför är en reservväg värd att testa som ett stödd alternativ i stället för att lita på den som ett löfte. När ett filter granskar trafik är portnumret bara det första det tittar på.

Bekräfta lyssnaren innan du rör profilen

Servern måste vara konfigurerad för TCP på porten, och klientprofilen måste begära samma transport. Att skriva om en UDP-profil till att begära TCP skapar inte lyssnaren, och tidsgränsen som följer går inte att skilja från en brandvägg som släpper porten. Ladda ner leverantörens egen TCP-profil när en finns, eftersom vissa tjänster publicerar en separat ändpunkt och separata identitetsinställningar för varje transport. Handredigering är bra för ett kontrollerat test och ett dåligt sätt att gissa leverantörens avsedda konfiguration.

Båda sidorna av den matchningen syns i konfigurationen, och OpenVPN-projektets länkalternativ dokumenterar båda formerna. Det minimala paret ser ut så här:

# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443

Tre villkor avgör om reservvägen lönar sig

Det första villkoret är att leverantören överhuvudtaget erbjuder transporten; utan det spelar inget annat någon roll. Det andra är att vägen håller en långvarig session vid liv, eftersom vissa nät återställer anslutningar som står öppna i stället för att blockera porten helt. Det tredje är om reservvägen är ett medvetet undantag eller en nödlösning som döljer ett fel du inte har åtgärdat.

Varje villkor har en billig kontroll. Ett misslyckande vid något av dem ser likadant ut från klienten:

Innan du jämför transporter, slutför alla inloggningar på en captive portal. Ett nät som inte har släppt in din enhet blockerar båda transporterna, och jämförelsen mäter då portalen i stället för tunneln. Logga in, bekräfta att vanlig surfning fungerar, och börja först därefter testet.

Kostnaden du accepterar: TCP inuti TCP

TCP skickar om förlorade segment och bevarar deras ordning. När ett program som också använder TCP körs inuti en TCP-tunnel reagerar två återhämtningslager på samma förlust, och just det samspelet gör tunneln långsam på en väg med förluster. Symtomet är fördröjning och jitter snarare än ett rent fel, vilket gör det lätt att skylla på den bortre änden. Mät från klienten under båda transporterna innan du drar en slutsats.

UDP undviker denna nästning, och det är huvudskälet till att leverantörer föredrar det och bara erbjuder TCP som alternativ. En stabil TCP-anslutning är fortfarande mer användbar än en oåtkomlig UDP-anslutning, så jämförelsen står mellan två verkliga kostnader och inte mellan ett bra och ett dåligt alternativ. Håll enheten och åtkomstnätet oförändrade medan du jämför, annars beskriver resultatet fel variabel.

Vissa klientfunktioner är bara dokumenterade för en transport, så en reservprofil kan tyst tappa beteende du var beroende av. Läs alternativets transportkrav innan du behandlar TCP-profilen som ett rakt byte.

Fel som en annan transport inte rör

Ett utgånget certifikat behöver fortfarande en klockkontroll eller en förnyelse, och ett avvisat konto behöver fortfarande rätt inloggningsuppgifter. Behåll serveridentitetskontrollerna som leverantören gav, eftersom ett välbekant portnummer inte autentiserar någon. En port som svarar säger bara att något lyssnar.

Om tunneln kommer upp och målen fortfarande misslyckas är det återstående problemet routing eller namnmatchning efter anslutningen, inte transporten. Följ den vägen i stället för att åka genom portar, för det är så en eftermiddag försvinner. Profilen säger vilken transport du ska pröva; den säger aldrig varför UDP-vägen misslyckades.