Hjelper TCP 443 eigentleg? Berre viss serveren lyttar der
Ein TCP-profil er ein reserveveg, ikkje ei forkleding. Sjekk at serveren lyttar på den porten, og veg deretter kostnaden ved dobbel TCP mot å vere utilgjengeleg.
TCP 443 er ein reserveveg med ein føresetnad, ikkje ei forkleding som lurer ein tunnel forbi kva filter som helst. Han hjelper når tilbydaren alt publiserer ein TCP-lyttar på den porten, og vegen toler eit samband som blir ståande open i timar. Han feilar, vanlegvis som tidsavbrot, når ein av dei to manglar, og tidsavbrotet seier sjeldan kven. Å avgjere om du skal byte krev tre spørsmål, og berre eitt av dei handlar om portnummeret.
Eit portnummer er ikkje eit transportløfte
Ein port namngir eit endepunkt; TCP gjer han om til ein ordna bytestraum; OpenVPN avgjer kva som reiser inne i den straumen. Ein webserver på same nummer brukar eit heilt anna applikasjonsoppsett, så delinga av port 443 får dei to til å sjå like ut for eit filter og ikkje meir. Nummeret er eit hint eit filter les, ikkje ein eigenskap som endrar kva pakkane inneheld. Å handsame dei to som det same fordi dei deler ein port, er feilen bak det meste av forvirringa her.
Mellomledd tek sjeldan ei enkel tillat-eller-avvis-avgjerd om ein port. Mange granskar dei første byta, nokre festar ein destinasjon, og nokre nullstiller samband som blir ståande opne for lenge. Difor kan den same profilen verke frå eitt nett og gå i tidsavbrot frå eit anna, og difor er ein reserveveg verd å teste som eit støtta alternativ i staden for å stole på han som eit løfte. Når eit filter granskar trafikk, er portnummeret berre det første det ser på.
Stadfest lyttaren før du rører profilen
Serveren må vere konfigurert for TCP på porten, og klientprofilen må be om den same transporten. Å skrive om ein UDP-profil til å be om TCP lagar ikkje lyttaren, og tidsavbrotet som følgjer, kan ikkje skiljast frå ein brannmur som droppar porten. Last ned tilbydaren sin eigen TCP-profil når ein finst, fordi nokre tenester publiserer eit eige endepunkt og eigne identitetsinnstillingar for kvar transport. Handredigering er fint for ein kontrollert test og ein dårleg måte å gjette tilbydaren si tiltenkte konfigurasjon på.
Begge sider av det samsvaret viser seg i konfigurasjonen, og OpenVPN-prosjektet sine koplingval dokumenterer begge formene. Det minimale paret ser slik ut:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443Tre vilkår avgjer om reservevegen løner seg
Det første vilkåret er at tilbydaren i det heile tek tilby transporten; utan han tyder ingenting anna noko. Det andre er at vegen held ein langvarig økt i live, sidan nokre nett nullstiller samband som blir ståande opne i staden for å blokkere porten heilt. Det tredje er om reservevegen er eit medvite unntak eller ei naudløysing som skjuler ein feil du ikkje har retta.
Kvart vilkår har ein billeg sjekk. Eit feilgrep ved nokon av dei ser likt ut frå klienten:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
Før du samanliknar transportar, fullfør all innlogging på ein captive portal. Eit nett som ikkje har sleppt eininga di inn, blokkerer begge transportane, og samanlikninga måler då portalen og ikkje tunnelen. Logg inn, stadfest at vanleg surfing verkar, og start først deretter testen.
Kostnaden du godtek: TCP inne i TCP
TCP sender tapte segment på nytt og held på rekkjefølgja deira. Når ein applikasjon som òg brukar TCP køyrer inne i ein TCP-tunnel, reagerer to attopprettingslag på det same tapet, og nettopp dette samspelet gjer tunnelen treg på ein veg med tap. Symptomet er forseinking og jitter framfor ein rein feil, noko som gjer det lett å skylde på den fjerne enden. Mål frå klienten under begge transportane før du konkluderer.
UDP unngår denne nestinga, og det er hovudgrunnen til at tilbydarar føretrekkjer det og berre tilbyr TCP som alternativ. Eit stabilt TCP-samband er framleis nyttigare enn eit utilgjengeleg UDP-samband, så samanlikninga er mellom to reelle kostnader og ikkje mellom eit godt og eit dårleg alternativ. Hald eininga og aksessnettet uendra medan du samanliknar, elles skildrar resultatet feil variabel.
Nokre klientfunksjonar er dokumenterte berre for éin transport, så ein reserveprofil kan stille miste åtferd du var avhengig av. Les transportkravet til valet før du handsamar TCP-profilen som ei enkel utskifting.
Feil som ein annan transport ikkje rører
Eit utgått sertifikat treng framleis ein klokkesjekk eller ei fornying, og ein avvist konto treng framleis dei rette påloggingsdetaljane. Hald på serveridentitetssjekkane tilbydaren gav, fordi eit kjent portnummer autentiserer ingen. Ein port som svarar, seier berre at noko lyttar.
Viss tunnelen kjem opp og destinasjonane framleis feilar, er det gjenverande problemet ruting eller namneoppslag etter tilkoplinga, ikkje transporten. Følg den vegen i staden for å køyre gjennom portar, for det er slik ein ettermiddag forsvinn. Profilen fortel deg kva transport du skal prøve; han fortel aldri kvifor UDP-vegen feila.