Help TCP 443 werklik? Net as die bediener daar luister
'n TCP-profiel is 'n terugval, nie 'n vermomming nie. Kyk of die bediener op daardie poort luister en weeg dan die koste van dubbele TCP teen die risiko om onbereikbaar te wees.
TCP 443 is 'n terugval met 'n voorwaarde, nie 'n vermomming wat 'n tonnel verby enige filter laat glip nie. Dit help wanneer die operateur reeds 'n TCP-luisteraar op daardie poort publiseer en die roete 'n verbinding verdra wat ure lank oop bly. Dit misluk, gewoonlik as 'n tydsverloop, wanneer een van die twee ontbreek, en die tydsverloop sê selde watter een. Om te besluit of jy moet oorskakel vra drie vrae, en net een daarvan gaan oor die poortnommer.
'n Poortnommer is nie 'n belofte van vervoer nie
'n Poort wys 'n eindpunt aan; TCP maak daarvan 'n geordende stroom grepe; OpenVPN besluit wat binne daardie stroom beweeg. 'n Webbediener op dieselfde nommer gebruik 'n heeltemal ander toepassingsreëling, so die deel van poort 443 maak die twee vir 'n filter dieselfde en niks meer nie. Die nommer is 'n wenk wat 'n filter lees, nie 'n eienskap wat verander wat die pakkette bevat nie. Om die twee as dieselfde te behandel omdat hulle 'n poort deel, is die fout agter die meeste verwarring hier.
Middleboxe neem selde 'n eenvoudige toelaat-of-weier-besluit oor 'n poort. Baie ondersoek die eerste grepe, sommige pen 'n bestemming vas, en sommige stel verbindings terug wat te lank oop bly. Dit is waarom dieselfde profiel van een netwerk kan werk en van 'n ander kan tydsverloop, en waarom 'n terugval werd is om as 'n ondersteunde opsie te toets eerder as om dit as 'n belofte te vertrou. Wanneer 'n filter verkeer ondersoek, is die poortnommer net die eerste ding waarna dit kyk.
Bevestig die luisteraar voordat jy die profiel aanraak
Die bediener moet vir TCP op die poort opgestel wees, en die kliëntprofiel moet dieselfde vervoer vra. Om 'n UDP-profiel te herskryf om TCP te vra, skep nie die luisteraar nie, en die gevolglike tydsverloop is nie van 'n firewall te onderskei wat die poort laat val nie. Laai die operateur se eie TCP-profiel af wanneer een bestaan, want sommige dienste publiseer 'n aparte eindpunt en aparte identiteitsinstellings vir elke vervoer. Handredigering is goed vir 'n beheerde toets en 'n swak manier om 'n verskaffer se bedoelde opstelling te raai.
Die twee kante van daardie passing verskyn in die opstelling, en die OpenVPN-projek se skakelopsies dokumenteer albei vorms. 'n Minimale paar lyk so:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443Drie voorwaardes bepaal of die terugval die moeite werd is
Die eerste voorwaarde is dat die operateur die vervoer hoegenaamd bied; sonder dit maak niks anders saak nie. Die tweede is dat die roete 'n langdurige sessie aan die lewe hou, want sommige netwerke stel verbindings terug wat oop bly eerder as om die poort heeltemal te blokkeer. Die derde is of die terugval 'n doelbewuste uitsondering is of 'n noodoplossing wat 'n fout wegsteek wat jy nie reggemaak het nie.
Elke voorwaarde het 'n goedkoop toets. 'n Mislukking by enigeen daarvan lyk dieselfde van die kliënt se kant:
| 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 |
Voltooi enige aanmelding by 'n captive-portaal voordat jy vervoer vergelyk. 'n Netwerk wat jou toestel nie toegelaat het nie, blokkeer albei vervoer, en die vergelyking meet dan die portaal eerder as die tonnel. Meld aan, bevestig dat gewone blaaiery werk, en begin eers dan die toets.
Die koste wat jy aanvaar: TCP binne TCP
TCP stuur verlore segmente weer en bewaar hulle volgorde. Wanneer 'n toepassing wat ook TCP gebruik binne 'n TCP-tonnel loop, reageer twee herstelvlakke op dieselfde verlies, en daardie wisselwerking is wat die tonnel stadig laat voel op 'n roete met verlies. Die simptoom is vertraging en jitter eerder as 'n skoon mislukking, wat dit maklik maak om die verre kant te blameer. Meet van die kliënt onder albei vervoer voordat jy 'n gevolgtrekking maak.
UDP vermy die nesting, en dit is die hoofrede waarom operateurs dit verkies en TCP net as 'n alternatief bied. 'n Stabiele TCP-verbinding is steeds nuttiger as 'n onbereikbare UDP-een, so die vergelyking is tussen twee werklike koste eerder as tussen 'n goeie opsie en 'n slegte een. Hou die toestel en die toegangsnetwerk onveranderd terwyl jy vergelyk, anders beskryf die resultaat die verkeerde veranderlike.
Sommige kliëntkenmerke word net vir een vervoer gedokumenteer, so 'n terugvalprofiel kan gedrag wat jy nodig gehad het stil laat val. Lees die opsie se vervoerveriste voordat jy die TCP-profiel as 'n reguit ruil beskou.
Foute wat 'n ander vervoer nie aanraak nie
'n Verstreke sertifikaat het steeds 'n kloktoets of 'n hernuwing nodig, en 'n verwerpte rekening het steeds die regte geloofsbriewe nodig. Hou die bedieneridentiteitstoetse wat die operateur verskaf het, want 'n bekende poortnommer verifieer niemand nie. 'n Poort wat antwoord sê net dat iets luister.
As die tonnel opkom en bestemmings steeds misluk, is die oorblywende probleem roetering of naamresolusie ná die verbinding, nie die vervoer nie. Volg daardie pad in plaas daarvan om deur poorte te sirkel, want dit is hoe 'n middag verdwyn. Die profiel sê vir jou watter vervoer om te probeer; dit sê nooit vir jou waarom die UDP-roete gefaal het nie.