Helpt TCP 443 echt? Alleen als de server daar luistert

TCP 443 is een terugvaloptie met een voorwaarde, geen vermomming die een tunnel langs elk filter smokkelt. Het helpt wanneer de aanbieder al een TCP-listener op die poort publiceert en het pad een verbinding verdraagt die urenlang open blijft. Het faalt, meestal als time-out, wanneer een van beide ontbreekt, en de time-out zegt zelden welke. De beslissing om te wisselen vergt drie vragen, en slechts één daarvan gaat over het poortnummer.

Een poortnummer is geen transportbelofte

Een poort benoemt een eindpunt; TCP maakt er een geordende bytestroom van; OpenVPN bepaalt wat er in die stroom reist. Een webserver op hetzelfde nummer gebruikt een volstrekt andere applicatieopzet, dus het delen van poort 443 maakt de twee voor een filter op elkaar lijken en niets meer. Het nummer is een hint die een filter leest, geen eigenschap die verandert wat de pakketten bevatten. Ze als hetzelfde behandelen omdat ze een poort delen is de fout achter het meeste misverstand hier.

Tussenliggende apparaten nemen zelden een simpele toestaan-of-weigeren-beslissing over een poort. Veel inspecteren de eerste bytes, sommige pinnen een bestemming vast, en sommige resetten verbindingen die te lang open blijven. Daarom kan hetzelfde profiel vanuit het ene netwerk werken en vanuit het andere time-outen, en daarom is een terugvaloptie het testen waard als ondersteunde optie in plaats van er als belofte op te vertrouwen. Wanneer een filter het verkeer onderzoekt, is het poortnummer alleen het eerste waar het naar kijkt.

Bevestig de listener voordat u het profiel aanraakt

De server moet voor TCP op de poort zijn geconfigureerd, en het clientprofiel moet hetzelfde transport vragen. Een UDP-profiel herschrijven om TCP te vragen maakt de listener niet aan, en de resulterende time-out is niet te onderscheiden van een firewall die de poort laat vallen. Download het eigen TCP-profiel van de aanbieder als dat bestaat, omdat sommige diensten een apart eindpunt en aparte identiteitsinstellingen per transport publiceren. Handmatig bewerken is prima voor een gecontroleerde test en een slechte manier om de bedoelde configuratie van een provider te raden.

Beide kanten van die overeenkomst staan in de configuratie, en de koppelingsopties van het OpenVPN-project documenteren beide vormen. Het minimale paar ziet er zo uit:

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

Drie voorwaarden beslissen of de terugvaloptie loont

De eerste voorwaarde is dat de aanbieder het transport überhaupt biedt; zonder dat doet al het andere er niet toe. De tweede is dat het pad een langdurige sessie in leven houdt, omdat sommige netwerken verbindingen resetten die open blijven in plaats van de poort botweg te blokkeren. De derde is of de terugvaloptie een bewuste uitzondering is of een noodoplossing die een storing verbergt die u niet hebt verholpen.

Elke voorwaarde heeft een goedkope controle. Een mislukking bij een van hen ziet er vanuit de client hetzelfde uit:

Rond elke aanmelding op een captive portal af voordat u transporten vergelijkt. Een netwerk dat uw apparaat niet heeft toegelaten, blokkeert beide transporten, en de vergelijking meet dan het portal en niet de tunnel. Meld u aan, bevestig dat gewoon browsen werkt, en begin pas daarna de test.

De kosten die u accepteert: TCP in TCP

TCP verstuurt verloren segmenten opnieuw en bewaart hun volgorde. Wanneer een applicatie die zelf ook TCP gebruikt binnen een TCP-tunnel draait, reageren twee herstellagen op hetzelfde verlies, en juist die wisselwerking maakt de tunnel traag op een pad met verlies. Het symptoom is vertraging en jitter in plaats van een schone fout, wat het makkelijk maakt het verre uiteinde de schuld te geven. Meet vanaf de client onder beide transporten voordat u een conclusie trekt.

UDP vermijdt die nesting, en dat is de belangrijkste reden dat aanbieders het verkiezen en TCP alleen als alternatief bieden. Een stabiele TCP-verbinding is nog steeds nuttiger dan een onbereikbare UDP-verbinding, dus de vergelijking gaat tussen twee echte kosten en niet tussen een goede en een slechte optie. Houd het apparaat en het toegangsnetwerk gelijk terwijl u vergelijkt, anders beschrijft het resultaat de verkeerde variabele.

Sommige clientfuncties zijn alleen voor één transport gedocumenteerd, dus een terugvalprofiel kan stilzwijgend gedrag laten vallen waarop u vertrouwde. Lees de transportvereiste van de optie voordat u het TCP-profiel als een simpele ruil behandelt.

Storingen die een ander transport niet raakt

Een verlopen certificaat heeft nog steeds een klokcontrole of een vernieuwing nodig, en een geweigerd account heeft nog steeds de juiste inloggegevens nodig. Houd de server-identiteitscontroles aan die de aanbieder heeft geleverd, want een vertrouwd poortnummer authenticeert niemand. Een poort die antwoordt, zegt alleen dat er iets luistert.

Als de tunnel opkomt en bestemmingen nog steeds falen, is het resterende probleem routering of naamresolutie na de verbinding, niet het transport. Volg dat pad in plaats van poorten af te lopen, want zo verdwijnt een middag. Het profiel zegt welk transport u moet proberen; het zegt nooit waarom het UDP-pad faalde.