OpenVPN pe portul 53: trei conversații pe care oamenii le confundă
Rezolvarea endpointului, transportul criptat și DNS-ul de după tunel sunt trei conversații. Identifică ce etapă a eșuat înainte de a schimba un port sau un resolver.
Rapoartele care spun că VPN-ul este blocat pe portul 53 amestecă trei observații care eșuează din motive diferite. Rezolvarea numelui endpointului are loc înainte să existe vreun tunel, transportul criptat este o conversație separată, iar interogările DNS făcute după aceea sunt a treia. Fiecare are propria semnătură de eșec, și doar una dintre ele se referă la DNS.
Sortează pachetele după scop înainte de a schimba ceva, pentru că remedierea urmează etapa.
Trei conversații, un număr de port
Prima conversație este o căutare de nume pentru endpoint: mașina ta întreabă resolverul configurat unde se află vpn.example.com, iar răspunsul ajunge prin DNS obișnuit înainte ca clientul să trimită un singur pachet de tunel. A doua este transportul OpenVPN în sine, care se conectează la adresa produsă de căutare pe protocolul și portul pe care le numește profilul. A treia are loc după ce tunelul este ridicat, când aplicațiile cer nume și setările de resolver trimise decid cine răspunde.
Aceste trei pot reuși sau eșua independent. Un client poate rezolva perfect endpointul și totuși poate să nu ajungă la listener, și poate stabili un tunel în timp ce fiecare căutare de nume internă eșuează pentru că setările DNS nu au ajuns niciodată.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Citește tabelul ca pe o listă de verificare, nu ca pe o descriere. Dacă numele endpointului nu se rezolvă, nimic ulterior nu poate funcționa, iar tunelul nu începe niciodată.
Numărul de port nu numește aplicația
Portul 53 transportă DNS prin convenție, iar un operator OpenVPN poate publica acolo și un listener, și exact de aceea numărul este un identificator slab. O sesiune OpenVPN pe UDP 53 rămâne o sesiune OpenVPN, iar o interogare DNS către un server pe portul 53 nu spune nimic despre dacă un tunel este permis. Liniile proto și remote ale profilului definesc endpointul extern; numărul de port nu definește nimic de unul singur.
Asta taie în ambele direcții la diagnosticare: o sondă UDP generică spre portul 53 dovedește că un port răspunde, nu că serviciul VPN răspunde. Testează cu clientul real și profilul real, pentru că doar așa se exersează handshake-ul pe care serviciul îl așteaptă.
Dovedește listenerul înainte de a da vina pe rețea
Pe server, verifică ce este legat cu ss -lunp | grep 53 și compară cu protocolul și portul profilului. Din rețeaua clientului, rulează clientul cu mai mult detaliu ca jurnalul să arate ce adresă și transport a încercat. Dacă serverul ascultă și pachetele clientului nu ajung, calea sau politica le refuză, iar aceea este o conversație cu proprietarul rețelei, nu un motiv de a schimba portul.
Un alt port ajută doar când serviciul ascultă într-adevăr acolo și implementarea permite asta. Mutarea unui listener pentru a ocoli filtrarea unei rețele administrate este o decizie de politică, nu un pas de depanare. Întreabă proprietarul rețelei ce este permis înainte de a schimba serviciul, pentru că o soluție ocolitoare care încalcă politica este închisă oricum mai târziu. Notează acel răspuns lângă profil ca următoarea persoană să nu repete cererea.
Verifică DNS-ul după tunel, separat
Odată ce tunelul este ridicat, inspectează starea resolverului pe interfața VPN și interoghează un nume intern și un nume public. Dacă numele interne eșuează în timp ce tunelul transportă trafic, setările DNS trimise nu au fost aplicate, ceea ce este o chestiune de integrare a clientului și nu de transport. Dacă numele publice eșuează și cele interne funcționează, politica de tunel divizat face ceea ce a fost configurată să facă.
Lasă modificările DNS la proprietarul resolverului. Suprascrierea unei configurații de resolver administrate pentru a trece un test poate rupe numele private pentru tot restul de pe mașină. Dacă tunelul trimite un resolver și clientul îl ignoră, repară integrarea clientului în loc să adaugi o intrare statică în altă parte. Intrările statice ascund eșecul până când cineva schimbă rețeaua. Notează ce resolver ar trebui să răspundă fiecărui spațiu de nume.