Masquerade sau rutare pe politici: trafic LAN printr-o poartă VPN

A pune un LAN întreg în spatele unui tunel VPN este partea ușoară; a decide cum vede partea îndepărtată acei clienți nu este. Masquerade rescrie fiecare sursă LAN în adresa tunelului porții, astfel încât capătul îndepărtat răspunde unui singur peer. Rutarea pe politici păstrează adresele originale și cere ca partea îndepărtată să știe cum să ajungă la ele. Niciuna nu este implicită; alegerea decurge din cine deține partea îndepărtată și dacă identitatea pe dispozitiv contează.

Cele două modele promit lucruri diferite

Masquerade reduce LAN-ul la un singur host vizibil: poarta. Rețeaua îndepărtată răspunde la acea singură adresă, iar poarta traduce răspunsurile înapoi la clientul care a început fluxul. Pe partea îndepărtată nu este nevoie de nicio rută către prefixele tale private, motiv pentru care acest model supraviețuiește la un furnizor care refuză să le transporte. Poarta devine și sursa fiecărei conexiuni, așa că partea îndepărtată nu poate distinge doi clienți.

Rutarea pe politici păstrează intactă adresa fiecărui client. Rețeaua îndepărtată vede sursa reală și o poate înregistra, aplica o regulă pe host sau trimite răspunsul direct la acea adresă. Această vizibilitate este tot scopul și vine cu o obligație: partea îndepărtată trebuie să aibă o rută pentru prefixul LAN care duce înapoi prin tunel. Planifică acea rută înainte de a activa regula, fiindcă tunelul va urca oricum și vor lipsi doar răspunsurile.

Modurile de eșec diferă tot atât cât promisiunile. O regulă masquerade lipsă produce pachete care pleacă cu surse private și nu se mai întorc. O rută de întoarcere lipsă produce același simptom la rutarea pe politici, dar remedierea aparține routerului îndepărtat, nu porții.

Masquerade: un singur peer pe partea îndepărtată

Calea masquerade are o ordine care contează. Redirecționarea trebuie să fie activă înainte ca orice regulă NAT să folosească, tabela de filtrare trebuie să permită tranzitul în ambele sensuri, și abia apoi traducerea se aplică pe interfața tunelului.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Clienții au în continuare nevoie de o cale către poartă. Fie poarta este routerul lor implicit, fie poartă o rută specifică pentru prefixul îndepărtat; dacă un router separat rămâne implicit, acel router are nevoie de o rută statică pentru destinațiile tunelului, altfel pachetul merge la saltul greșit înainte ca poarta să îl vadă.

DNS este o decizie separată. Un resolver de pe partea îndepărtată răspunde doar dacă răspunsul său poate călători înapoi la client. Sub masquerade interogarea pare să vină de la poartă, așa că ruta de întoarcere a resolverului este deja satisfăcută; sub rutarea pe politici resolverul are nevoie de aceeași rută de întoarcere ca orice alt serviciu îndepărtat.

Rutare pe politici: păstrează sursa, adaugă o rută de întoarcere

Rutarea pe politici începe cu o tabelă și cu o regulă care o selectează. Traficul care intră din interfața LAN este trimis către o tabelă dedicată, iar acea tabelă poartă o rută implicită prin tunel. Tabela principală rămâne neatinsă, așa că traficul generat de poarta însăși poate urma altă cale.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

Partea îndepărtată trebuie apoi să ruteze prefixul LAN înapoi prin tunel. Aceasta este o configurație pe routerul îndepărtat, nu pe această poartă. Poarta trebuie să accepte și răspunsuri care sosesc pe o interfață diferită de cea pe care tabela principală ar prevedea-o; filtrarea laxă a căii inverse (rp_filter setat la 2) este ajustarea obișnuită când modul strict aruncă acele pachete.

Când două tuneluri sunt active, marchează fiecare flux la intrare și lasă marcajul să aleagă tabela. O regulă care se uită doar la interfața de intrare trimite traficul ambelor tuneluri în aceeași tabelă, așa că al doilea tunel fură fluxuri de la primul. Testează marcajul cu o conexiune care supraviețuiește unei reconectări, fiindcă atunci se arată o politică mixtă.

Decide după proprietate și după ce înregistrează partea îndepărtată

Dacă tunelul se termină la un furnizor, folosește masquerade. Acel operator nu va ruta intervalele tale LAN private și nu are niciun motiv să distingă clienți individuali în spatele porții tale. Un singur peer vizibil este singurul model pe care politica lui îl susține, așa că dă-i asta și ține traducerea la marginea ta. Furnizorul vede un peer, exact ceea ce așteaptă politica lui, iar clienții tăi moștenesc acea singură identitate.

Dacă ambele capete sunt ale tale și serviciile îndepărtate acționează pe adrese de sursă, rutarea pe politici își merită ruta suplimentară. Regulile de firewall, accesul pe utilizator și jurnalele de audit pot atunci distinge clienții. Dacă partea îndepărtată are nevoie doar de accesibilitate, masquerade este mai simplu și elimină o întreagă clasă de erori ale rutei de întoarcere.

Modelele hibride sunt normale: rutare pe politici în rețeaua ta, masquerade la marginea furnizorului. Important este să notezi care hop traduce și care hop rutează, fiindcă o regulă NAT adăugată din greșeală pentru un client ascunde sursa pentru fiecare client din același lanț.

Verifică de la un client, apoi de la un al doilea client

Rulează testul acolo unde începe traficul. Verifică ruta folosită de host, urmărește pachetul apărând pe interfața tunelului și inspectează conntrack pentru traducere. Această succesiune dovedește că pachetul a luat calea dorită, nu că a ajuns pur și simplu undeva.

Repetă testul după o reconectare. O regulă masquerade care numește interfața supraviețuiește unei adrese noi de tunel; o regulă care numește adresa veche nu. Apoi testează un al doilea host LAN, fiindcă un model care funcționează pe o mașină depinde adesea de ruta proprie a acelei mașini, nu de politica porții.

Notează modelul ales, sursa tradusă sau păstrată și proprietarul rutei de întoarcere în notele porții. Altfel următoarea persoană care adaugă un client sau un tunel va ghici, iar ghicitul este felul în care o configurație LAN-spre-VPN care funcționează devine parțială.