Hjælper TCP 443 egentlig? Kun hvis serveren lytter der

TCP 443 er en reserve med en forudsætning, ikke en forklædning, der smugler en tunnel forbi enhver filtrering. Det hjælper, når udbyderen allerede offentliggør en TCP-lytter på den port, og netvejen tåler en forbindelse, der bliver åben i timer. Det fejler, sædvanligvis som timeout, når en af de to ting mangler, og timeouten siger sjældent hvilken. At afgøre, om du skal skifte, kræver tre spørgsmål, og kun ét af dem handler om portnummeret.

Et portnummer er ikke et transportløfte

En port navngiver et endepunkt; TCP gør den til en ordnet bytestrøm; OpenVPN afgør, hvad der rejser inde i den strøm. En webserver på samme nummer bruger en helt anden applikationsopsætning, så delingen af port 443 får de to til at ligne hinanden for en filtrering og intet mere. Nummeret er et vink, som en filtrering læser, ikke en egenskab, der ændrer, hvad pakkerne indeholder. At behandle de to som det samme, fordi de deler en port, er fejlen bag det meste af forvirringen her.

Mellemled træffer sjældent en simpel tillad-eller-afvis-beslutning om en port. Mange undersøger de første bytes, nogle fastlåser en destination, og nogle nulstiller forbindelser, der bliver åbne for længe. Derfor kan den samme profil virke fra ét netværk og time out fra et andet, og derfor er en reserve værd at teste som en understøttet mulighed i stedet for at stole på den som et løfte. Når en filtrering undersøger trafik, er portnummeret kun det første, den ser på.

Bekræft lytteren, før du rører profilen

Serveren skal være konfigureret til TCP på porten, og klientprofilen skal bede om den samme transport. At omskrive en UDP-profil til at bede om TCP skaber ikke lytteren, og den resulterende timeout kan ikke skelnes fra en firewall, der dropper porten. Hent udbyderens egen TCP-profil, når der findes en, fordi nogle tjenester offentliggør et særskilt endepunkt og særskilte identitetsindstillinger for hver transport. Håndredigering er fint til en kontrolleret test og en dårlig måde at gætte på udbyderens tilsigtede konfiguration.

De to sider af det match fremgår af konfigurationen, og OpenVPN-projektets linkindstillinger dokumenterer begge former. Det minimale par ser sådan ud:

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

Tre betingelser afgør, om reserven kan betale sig

Den første betingelse er, at udbyderen overhovedet tilbyder transporten; uden den betyder alt andet intet. Den anden er, at netvejen holder en langvarig session i live, da nogle netværk nulstiller forbindelser, der bliver åbne, i stedet for at blokere porten helt. Den tredje er, om reserven er en bevidst undtagelse eller en nødløsning, der skjuler en fejl, du ikke har rettet.

Hver betingelse har et billigt tjek. Et fejltrin ved enhver af dem ser ens ud fra klienten:

Færdiggør enhver login på en captive portal, før du sammenligner transporter. Et netværk, der ikke har lukket din enhed ind, blokerer begge transporter, og sammenligningen måler så portalen i stedet for tunnelen. Log ind, bekræft, at almindelig browsing virker, og start først derefter testen.

Prisen, du accepterer: TCP inde i TCP

TCP gensender tabte segmenter og bevarer deres rækkefølge. Når en applikation, der også bruger TCP, kører inde i en TCP-tunnel, reagerer to genopretningslag på det samme tab, og netop det samspil gør tunnelen langsom på en netvej med tab. Symptomet er forsinkelse og jitter frem for en ren fejl, hvilket gør det let at give den fjerne ende skylden. Mål fra klienten under begge transporter, før du konkluderer.

UDP undgår denne indlejring, og det er hovedårsagen til, at udbydere foretrækker det og kun tilbyder TCP som alternativ. En stabil TCP-forbindelse er stadig mere nyttig end en utilgængelig UDP-forbindelse, så sammenligningen er mellem to reelle priser og ikke mellem en god og en dårlig mulighed. Hold enheden og adgangsnetværket uændrede, mens du sammenligner, ellers beskriver resultatet den forkerte variabel.

Nogle klientfunktioner er kun dokumenteret for én transport, så en reserveprofil kan stille droppe adfærd, du var afhængig af. Læs indstillingens transportkrav, før du behandler TCP-profilen som en ligetil udskiftning.

Fejl, som en anden transport ikke rører

Et udløbet certifikat kræver stadig et urtjek eller en fornyelse, og en afvist konto kræver stadig de rigtige legitimationsoplysninger. Behold de serveridentitetskontroller, udbyderen har givet, fordi et velkendt portnummer ikke autentificerer nogen. En port, der svarer, siger kun, at noget lytter.

Hvis tunnelen kommer op, og destinationer stadig fejler, er det resterende problem routing eller navneopløsning efter forbindelsen, ikke transporten. Følg den vej i stedet for at køre portene igennem, for det er sådan en eftermiddag forsvinder. Profilen fortæller dig, hvilken transport du skal prøve; den fortæller aldrig, hvorfor UDP-vejen fejlede.