nftables: inserați regula de permisiune VPN înaintea handle-ului de drop

Puneți o regulă de permisiune în locul greșit și se comportă ca și cum nu ar exista nicio regulă. În nftables, alegerea dintre insert și add decide pe ce parte a unei reguli referite ajunge noua instrucțiune, iar un handle numește regula în setul de reguli activ, nu numărul ei de linie. Dacă plasarea este greșită, pachetul ajunge mai întâi la drop.

Comparația de mai jos folosește un peer fix și un singur schimb de ascultător extern. Este intenționat îngustă; înlocuirea unei întregi lanț este o altă modificare, cu alt profil de risc.

Două plasări, două rezultate diferite

insert așază o regulă înaintea regulii referite. add o așază după ea. Dacă regula referită este drop-ul terminal al fluxului, cele două comenzi produc rezultate opuse chiar și atunci când textul regulii este identic.

Omiterea unei locații are propriul comportament implicit, ceea ce este încă un motiv să nu copiați o comandă de pe un forum fără să citiți de ce este ancorată. Ancora este întreaga decizie. Notați partea dorită înainte de a tasta comanda. insert și add diferă printr-un singur cuvânt în fișier.

Plasarea este relativă la o regulă dintr-un lanț anume. Mutarea aceleiași instrucțiuni într-un alt lanț sau la o altă prioritate hook schimbă ce pachete vede, chiar și atunci când sintaxa regulii pare corectă.

Un handle identifică o regulă, nu un număr de linie

Un handle precum 42 este un identificator în starea curentă a setului de reguli. Nu este a patruzeci și doua regulă și nu este stabil între gazde, reconstrucții sau un manager care își reîncarcă configurația.

Localizați lanțul și drop-ul terminal real înainte de a alege ancora. Apoi confirmați handle-ul pe acea regulă în aceeași listare care arată drop-ul, astfel încât numărul și regula să fie citite împreună. Un handle citit dintr-o listare veche poate aparține deja altei reguli. Recitiți-l în sesiunea care va aplica modificarea.

iptables --version
nft -a list ruleset

Versiunea iptables raportează ce backend este folosit. Un set de reguli iptables-nft și un tabel nativ administrat independent pot coexista, așa că o listare dintr-un singur frontend nu este automat imaginea completă a filtrării. Verificați ambele vederi înainte de a alege un lanț.

Găsiți lanțul și regula care chiar face drop

Citiți hook-ul de intrare, prioritatea lanțului și regula care respinge acest flux de ascultător. Un tabel inet poate purta ambele familii de adrese, dar o regulă individuală poate totuși să corespundă doar IPv4.

Luați un peer aprobat, folosind ca exemplu 198.51.100.25 din intervalul de documentare. Un fișier nativ revizuit ar putea plasa o permisiune externă înaintea handle-ului 42:

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

Înlocuiți familia, tabelul, lanțul, handle-ul, interfața de intrare și peer-ul după inspecție. Exemplul folosește forma de plasare pe handle documentată pentru nft 1.0.9 și aparține unui fișier de intrare; citarea acoladelor este o chestiune separată atunci când comanda este tastată interactiv.

Păstrați clar proprietarul configurației. Un manager care își reconstruiește regulile poate suprascrie o modificare din timpul execuției, iar un script de pornire care codifică rigid un handle învechit fie va eșua, fie se va atașa la regula greșită.

Permisiunea este limitată, drop-ul este terminal

Un verdict de permisiune încheie evaluarea pe calea sa curentă, dar un lanț de bază aplicabil mai târziu poate totuși să elimine pachetul. Un verdict de drop este terminal. De aceea un contor de permisiuni crescător nu este dovada că fluxul a reușit.

Inspectați toate prioritățile hook relevante în loc de un singur lanț izolat. Un pachet poate trece de un filtru de intrare și totuși poate fi respins de hook-ul altui tabel la o prioritate diferită. Enumerați fiecare lanț de bază care poate vedea fluxul.

Regula aceea acoperă doar schimbul de ascultător extern. ESP încapsulat în transport, ESP nativ, peer-i IPv6 și traficul decriptat din interiorul tunelului au toate nevoie de politici proprii. Nu este un firewall VPN de site complet.

Verificați fișierul, apoi validați rezultatul live

Rulați o verificare de sintaxă și de tranzacție pe fișierul revizuit înainte de a-l aplica. Modul de verificare raportează dacă nft poate analiza și pregăti modificarea; nu o aplică și nu dovedește că un alt hook va permite pachetul. Fișierul rămâne o propunere până când proprietarul îl aplică:

nft -c -f reviewed-vpn-rule.nft

Aplicați-l prin procesul controlat al proprietarului și păstrați accesul de recuperare. Dacă regula este greșită, drop-ul pe care încercați să îl precedeți poate tăia și calea pe care o folosiți pentru a o corecta.

După modificare, observați o nouă încercare a unui peer permis și verificați că sursele din afara peer-ului aprobat sunt încă respinse. Mutați regula durabilă în managerul care deține setul de reguli, deoarece handle-urile din timpul execuției localizează obiectele curente în loc să le identifice între porniri.