proto udp sau tcp-client: pe care o aude serverul tău?

Un profil care funcționa luna trecută acum expiră, iar cineva propune schimbarea proto udp cu proto tcp-client. Uneori este pasul corect, alteori produce un client care se conectează la un port unde nimic nu ascultă, pentru că serverul nu a fost niciodată configurat pentru celălalt transport. Directiva descrie cum vorbește partea ta; nu poate crea un ascultător la cealaltă parte. Citește profilul și serverul împreună înainte de a schimba oricare dintre ele.

Citește transportul folosit de conexiunea selectată

Un profil poate conține mai multe intrări remote, iar fiecare poate indica propriul transport. Clientul le parcurge în ordine, așa că linia pe care o vezi prima nu este neapărat cea care se aplică.

Găsește intrarea care este de fapt încercată, apoi citește-i transportul. Ordinea contează, pentru că clientul nu trece mai departe în tăcere. Unele compilări încearcă următoarea intrare doar după un timeout, așa că o alternativă funcțională de la sfârșitul fișierului este atinsă cu câteva secunde mai târziu decât te aștepți. Urmărește în jurnal ce punct final este încercat în loc să presupui că a câștigat prima linie.

Dacă fișierul are o linie proto aproape de început și mai multe intrări remote dedesubt, acea linie este valoarea implicită pentru orice remote care nu o suprascrie. O modificare locală a valorii implicite nu face nimic pentru o intrare remote care își indică propriul transport.

grep -nE '^(remote|proto)\b' client.ovpn

UDP și TCP nu sunt o setare de viteză

UDP trimite datagrame fără a construi un flux ordonat, așa că traficul tunelului însuși nu este împachetat într-un al doilea transport fiabil. TCP îți oferă o cale prin rețele care aruncă sau blochează UDP, cu prețul retransmisiei imbricate care poate face o legătură cu pierderi să se simtă mai rău.

Acesta este un schimb de accesibilitate, nu un clasament universal. Alegerea corectă este cea pe care rețeaua din fața clientului o permite. O cale care aruncă UDP pe portul VPN nu va negocia niciodată, oricât de bine ar fi scris profilul. Testează calea, apoi alege transportul.

A alege între ele doar pe baza unei măsurători este o greșeală, pentru că răspunsul depinde de ce permite rețeaua din fața ta. Un hotel sau un proxy corporativ poate permite TCP de ieșire pe 443 și nimic altceva, de aceea furnizorii oferă acea variantă. Rămâne o conexiune OpenVPN pe acel port, nu o sesiune HTTPS, chiar dacă numărul portului este cel familiar.

Ce înseamnă de fapt tcp-client

Directiva din partea clientului numește capătul care inițiază o conexiune TCP. Partea serverului folosește propria formă de ascultare, iar copierea cuvântului clientului într-o configurație de server produce un ascultător care așteaptă să fie sunat, nu unul care acceptă.

Potrivirea înseamnă că cele două capete sunt de acord asupra transportului, nu că împart același șir.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Întreabă serverul pe ce ascultă înainte de a presupune că profilul este greșit. Un ascultător UDP nu apare într-o listă de socketuri TCP, iar invers este de asemenea adevărat, așa că privește vizualizarea specifică protocolului în loc de una generică.

Când profilul este importat, dar nu se conectează niciodată

Un profil importat care expiră imediat eșuează de obicei înainte de orice autentificare. Pachetul merge către un port fără ascultător, sau rețeaua îl aruncă în tăcere.

Testează calea în cel mai simplu mod posibil: conectează-te la același host și port cu transportul pe care profilul îl afirmă, din aceeași rețea ca clientul care eșuează.

Dacă un test UDP nu obține nimic și un test TCP se conectează, serverul oferă celălalt transport, iar profilul este pur și simplu învechit. Dacă niciunul nu răspunde, problema este deasupra alegerii transportului și nicio editare a profilului nu o va rezolva. Distingerea acestor două cazuri durează un minut și economisește o oră de depanare a certificatelor care nu a fost niciodată relevantă.

Notează transportul care funcționează

Când o combinație funcționează, noteaz-o împreună cu serverul, portul și protocolul și menționează din ce rețea a fost testată.

Altfel, următoarea persoană care întâlnește un timeout va repeta același experiment în direcția opusă și poate va schimba un server care era în regulă.

Dacă furnizorul publică ambele variante, păstrează ambele fișiere și etichetează-le în funcție de rețeaua căreia i se potrivesc. Două profiluri cu nume clare împiedică amestecarea accidentală a unui transport de client cu un ascultător de server care nu a fost niciodată configurat pentru el.