Portul sursă al clientului față de listenerul serverului într-un flux VPN
Comparați cele două numere de port dintr-un tunel: listenerul fix al serverului și sursa efemeră a clientului, și cum traducerea routerului se află între ele.
În aceeași conversație apar două numere și niciunul nu este greșit. Jurnalul serverului arată listenerul care oferă serviciul, laptopul arată socketul care a trimis datagrama, iar un router între ele poate rescrie al doilea la ieșire. Compararea capetelor conversației este mai utilă decât compararea cifrelor. Comparația de mai jos ține separat listenerul, socketul clientului și sursa tradusă, pentru că răspund la întrebări diferite.
Două numere care descriu capete opuse
Portul configurat al serverului este destinația pe care clientul o apelează. Este fixat de politică, apare în profil și trebuie să fie deschis pe partea serverului. Portul sursă al clientului este ales local, de obicei din intervalul efemer, și există pentru ca răspunsul să aibă unde ateriza. Se poate schimba la fiecare reconectare, iar nimic din proiect nu depinde de stabilitatea lui.
Un router între ele poate rescrie acea sursă în propria mapare 'NAT'. De aceea numărul observat pe server adesea nu are nicio legătură cu cel ales de laptop.
Unde se schimbă numărul sursei la ieșire
Luați un exemplu IPv4 inventat: un client în spatele unui router care traduce, un server cu un singur listener 'UDP' și o singură datagramă care traversează ambele. Tabelul numește fiecare capăt și ce i se întâmplă, în loc să redea pachetul în trei puncte de observare.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
Destinația este constantă în fiecare rând, iar singurul lucru care se schimbă este identitatea sursei. Cerințe UDP NAT disting o adresă și un port interne de maparea externă, ceea ce este exact diferența dintre al doilea și al treilea rând. Un router poate păstra portul sursă al clientului sau poate alege altul; păstrarea nu este ceva ce o aplicație ar trebui să presupună.
Citiți cele trei capete de pe gazdele înseși
Listele de mai jos provin de pe trei mașini diferite și împreună arată întreaga conversație. Rulați prima pe server, a doua pe client și a treia oriunde există maparea. O singură linie de jurnal nu arată niciodată toate trei.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194Prima listă dovedește că serverul este legat de portul serviciului și arată ce proces îl deține. A doua arată socketul local al clientului și destinația pe care a apelat-o. A treia arată maparea creată de router, și este singurul loc unde apare sursa tradusă. Citiți-le în această ordine și cele două numere nu mai par contradictorii.
Ce schimbă o reconectare și ce nu
Unele routere păstrează portul sursă al clientului când este liber, iar altele alocă unul diferit de fiecare dată. Ambele comportamente sunt normale, iar o aplicație care îl cere pe primul se va rupe pe al doilea. O schimbare de mapare după o reconectare sau o schimbare de rețea nu este o defecțiune a serverului: clientul deschide un socket nou, routerul alocă ce are, iar serverul vede o sursă nouă pe același listener. O defecțiune ar fi să ne așteptăm ca serverul să accepte trafic adresat unei porturi de client arbitrare.
Clienții OpenVPN din comunitate obțin acest comportament prin nobind, care lasă sistemul de operare să aleagă portul local; portul îndepărtat vine în continuare din profil. Legarea explicită este o alegere deliberată, nu o cerință a protocolului. Serverul continuă să ofere un singur capăt în timp ce clienții își aleg propriile identități locale.
Etichetați straturile separat în înregistrare
În interiorul tunelului există o a doua conversație cu porturi proprii. O cerere HTTPS purtată de tunel are destinația TCP 443, în timp ce conexiunea criptată exterioară folosește UDP 1194, așa că schimbarea portului sursă exterior nu schimbă nimic în serviciul interior.
Chiar și la stratul exterior, protocolul contează. UDP 1194 și TCP 1194 sunt capete diferite, iar un listener 'TCP' nu va primi niciodată o datagramă UDP doar pentru că numărul se potrivește. Când documentați o implementare, etichetați listenerul serverului, socketul clientului și sursa tradusă ca trei lucruri distincte și adăugați transportul la fiecare.
Apoi lăsați politica să urmeze rolurile. Serverul deschide transportul prevăzut pe listenerul său și autentifică în continuare partenerul; firewallul clientului admite răspunsurile la propriul schimb de ieșire fără a publica un serviciu de intrare. Un filtru fără stare are nevoie de direcția de retur scrisă explicit, iar acesta este motivul practic pentru care distincția contează dincolo de diagramele îngrijite.