SNAT, DNAT și Masquerade: ce face fiecare regulă NAT din VPN

Pune o captură pe ambele părți ale unui gateway VPN și un singur flux poate arăta patru adrese diferite. NAT-ul de sursă rescrie de unde susține pachetul că vine; NAT-ul de destinație rescrie unde merge. Masquerade nu este o a treia direcție, este o regulă de NAT de sursă care ia adresa de pe interfața de ieșire în loc de o valoare fixă. Numește care dintre cele trei îți trebuie cu adevărat și majoritatea tichetelor „VPN-ul e stricat“ se reduc la o întrebare despre calea de întoarcere.

Ce rescrie fiecare regulă

NAT-ul de sursă, scris de obicei SNAT, schimbă adresa de sursă a unui flux când acesta părăsește un router sau un gateway. Serviciul care primește răspunde la adresa tradusă, iar cutia care traduce anulează schimbarea folosind starea pe care a păstrat-o pentru conexiunea respectivă. În Linux starea aceea trăiește în conntrack, de aceea conntrack -L afișează tuplurile original și de răspuns unul lângă altul.

NAT-ul de destinație, DNAT, schimbă în schimb destinația. Un pachet adresat unei adrese publice pe UDP 51820 poate fi rescris către un server WireGuard intern la 10.8.0.2:51820. Așa publică un router de acasă sau un balansator din cloud un ascultător VPN, iar asta nu spune nimic despre ce poate transporta tunelul după aceea.

Masquerade aparține familiei SNAT. Regula nu numește nicio adresă; folosește adresa pe care o are interfața de ieșire când pachetul pleacă. Linux îi dă o țintă proprie, iar aceasta este alegerea obișnuită pe o interfață WAN care își ia adresa prin DHCP sau PPPoE.

Unde trăiește maparea decide defecțiunea

Notează tuplul la fiecare graniță: înainte de tunel, în interiorul lui și pe interfața publică. O captură din interiorul tunelului diferă în mod legitim de una din exterior, iar cine le compară pe cele două fără să știe unde are loc traducerea va urmări gazda greșită.

Traficul de întoarcere trebuie să treacă prin dispozitivul care ține maparea. Dacă răspunsul ia altă rută, un al doilea uplink, o rută de politică sau un furnizor care nu a auzit niciodată de intervalul tău privat, traducerea inversă cu stare nu are loc niciodată, iar clientul vede trafic unidirecțional. Adăugarea de mai mult NAT de sursă rareori repară o rută de întoarcere lipsă; poate ascunde simptomul pe un flux și, în același timp, rupe politica bazată pe adrese peste tot în rest.

Cealaltă greșeală frecventă este să te aștepți ca tunelul să creeze rutabilitate. Un client privat ale cărui pachete ies pe internet are nevoie de o ieșire validă: o rută implicită, un gateway care transmite mai departe și, de obicei, traducere de sursă către o adresă publică. Criptarea singură nu face o adresă privată accesibilă.

Masquerade sau SNAT explicit

Compară-le după ce promit. Masquerade alege adresa de ieșire, SNAT explicit o fixează. Pe un gateway cu adresă publică stabilă, fixarea le dă jurnalelor și listelor de permisiuni ale partenerilor o singură valoare predictibilă. Pe un link WAN dinamic, o adresă SNAT fixată devine greșită în momentul în care se schimbă concesiunea, iar exact acesta este cazul pentru care a fost construit Masquerade.

Domeniul contează la fel de mult ca alegerea. O regulă Masquerade care se potrivește fiecărui pachet care părăsește gateway-ul, fără limită de sursă sau destinație, traduce și traficul pe care voiai să-l lași intact, inclusiv trafic către alte rețele private. Limitează regula la intervalul clienților, la destinația dorită și la interfață.

La IPsec bazat pe politici mușcă cel mai tare. Ghidul de forwarding al strongSwan parcurge activarea forwardingului IP și adăugarea unei reguli SNAT de sursă pentru clienți, iar aceeași documentație acoperă excluderea traficului care trebuie să-și păstreze adresa originală. Tradu o sursă înainte ca politica de securitate să se potrivească pe ea și tunelul poate urca în timp ce traficul tot cade, pentru că pachetul nu mai arată ca selectorul negociat.

Decide și ce trebuie să vadă capătul îndepărtat. După traducere un serviciu vede gateway-ul, nu clientul individual. Asta simplifică rutarea de întoarcere și în același timp aplatizează jurnalele și anulează listele de permisiuni pe client. Dacă păstrarea adreselor clienților contează, planifică o cale de întoarcere rutată în loc să le ascunzi ca să treacă un test.

Citirea regulilor pe un gateway Linux

Un gateway de acces la distanță cu clienți în 10.8.0.0/24 și o interfață WAN numită eth0 are nevoie de forwarding activat și de o politică de filtrare care permite fluxul, înainte ca vreo regulă NAT să ajute. Versiunea iptables ține ambele direcții în tabela nat:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

Forma nftables folosește aceleași două cârlige cu o interfață numită și un lanț explicit:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Ambele fragmente presupun că lanțul de filtrare acceptă deja fluxul transmis. NAT nu este o regulă de permisiune, iar un pachet tradus corect poate fi totuși aruncat o tabelă mai încolo. Confirmă maparea vie cu conntrack -L, confirmă ce este încărcat cu nft list ruleset sau iptables-save -t nat, apoi capturează pe ambele interfețe ca să vezi că adresa chiar se schimbă.

Moduri de eșec care arată ca o regulă proastă

Traficul de ac tip este clasicul. Un client intern care ajunge la un server intern prin adresa publică a serverului are nevoie de DNAT la intrare și de o traducere de sursă la ieșirea de întoarcere, altfel serverul răspunde direct clientului și răspunsul este respins. Corectarea este o a doua regulă, mai îngustă, pentru acel caz intern-către-public, nu o regulă Masquerade mai largă pentru tot.

Traducerea dublă este cea tăcută. Un client care este deja în spatele NAT de nivel operator ajunge la gateway-ul tău cu o adresă pe care nu o poți ruta înapoi, așa că traduci din nou. Funcționează, dar jurnalele poartă acum două salturi de adresare privată și orice investigație are nevoie de ambele mapări. IPsec bazat pe politici adaugă o a treia răsucire: traduce înainte de potrivirea politicii și obții un SA ridicat fără trafic care să treacă, ceea ce se citește ca un bug de firewall, nu de NAT.

Apoi există testul care trece și implementarea care eșuează. Rularea comenzii NAT de mână dovedește mecanismul, nu configurația. O regulă adăugată în timpul rulării dispare la repornire sau la următorul eveniment de interfață, iar o regulă Masquerade legată de o interfață care își schimbă numărul poate schimba în tăcere adresa pe care o vede capătul îndepărtat. Pune regula în configurația firewallului care o deține și retestează după o reconectare.

Listă de verificare înainte de a salva regula

Numește mai întâi direcția: sursă, destinație sau ambele. Apoi identifică cine trebuie să țină starea — gateway-ul, routerul de deasupra sau partenerul IPsec — și confirmă că calea de răspuns se întoarce prin el. Limitează regula la intervalul de clienți, destinația și interfața pe care le urmărești cu adevărat, și decide dinainte dacă capătul îndepărtat trebuie să vadă gateway-ul sau adresa originală a clientului.

Testează de la un client, nu de la gateway. Un browser pe gateway-ul însuși poate ocoli complet regula de traducere pentru clienți, așa că o pagină care funcționează acolo nu dovedește nimic despre tunel. Trimite o cerere originată la client, urmărește contoarele și tabela conntrack, și repetă după o reconectare a tunelului și o schimbare de adresă WAN dacă vreuna dintre ele este posibilă acolo unde lucrezi.