Manteña estable a política de nftables mentres chega a interface VPN

Os túneles son desbotables; a política non debería selo. Nunha pasarela Linux, unha regra de nftables que coincide coa interface do túnel polo nome pódese cargar unha vez e segue aplicándose cada vez que esa interface aparece. A interface segue tendo un ciclo de vida: créase, desaparece, e as rutas e traducións ao seu redor seguen o seu propio calendario. Separar eses propietarios é o que mantén o acceso estable durante unha reconexión.

Unha coincidencia por nome sobrevive á interface

nftables ofrece coincidencias numéricas por índice de interface e as coincidencias dinámicas por nome iifname e oifname. As regras que usan eses nomes cárganse limpas mesmo cando o dispositivo do túnel aínda non se creou, que é xusto o que necesita un conxunto de regras ao arrincar. Deixa de coincidir se a interface se renomea e retómase cando unha interface nova toma ese nome. Un índice numérico carece desa propiedade, por iso a forma con nome é a opción habitual para un túnel.

O nome é unha clave de coincidencia, non unha proba de quen está ao outro lado. A autenticación do par segue a ser tarefa da VPN.

Lea a cadea antes de engadir regras

Mire que contén agora o conxunto de regras e onde quedaría unha regra nova, porque a orde decide o resultado.

nft list ruleset
nft -c -f /etc/nftables.conf

A listaxe mostra cadeas, regras e handles, e o modo de comprobación valida un ficheiro candidato sen cargalo. Un permiso só para o túnel colocado despois dunha aceptación anterior para o mesmo fluxo non cambia nada, porque gaña a primeira regra que coincide. Por iso unha regra tardía pode parecer correcta e non ter ningún efecto. Lea a cadea en orde e confirme que a denegación do tráfico do cliente cara á ligazón ascendente segue precedendo a calquera cousa máis ampla.

As rutas, a tradución e os fluxos teñen outros propietarios

A presenza da interface non crea rutas e non autentica o par. Iso corresponde ao xestor da VPN, mentres que a tradución ten un terceiro ciclo de vida.

conntrack -L -s 10.20.0.0/24 | head
ip route show dev vpn0

A listaxe de conntrack mostra os fluxos existentes cos seus valores orixinais e traducidos, e a listaxe de rutas mostra o que o xestor instalou para a interface. As regras NAT establecen o estado de seguimento de conexión no primeiro paquete, así que un fluxo establecido conserva a súa tradución mesmo despois de que cambie a regra. Por iso unha regra que se actualiza e un fluxo que usa o camiño novo son afirmacións distintas. Decida que sesións deben reconectarse e deixe en paz os fluxos non relacionados.

Acepte o arrinque en frío, a perda e a recuperación

Probe a pasarela co túnel ausente ao arrincar, logo presente e despois tras unha caída e un retorno. Confirme que o reenvío prohibido segue denegado mentres falta o túnel, que un fluxo permitido novo funciona unha vez autenticado o par e que a recuperación non esixe baleirar estado non relacionado. Non borre toda a cadea POSTROUTING nin cada entrada de conntrack como acción de parada dun perfil, porque outros servizos as comparten. Anote que compoñente cambiou a interface, a ruta e a política, en lugar de só que un gancho de arrinque saíu con cero.

Unha política que sobrevive a unha reconexión é aquela cuxos propietarios están nomeados e cuxas regras se probaron co túnel tanto baixado como levantado. Un gancho que informa de éxito só demostra que o gancho se executou.