nftables: insira a regra de permiso VPN antes do identificador de descarte

Coloque unha regra de permiso na posición incorrecta e compórtase como se non houbese ningunha. En nftables, a elección entre insert e add decide en que lado dunha regra referenciada cae a nova instrución, e un identificador nomea a regra no conxunto de regras activo, non o seu número de fila. Se a colocación é incorrecta, o paquete chega primeiro ao descarte.

A comparación de abaixo usa un par fixo e un intercambio de oínte exterior. É deliberadamente estreita; substituír unha cadea enteira é outro cambio con outro perfil de risco.

Dúas colocacións, dous resultados distintos

insert coloca unha regra antes da regra referenciada. add colócaa despois. Se a regra referenciada é o descarte terminal do fluxo, eses dous comandos producen resultados opostos aínda que o texto da regra sexa idéntico.

Omitir unha localización ten o seu propio comportamento predeterminado, outra razón para non copiar un comando dun foro sen ler a que está ancorado. A áncora é toda a decisión. Anote o lado previsto antes de escribir o comando. insert e add diferéncianse nunha palabra no ficheiro.

A colocación é relativa a unha regra nunha cadea concreta. Mover a mesma instrución a outra cadea ou outra prioridade de hook cambia que paquetes ve, mesmo cando a sintaxe da regra parece correcta.

Un identificador identifica unha regra, non un número de liña

Un identificador como 42 é un identificador no estado actual do conxunto de regras. Non é a regra corenta e dous e non é estable entre hosts, reconstrucións ou un xestor que recarga a súa configuración.

Localice a cadea e o descarte terminal real antes de escoller a áncora. Despois confirme o identificador nesa regra na mesma listaxe que mostra o descarte, para que o número e a regra se lean xuntos. Un identificador lido dunha listaxe antiga pode pertencer xa a outra regra. Vólvao ler na sesión que aplicará o cambio.

iptables --version
nft -a list ruleset

A versión de iptables informa que backend se usa. Un conxunto de regras iptables-nft e unha táboa nativa xestionada de forma independente poden coexistir, así que unha listaxe dun só frontend non é automaticamente a imaxe completa do filtrado. Revise ambas as vistas antes de escoller unha cadea.

Atope a cadea e a regra que realmente descarta

Lea o hook de entrada, a prioridade da cadea e a regra que rexeita este fluxo de oínte. Unha táboa inet pode portar ambas as familias de enderezos, pero unha regra individual aínda pode coincidir só con IPv4.

Tome un par aprobado, usando 198.51.100.25 do rango de documentación como exemplo. Un ficheiro nativo revisado podería colocar un permiso exterior antes do identificador 42:

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

Substitúa a familia, a táboa, a cadea, o identificador, a interface de entrada e o par tras a inspección. O exemplo usa a forma de localización por identificador documentada para nft 1.0.9, e pertence a un ficheiro de entrada; o entrecomillado de chaves é un asunto aparte cando o comando se escribe de forma interactiva.

Manteña claro o propietario da configuración. Un xestor que reconstrúe as súas regras pode sobrescribir unha edición en tempo de execución, e un script de arranque que codifica un identificador obsoleto fallará ou engancharase á regra incorrecta.

A aceptación ten alcance, o descarte é terminal

Un veredicto de aceptación remata a avaliación na súa ruta actual, pero unha cadea base aplicable posterior aínda pode descartar o paquete. Un veredicto de descarte é terminal. Por iso un contador de aceptacións crecente non é proba de que o fluxo tivese éxito.

Inspeccione todas as prioridades de hook relevantes en lugar dunha cadea illada. Un paquete pode pasar un filtro de entrada e aínda así ser rexeitado polo hook doutra táboa a unha prioridade distinta. Enumere cada cadea base que poida ver o fluxo.

Esa regra cobre só o intercambio do oínte exterior. ESP encapsulado en transporte, ESP nativo, pares IPv6 e o tráfico descifrado dentro do túnel necesitan todos políticas propias. Non é unha devasa completa de VPN de sitio.

Revise o ficheiro e despois verifique o resultado activo

Execute unha comprobación de sintaxe e transacción sobre o ficheiro revisado antes de aplicalo. O modo de comprobación informa se nft pode analizar e preparar o cambio; non o aplica nin demostra que outro hook permita o paquete. O ficheiro segue sendo unha proposta ata que o propietario o aplique:

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

Aplíqueo mediante o proceso controlado do propietario e conserve o acceso de recuperación. Se a regra é incorrecta, o descarte que intentaba preceder tamén pode cortar a ruta que usa para corrixilo.

Tras o cambio, observe un novo intento de par permitido e comprobe que as fontes fóra do par aprobado seguen sendo rexeitadas. Mova a regra duradeira ao xestor que posúa o conxunto de regras, porque os identificadores en tempo de execución localizan obxectos actuais en lugar de identificalos entre arranques.