Hjelper TCP 443 egentlig? Bare hvis serveren lytter der

TCP 443 er en reserve med en forutsetning, ikke en forkledning som lurer en tunnel forbi et hvilket som helst filter. Den hjelper når tilbyderen allerede publiserer en TCP-lytter på den porten, og veien tåler en forbindelse som blir stående åpen i timer. Den feiler, vanligvis som tidsavbrudd, når en av de to mangler, og tidsavbruddet sier sjelden hvilken. Å avgjøre om du skal bytte krever tre spørsmål, og bare ett av dem handler om portnummeret.

Et portnummer er ikke et transportløfte

En port navngir et endepunkt; TCP gjør den om til en ordnet bytestrøm; OpenVPN avgjør hva som reiser inne i den strømmen. En webserver på samme nummer bruker et helt annet applikasjonsoppsett, så delingen av port 443 får de to til å se like ut for et filter og ikke mer. Nummeret er et hint et filter leser, ikke en egenskap som endrer hva pakkene inneholder. Å behandle de to som det samme fordi de deler en port, er feilen bak det meste av forvirringen her.

Mellomledd tar sjelden en enkel tillat-eller-avvis-avgjørelse om en port. Mange undersøker de første bytene, noen fester en destinasjon, og noen nullstiller forbindelser som blir stående åpne for lenge. Derfor kan den samme profilen virke fra ett nett og gå i tidsavbrudd fra et annet, og derfor er en reserve verdt å teste som et støttet alternativ i stedet for å stole på den som et løfte. Når et filter undersøker trafikk, er portnummeret bare det første det ser på.

Bekreft lytteren før du rører profilen

Serveren må være konfigurert for TCP på porten, og klientprofilen må be om den samme transporten. Å skrive om en UDP-profil til å be om TCP lager ikke lytteren, og tidsavbruddet som følger, kan ikke skilles fra en brannmur som dropper porten. Last ned tilbyderens egen TCP-profil når en finnes, fordi noen tjenester publiserer et eget endepunkt og egne identitetsinnstillinger for hver transport. Håndredigering er fint for en kontrollert test og en dårlig måte å gjette tilbyderens tiltenkte konfigurasjon på.

Begge sider av den samsvaret vises i konfigurasjonen, og OpenVPN-prosjektets koblingsvalg 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 443

Tre betingelser avgjør om reserven lønner seg

Den første betingelsen er at tilbyderen i det hele tatt tilbyr transporten; uten den betyr ingenting annet noe. Den andre er at veien holder en langvarig økt i live, siden noen nett nullstiller forbindelser som blir stående åpne i stedet for å blokkere porten helt. Den tredje er om reserven er et bevisst unntak eller en nødløsning som skjuler en feil du ikke har rettet.

Hver betingelse har en billig sjekk. Et feiltrinn ved noen av dem ser likt ut fra klienten:

Før du sammenligner transporter, fullfør all innlogging på en captive portal. Et nett som ikke har sluppet enheten din inn, blokkerer begge transportene, og sammenligningen måler da portalen og ikke tunnelen. Logg inn, bekreft at vanlig surfing virker, og start først deretter testen.

Kostnaden du aksepterer: TCP inne i TCP

TCP sender tapte segmenter på nytt og bevarer rekkefølgen deres. Når en applikasjon som også bruker TCP kjører inne i en TCP-tunnel, reagerer to gjenopprettingslag på det samme tapet, og nettopp dette samspillet gjør tunnelen treg på en vei med tap. Symptomet er forsinkelse og jitter framfor en ren feil, noe som gjør det lett å skylde på den fjerne enden. Mål fra klienten under begge transportene før du konkluderer.

UDP unngår denne nesting, og det er hovedgrunnen til at tilbydere foretrekker det og bare tilbyr TCP som alternativ. En stabil TCP-forbindelse er fortsatt mer nyttig enn en utilgjengelig UDP-forbindelse, så sammenligningen er mellom to reelle kostnader og ikke mellom et godt og et dårlig alternativ. Hold enheten og aksessnettet uendret mens du sammenligner, ellers beskriver resultatet feil variabel.

Noen klientfunksjoner er dokumentert bare for én transport, så en reserveprofil kan stille miste atferd du var avhengig av. Les alternativets transportkrav før du behandler TCP-profilen som en enkel utskifting.

Feil en annen transport ikke berører

Et utløpt sertifikat trenger fortsatt en klokkesjekk eller fornyelse, og en avvist konto trenger fortsatt de riktige påloggingsdetaljene. Behold serveridentitetssjekkene tilbyderen ga, fordi et kjent portnummer ikke autentiserer noen. En port som svarer, sier bare at noe lytter.

Hvis tunnelen kommer opp og destinasjonene fortsatt feiler, er det gjenværende problemet ruting eller navneoppslag etter tilkoblingen, ikke transporten. Følg den veien i stedet for å kjøre gjennom porter, for det er slik en ettermiddag forsvinner. Profilen forteller deg hvilken transport du skal prøve; den forteller aldri hvorfor UDP-veien feilet.