Ajută într-adevăr TCP 443? Doar dacă serverul ascultă acolo
Un profil TCP este o soluție de rezervă, nu o deghizare. Verificați dacă serverul ascultă pe acel port, apoi cântăriți costul TCP dublu față de imposibilitatea de a vă conecta.
TCP 443 este o soluție de rezervă cu o condiție prealabilă, nu o deghizare care strecoară un tunel pe lângă orice filtru. Ajută când operatorul publică deja un ascultător TCP pe acel port și calea tolerează o conexiune care rămâne deschisă ore întregi. Eșuează, de obicei ca expirare, când lipsește una dintre cele două, iar expirarea spune rar care. Decizia de a schimba cere trei întrebări, și doar una dintre ele privește numărul portului.
Un număr de port nu este o promisiune de transport
Un port numește un punct final; TCP îl transformă într-un flux ordonat de octeți; OpenVPN decide ce călătorește în acel flux. Un server web pe același număr folosește o aranjare de aplicație complet diferită, așa că partajarea portului 443 le face pe cele două să pară asemănătoare pentru un filtru și nimic mai mult. Numărul este un indiciu pe care filtrul îl citește, nu o proprietate care schimbă ce conțin pachetele. A le trata ca pe același lucru pentru că împart un port este greșeala din spatele celei mai mari părți a confuziei de aici.
Dispozitivele intermediare iau rar o decizie simplă de permitere sau blocare privind un port. Multe inspectează primii octeți, unele fixează o destinație, iar altele resetează conexiunile care rămân deschise prea mult. De aceea același profil poate funcționa dintr-o rețea și poate expira din alta, și de aceea merită testată soluția de rezervă ca opțiune susținută, nu crezută ca promisiune. Când un filtru examinează traficul, numărul portului este doar primul lucru la care se uită.
Confirmați ascultătorul înainte de a atinge profilul
Serverul trebuie să fie configurat pentru TCP pe port, iar profilul clientului trebuie să ceară același transport. Rescrierea unui profil UDP ca să ceară TCP nu creează ascultătorul, iar expirarea rezultată nu se distinge de un firewall care aruncă portul. Descărcați profilul TCP propriu al operatorului când există, pentru că unele servicii publică un punct final și setări de identitate separate pentru fiecare transport. Editarea manuală este bună pentru un test controlat și o metodă proastă de a ghici configurația intenționată a furnizorului.
Ambele părți ale acelei potriviri apar în configurație, iar opțiunile de legătură ale proiectului OpenVPN documentează ambele forme. Perechea minimă arată astfel:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443Trei condiții decid dacă soluția de rezervă merită
Prima condiție este ca operatorul să ofere transportul deloc; fără ea nimic altceva nu contează. A doua este ca calea să țină în viață o sesiune de durată lungă, fiindcă unele rețele resetează conexiunile care rămân deschise în loc să blocheze portul de tot. A treia este dacă soluția de rezervă este o excepție deliberată sau o soluție provizorie care ascunde o defecțiune pe care nu ați remediat-o.
Fiecare condiție are o verificare ieftină. Un eșec la oricare dintre ele arată la fel din partea clientului:
| 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 |
Înainte de a compara transporturile, finalizați orice autentificare într-un portal captiv. O rețea care nu v-a admis dispozitivul blochează ambele transporturi, iar comparația măsoară atunci portalul, nu tunelul. Autentificați-vă, confirmați că navigarea obișnuită funcționează și abia apoi începeți testul.
Costul pe care îl acceptați: TCP în TCP
TCP retransmite segmentele pierdute și le păstrează ordinea. Când o aplicație care folosește și TCP rulează într-un tunel TCP, două straturi de recuperare reacționează la aceeași pierdere, iar această interacțiune face tunelul să pară lent pe o cale cu pierderi. Simptomul este întârziere și jitter, nu o eșuare curată, ceea ce face ușor de învinuit capătul îndepărtat. Măsurați de la client pe ambele transporturi înainte de a trage o concluzie.
UDP evită această imbricare, și acesta este motivul principal pentru care operatorii îl preferă și oferă TCP doar ca alternativă. O conexiune TCP stabilă rămâne mai utilă decât una UDP inaccesibilă, deci comparația este între două costuri reale, nu între o opțiune bună și una rea. Țineți dispozitivul și rețeaua de acces neschimbate cât comparați, altfel rezultatul descrie variabila greșită.
Unele funcții ale clientului sunt documentate doar pentru un transport, așa că un profil de rezervă poate renunța în tăcere la un comportament pe care contam. Citiți cerința de transport a opțiunii înainte de a trata profilul TCP ca pe o simplă schimbare.
Defecțiuni pe care alt transport nu le atinge
Un certificat expirat are în continuare nevoie de o verificare a ceasului sau de o reînnoire, iar un cont respins are în continuare nevoie de acreditările corecte. Păstrați verificările de identitate ale serverului oferite de operator, pentru că un număr de port familiar nu autentifică pe nimeni. Un port care răspunde spune doar că ceva ascultă.
Dacă tunelul urcă și destinațiile tot eșuează, problema rămasă este rutarea sau rezolvarea numelor după conexiune, nu transportul. Urmați acea cale în loc să rotiți porturile, pentru că așa dispare o după-amiază. Profilul vă spune ce transport să încercați; nu vă spune niciodată de ce a eșuat calea UDP.