nftables: inseriu la regla d’autorització de VPN abans de l’identificador de descart

Col·loqueu una regla d’autorització en la posició equivocada i es comporta com si no n’hi hagués cap. A nftables, l’elecció entre insert i add decideix a quin costat d’una regla referenciada cau la nova instrucció, i un identificador anomena la regla del conjunt de regles actiu, no el seu número de fila. Si la posició és incorrecta, el paquet arriba primer al descart.

La comparació de sota fa servir un parell fix i un intercanvi de l’oient exterior. És deliberadament estreta; substituir una cadena sencera és un canvi diferent amb un perfil de risc diferent.

Dues posicions, dos resultats diferents

insert col·loca una regla abans de la regla referenciada. add la col·loca després. Si la regla referenciada és el descart terminal del flux, aquestes dues ordres produeixen resultats oposats encara que el text de la regla sigui idèntic.

Ometre una ubicació té el seu propi comportament per defecte, que és una altra raó per no copiar una ordre d’un fòrum sense llegir a què està ancorada. L’àncora és tota la decisió. Anoteu el costat previst abans d’escriure l’ordre. insert i add es diferencien en una paraula al fitxer.

La posició és relativa a una regla d’una cadena concreta. Moure la mateixa instrucció a una altra cadena o a una altra prioritat de hook canvia quins paquets veu, encara que la sintaxi de la regla sembli correcta.

Un identificador identifica una regla, no un número de línia

Un identificador com 42 és un identificador de l’estat actual del conjunt de regles. No és la regla quaranta-dos i no és estable entre amfitrions, reconstruccions o un gestor que recarrega la seva configuració.

Localitzeu la cadena i el descart terminal real abans de triar l’àncora. Després confirmeu l’identificador d’aquesta regla al mateix llistat que mostra el descart, perquè el número i la regla es llegeixin junts. Un identificador llegit d’un llistat antic pot pertànyer ja a una altra regla. Torneu-lo a llegir a la sessió que aplicarà el canvi.

iptables --version
nft -a list ruleset

La versió d’iptables indica quin backend s’utilitza. Un conjunt de regles iptables-nft i una taula nativa gestionada de manera independent poden coexistir, així que un llistat d’un sol frontal no és automàticament la imatge completa del filtratge. Reviseu les dues vistes abans de triar una cadena.

Trobeu la cadena i la regla que realment descarta

Llegiu el hook d’entrada, la prioritat de la cadena i la regla que rebutja aquest flux d’oient. Una taula inet pot portar les dues famílies d’adreces, però una regla individual encara pot coincidir només amb IPv4.

Preneu un parell aprovat, fent servir 198.51.100.25 del rang de documentació com a exemple. Un fitxer natiu revisat podria col·locar una autorització exterior abans de l’identificador 42:

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

Substituïu la família, la taula, la cadena, l’identificador, la interfície d’entrada i el parell després de la inspecció. L’exemple fa servir la forma d’ubicació per identificador documentada per a nft 1.0.9, i pertany a un fitxer d’entrada; el citat de claus és un assumpte a part quan l’ordre s’escriu interactivament.

Mantingueu clar el propietari de la configuració. Un gestor que reconstrueix les seves regles pot sobreescriure una edició en temps d’execució, i un script d’arrencada que codifica un identificador obsolet o bé fallarà o bé s’enganxarà a la regla equivocada.

L’autorització té abast, el descart és terminal

Un veredicte d’autorització acaba l’avaluació al seu camí actual, però una cadena base aplicable posterior encara pot descartar el paquet. Un veredicte de descart és terminal. Per això un comptador d’autoritzacions creixent no és prova que el flux hagi tingut èxit.

Inspeccioneu totes les prioritats de hook rellevants en lloc d’una cadena aïllada. Un paquet pot passar un filtre d’entrada i tot i així ser rebutjat pel hook d’una altra taula a una prioritat diferent. Llisteu cada cadena base que pugui veure el flux.

Aquesta regla només cobreix l’intercanvi de l’oient exterior. ESP encapsulat en transport, ESP natiu, parells IPv6 i el trànsit desxifrat dins del túnel necessiten tots polítiques pròpies. No és un tallafoc complet de VPN de lloc.

Reviseu el fitxer i després verifiqueu el resultat actiu

Executeu una comprovació de sintaxi i transacció sobre el fitxer revisat abans d’aplicar-lo. El mode de comprovació informa si nft pot analitzar i preparar el canvi; no l’aplica ni demostra que un altre hook permeti el paquet. El fitxer continua sent una proposta fins que el propietari l’apliqui:

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

Apliqueu-ho a través del procés controlat del propietari i preserveu l’accés de recuperació. Si la regla és incorrecta, el descart que intentàveu precedir també pot tallar el camí que feu servir per corregir-ho.

Després del canvi, observeu un nou intent de parell permès i comproveu que les fonts fora del parell aprovat segueixen sent rebutjades. Moveu la regla duradora al gestor que posseeixi el conjunt de regles, perquè els identificadors en temps d’execució localitzen els objectes actuals en lloc d’identificar-los entre arrencades.