NAT pentru LAN prin tun0 pe un gateway VPN OpenBSD

Doi ingineri cu același gateway OpenBSD îți vor da adesea două seturi diferite de reguli pentru a ajunge la o rețea îndepărtată, iar ambele pot fi apărate. Alegerea între traducerea sursei și o rută de retur nu este deloc o problemă de sintaxă. Totul depinde de ce știe deja partea cealaltă despre 192.168.88.0/24 și de ce trebuie să păstrezi în jurnale. Greșește aici și linia nat-to va arăta perfect corectă în timp ce răspunsurile dispar în gateway-ul implicit îndepărtat.

Rutarea și rescrierea răspund la întrebări diferite

Tabela de rutare decide că 172.20.0.0/16 este accesibilă prin tun0, iar această decizie se ia înainte de a fi consultată orice traducere pf. Apoi traducerea sursei schimbă antetul pachetului astfel încât capătul îndepărtat să vadă adresa tunelului gateway-ului în loc de un host din LAN. Niciun mecanism nu îl înlocuiește pe celălalt: o regulă nat nu poate crea o rută, iar o rută nu poate convinge un router îndepărtat care nu a auzit niciodată de subrețeaua ta privată. Când partea cealaltă nu are cale de întoarcere, răspunsurile sunt aruncate sau trimise către gateway-ul ei implicit, iar nicio ajustare a regulilor nu repară asta.

Spus simplu, forwardingul răspunde unde merge traficul, iar traducerea răspunde de unde pare că vine. Ține-le în cutii mentale separate în timp ce proiectezi setul de reguli.

Trei condiții care decid

Pune trei întrebări în ordine și proiectul de obicei se alege singur. Are rețeaua îndepărtată o rută statică ce indică adresa tunelului pentru 192.168.88.0/24, sau administratorul ei controlează routerele de pe acea cale? Dacă da, lasă adresele LAN să călătorească nemodificate și sari complet peste traducere. Ai nevoie de vizibilitate per client pe partea cealaltă, fie pentru politica de acces, fie pentru o urmă de audit? Dacă da, păstrarea sursei merită munca de rutare. Este adresa tunelului suficient de stabilă pentru a fi scrisă într-o rută îndepărtată, sau se schimbă între reconectări?

Dacă vreun răspuns este nu sau necunoscut, nat-to este opțiunea pragmatică și totodată cea reversibilă. O regulă de traducere iese într-o singură linie de îndată ce partea cealaltă adaugă o rută corectă. O rută de retur care nu a fost niciodată instalată te costă un fir de suport de fiecare dată când cineva întreabă de ce tunelul funcționează doar într-o direcție.

Plasează fragmentul astfel încât pf să îl evalueze cu adevărat

Fragmentul de mai jos presupune că LAN-ul este 192.168.88.0/24, rețeaua îndepărtată este 172.20.0.0/16 și interfața tunelului este tun0. Nimic din el nu alege următorul salt. Doar rescrie sursa pachetelor care ies deja prin tunel.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Două detalii din acea primă linie duc cea mai mare parte a greutății. Parantezele din jurul tun0 îi spun lui pf să citească adresa interfeței de fiecare dată când construiește o intrare de stare, ceea ce contează când tunelul este renumerotat după o reconectare. Cuvântul match înseamnă că regula rescrie și apoi cade mai departe, așa că o regulă pass separată tot trebuie să admită fluxul. Interfața numită în linia match trebuie să fie și cea pe care o alege tabela de rutare, altfel pf evaluează regula pe o cale de ieșire diferită de cea pe care merge pachetul.

Nu uita partea de kernel. Forwardingul IPv4 trebuie să fie activat, iar regulile pass cu stare pentru tunel și LAN trebuie să existe înainte ca toate acestea să aibă sens. Secțiunea PF NAT din FAQ-ul OpenBSD este referința potrivită pentru ordinea cuvintelor-cheie aici.

Verifică setul de reguli înainte să ai încredere în trafic

Verifică mai întâi sintaxa cu pfctl -nf /etc/pf.conf, care analizează fișierul fără a-l încărca. Apoi încarcă politica și recitește ce ține kernelul cu adevărat, pentru că o regulă analizată curat poate fi totuși umbrită sau atașată la interfața greșită. pfctl -sn tipărește regulile de traducere în forma încărcată, iar pfctl -sr tipărește regulile de filtrare în ordinea evaluării.

Apoi urmărește firul. Pe gateway, tcpdump -ni tun0 'host 172.20.0.10' arată dacă adresa sursă care iese din tunel este adresa tunelului sau hostul din LAN. Un netstat -rn -f inet rapid confirmă pe ce interfață se rezolvă destinația. Odată ce traficul curge, pfctl -ss listează intrările de stare; dacă un flux nu a produs stare, pachetul nu a întâlnit niciodată o regulă care să creeze una.

Dacă partea tunelului pare corectă și răspunsurile tot nu sosesc, oprește editarea pf. Defecțiunea rămasă este pe routerul îndepărtat, unde răspunsul este trimis către o adresă privată pe care acea parte nu o poate atinge.

Când traducerea costă mai mult decât economisește

Traducerea ascunde clienții, iar uneori exact asta este schimbul greșit. Subrețelele suprapuse sunt un caz: dacă partea cealaltă folosește și ea 192.168.88.0/24 intern, prezentarea hosturilor din LAN drept gateway înrăutățește coliziunea în loc să o amelioreze. Politicile IPsec care selectează traficul după perechea de adrese sunt alt caz, pentru că baza de date a politicii de securitate este potrivită înainte de traducere și nu vede niciodată pachetul rescris. Orice implementare care facturează, limitează sau auditează pe utilizator pierde și identitatea de care are nevoie în momentul în care sursa se prăbușește într-o singură adresă.

Derivații portabili ai pf sunt o capcană separată. Produsele care își generează propriile fișiere de reguli se așteaptă ca NAT să fie configurat prin interfața lor, iar fragmentele editate manual sunt suprascrise la următoarea reîncărcare. Seturile de reguli copiate din ghiduri scrise înainte de a exista cuvântul-cheie match nu se vor încărca pe un kernel actual, așa că portează sintaxa și citește eroarea în loc să ghicești.

Regula de decizie care supraviețuiește contactului cu rețele reale este scurtă: instalează o rută de retur când poți, tradu când nu poți, și notează care dintre cele trei condiții te-a făcut să alegi. Acea notă economisește o după-amiază pentru următoarea persoană.