Unde merge NAT-ul VPN în before.rules al UFW și cum îl testezi

O regulă NAT care funcționează când este tastată într-un shell eșuează când este lipită în before.rules, pentru că acel fișier nu este un script. Este un document în format de restaurare cu secțiuni de tabel, declarații de lanț și un marcaj COMMIT pentru fiecare tabel. O linie în locul greșit fie întrerupe întreaga restaurare, fie aruncă în tăcere reguli despre care credeai că există. Procedura de mai jos pune fragmentul acolo unde îl așteaptă cadrul și dovedește rezultatul înainte de următoarea reîncărcare.

O comandă de shell nu este un fișier de restaurare

O linie care începe cu iptables -t nat este o instrucțiune pentru binarul iptables, în timp ce fișierul pe care UFW îl citește este descrierea unui set complet de reguli. Diferența nu este cosmetică: formatul de restaurare trebuie să știe în ce tabel se află, ce lanțuri există și unde se termină tabelul. O comandă lipită în acel document este fie o eroare de sintaxă, fie, mai rău, o regulă atașată tabelului greșit. Cadrul încarcă aceste fișiere prin instrumente de restaurare exact pentru că sunt declarative, nu secvențiale.

Documentul este încărcat și ca un întreg, așa că o secțiune malformată poate opri aplicarea restului fișierului. De aceea o mică greșeală într-un fragment NAT duce cu ea și regulile de filtrare, și așa o modificare de firewall devine o întrerupere.

Pune fragmentul în secțiunea de tabel existentă

Un fragment NAT are o formă, iar forma contează mai mult decât textul regulii din interior. Antetul tabelului deschide secțiunea, declarațiile de lanț stabilesc contoarele, regulile urmează, iar un COMMIT închide secțiunea.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Pool-ul și interfața de mai sus sunt substituenți pentru valorile tale; structura este partea care merită copiată. Dacă fișierul conține deja o secțiune *nat, adaugă regula în acea secțiune în loc să deschizi una a doua, pentru că formatul așteaptă un COMMIT pe tabel, iar două secțiuni pentru același tabel sunt o reparație care așteaptă să se întâmple. Păstrează neatinse definițiile de lanț ale distribuției, inclusiv cele adăugate de furnizor pentru propria integrare. Manualul cadrului UFW documentează fișierele before, user și after împreună cu cerința unui COMMIT corespunzător.

Dacă fișierul se dovedește gol, nu îl completa dintr-un tutorial. Confirmă ce pachet îl deține și care este de fapt politica activă, pentru că un fișier persistent gol nu dovedește că nucleul nu are reguli, iar un set de reguli încărcat nu dovedește că următoarea reîncărcare va avea un fișier complet de citit. Restaurează mai întâi linia de bază acceptată, apoi reaplică modificările de site peste ea.

Testează candidatul fără a-l aplica

Instrumentul de restaurare poate analiza și construi un set de reguli fără a-l aplica, iar acesta este cel mai ieftin test disponibil. Rulează-l pe o copie protejată, nu pe fișierul activ, și citește textul erorii, nu doar starea de ieșire. O eroare de analiză numește o linie și de obicei un tabel, ceea ce este mai mult decât îți va spune o reîncărcare eșuată.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Trecerea acestei verificări dovedește că documentul este analizat și nimic altceva. Nu dovedește că candidatul mai conține fiecare lanț de care depinde UFW, că permite doar sursele intenționate sau că administrarea la distanță rămâne accesibilă. Acestea sunt evaluări separate, iar ultima merită o a doua sesiune deschisă înainte de a începe.

Alege instrumentul care corespunde backend-ului instalat și familiei de adrese. Un host care rulează backend-ul nft prin stratul de compatibilitate are nevoie de comanda corespunzătoare, iar regulile IPv6 trăiesc într-un fișier complet diferit.

Ține redirecționarea, NAT-ul și politica de acces separate

Traducerea sursei rezolvă o problemă de adresare și nu acordă nimic. Redirecționarea este o permisiune separată controlată de un sysctl și de tabelul de filtrare, și este cea pe care oamenii o uită când un tunel rutează dar nu lasă traficul să treacă. Politica de acces este o a treia decizie despre ce surse pot ajunge la ce servicii, și nicio regulă NAT nu o exprimă. Tocmai păstrarea celor trei separate face o defecțiune diagnosticabilă în loc de un singur simptom vag.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Citește aceste trei ieșiri împreună, nu una câte una. O regulă masquerade cu redirecționarea dezactivată produce un client care se conectează și nu ajunge nicăieri, ceea ce din partea clientului arată exact ca o defecțiune de rutare și trimite oamenii la fișierul greșit. Tabelul de filtrare este și locul unde se ascunde un accept prea larg, așa că verifică politica lui implicită cât timp ești acolo.

Verifică o reîncărcare, un refuz și o pierdere de VPN

Trei observații compun un test de acceptare complet: reîncărcarea reușește, o operațiune de client permisă funcționează și o cerere care ar trebui refuzată este într-adevăr refuzată. A treia este cea care este omisă, și este singura dovadă că politica face ceva.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Apoi testează defecțiunea pentru care ai proiectat. Doboară tunelul și observă ce face hostul, pentru că o politică ce funcționează doar cât timp VPN-ul este pornit este o politică cu o dependență nedeclarată. Reîncarcă încă o dată după aceea pentru a dovedi că fișierul, și nu o stare de execuție rămasă, produce rezultatul funcțional.

NAT-ul IPv4 nu spune nimic despre IPv6, așa că precizează acoperirea intenționată pentru ambele familii în aceeași notă ca regula. Scopul este o politică gestionată coerentă, iar un fragment care s-a întâmplat să fie analizat nu este dovada ei.