NAT simetric și VPN: măsurați maparea, nu eticheta

Un fir de suport se termină cu verdictul „NAT simetric, VPN-ul nu va funcționa aici”, iar apoi clientul este reinstalat de trei ori fără motiv. Eticheta face rău pentru că răspunde la o întrebare pe care nimeni nu a pus-o. Un client care se conectează spre exterior la un server fix creează o mapare în momentul în care trimite primul pachet, iar răspunsul este lăsat să revină după reguli pe care aproape orice rețea le implementează. Ceea ce maparea dependentă de punctul final complică cu adevărat este ca doi parteneri să încerce să ajungă unul la altul în același timp, iar acesta este alt test.

Două întrebări se ascund în spatele unei etichete

Prima întrebare este dacă o gazdă din spatele acestei rețele poate deschide o sesiune către o adresă publică și un port cunoscute. Pentru un client de tunel acesta este cazul normal, iar răspunsul este aproape întotdeauna da. Routerul înregistrează sursa internă, alocă un port extern și lasă răspunsul să treacă pentru că aparține unei sesiuni începute din interior.

A doua întrebare este dacă două gazde din spatele unor rețele diferite pot găsi o cale comună și își pot trimite fără un server la mijloc. Aceasta depinde de modul în care fiecare rețea alocă acele porturi externe, și este singurul loc în care comportamentul mapării contează.

Confundarea celor două produce diagnosticul greșit clasic: o funcție între parteneri eșuează, cineva rulează un test de tip NAT, vede cea mai proastă categorie și concluzionează că nici tunelul obișnuit nu poate funcționa. Tunelul nu a fost niciodată ceea ce a eșuat.

Maparea și filtrarea sunt proprietăți separate

Terminologia RFC este mai precisă decât numele folosite de furnizori, și merită dusă în tichet pentru că încheie dispute. Maparea este felul în care este alocat portul extern. Filtrarea este ce pachete de intrare sunt lăsate să treacă. O rețea poate fi strictă într-una și liberală în cealaltă, iar acea combinație este ceea ce un protocol între parteneri trebuie să supraviețuiască.

Al treilea rând este ceea ce majoritatea routerelor de consum și operatorii mobili înțeleg prin simetric. Observați că eticheta descrie doar alocarea. O rețea cu acea mapare și filtrare liberală poate totuși accepta pachete de intrare către portul pe care tocmai l-a alocat, de aceea găurirea găurilor reușește pe unele și eșuează pe altele.

Filtrarea are cele trei cazuri ale ei și numele ei pentru fiecare. Să scrii „NAT simetric” într-un tichet când vrei să spui „filtrare dependentă de adresă și port” trimite următoarea persoană la capitolul greșit al manualului. Cele două se comportă diferit la test, așa că greșeala nu este academică.

Măsurați maparea în loc să o numiți

Puteți observa portul alocat direct din partea serverului oricărui serviciu UDP pe care îl controlați. Porniți o captură pe gazda publică, trimiteți din client și citiți portul sursă cu care a sosit pachetul:

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

Linia punctului final este cea mai utilă dintre cele trei, pentru că WireGuard înregistrează ultima adresă și ultimul port primite de la fiecare partener. Comparați acel port cu cel pe care clientul crede că îl folosește. Vor diferi ori de câte ori are loc vreo traducere, iar întrebarea importantă este dacă valoarea rămâne stabilă.

Repetați observația către un al doilea port de destinație sau un al doilea server și comparați din nou. Dacă portul extern se schimbă în funcție de destinație, maparea depinde de adresă și port. Dacă rămâne același, rețeaua vă dă o singură mapare și descoperirea are o șansă.

Instrumentele bazate pe STUN raportează aceeași clasificare într-un singur pas, și pot fi folosite când rețeaua permite UDP de ieșire către un server STUN public. Când nu permite, metoda de captură de mai sus funcționează în continuare și nu cere nimic altceva decât o gazdă pe care o controlați deja.

Alegeți o remediere care se potrivește defecțiunii

Dacă funcția care eșuează este între parteneri, răspunsurile acceptate sunt un releu, un serviciu de întâlnire la care ambii parteneri pot ajunge, sau o topologie diferită. TURN există exact pentru asta, iar un produs care livrează propriul releu vă spune că se așteaptă ca unele rețele să fie ostile.

Dacă funcția care eșuează este un tunel obișnuit, comportamentul mapării nu este problema dumneavoastră și nimic din cele de mai sus nu se aplică. Verificați că clientul chiar trimite, că serverul vede pachetul și că răspunsul se întoarce. Acea secvență înseamnă trei observații și nu cere să știți nimic despre categoria NAT a routerului.

Ce nu funcționează este să împrăștii modificări de port local până când ceva se conectează. Schimbarea portului sursă al clientului nu schimbă modul în care rețeaua alocă mapări. Un succes întâmplător la a cincea încercare este un fals pozitiv, și va fi citat ca remediere luni de zile.

Înregistrați arhitectura, nu verdictul

O notă utilă spune ce protocol, în ce direcție începe sesiunea, dacă există un releu pe traseu și ce s-a observat pe cablu. „NAT simetric, nu funcționează” este inutilizabil, pentru că este simultan greșit despre tunel și neinformativ despre traseul partenerului.

Includeți stabilitatea portului măsurată și comportamentul filtrării dacă le-ați testat. Aceste două fapte permit altcuiva să prevadă dacă o funcție nouă va funcționa în acea rețea fără a repeta întreaga investigație. Ele îmbătrânesc și mai bine decât o categorie de furnizor care înseamnă ceva ușor diferit pe fiecare pagină de ajutor.

În final, țineți la îndemână terminologia RFC 4787 când scrieți asta. Folosirea termenilor preciși costă o propoziție și împiedică următorul cititor să repete același diagnostic greșit, și exact acesta este rostul scrierii notei.