Manteniu estable la política de nftables mentre arriba la interfície VPN

Els túnels són descartables; la política no hauria de ser-ho. En una passarel·la Linux, una regla de nftables que coincideix amb la interfície del túnel pel nom es pot carregar un cop i continuar aplicant-se cada vegada que aquesta interfície apareix. La interfície encara té un cicle de vida: es crea, desapareix, i les rutes i les traduccions del seu entorn segueixen el seu propi calendari. Separar aquests propietaris és el que manté l'accés estable durant una reconnexió.

Una coincidència pel nom sobreviu a la interfície

nftables ofereix coincidències numèriques per índex d'interfície i les coincidències dinàmiques pel nom iifname i oifname. Les regles que utilitzen aquests noms es carreguen netes fins i tot quan el dispositiu del túnel encara no s'ha creat, que és exactament el que necessita un conjunt de regles en arrencar. Deixa de coincidir si es canvia el nom de la interfície i es reprèn quan una interfície nova pren aquest nom. Un índex numèric no té aquesta propietat, i per això la forma amb nom és l'opció habitual per a un túnel.

El nom és una clau de coincidència, no una prova de qui hi ha a l'altre extrem. L'autenticació del par continua sent feina de la VPN.

Llegiu la cadena abans d'afegir regles

Mireu què conté ara el conjunt de regles i on quedaria una regla nova, perquè l'ordre decideix el resultat.

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

El llistat mostra cadenes, regles i identificadors, i el mode de comprovació valida un fitxer candidat sense carregar-lo. Una autorització només per al túnel col·locada després d'una acceptació anterior per al mateix flux no canvia res, perquè guanya la primera regla que coincideix. Per això una regla tardana pot semblar correcta i no tenir cap efecte. Llegiu la cadena en ordre i confirmeu que la denegació del trànsit del client cap a l'enllaç ascendent encara precedeix qualsevol cosa més àmplia.

Les rutes, la traducció i els fluxos tenen altres propietaris

La presència de la interfície no crea rutes i no autentica el par. Això pertoca al gestor de la VPN, mentre que la traducció té un tercer cicle de vida.

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

El llistat de conntrack mostra els fluxos existents amb els seus valors originals i traduïts, i el llistat de rutes mostra què ha instal·lat el gestor per a la interfície. Les regles NAT estableixen l'estat de seguiment de la connexió al primer paquet, així que un flux establert conserva la seva traducció fins i tot després que la regla canviï. Per això una regla que s'actualitza i un flux que utilitza el camí nou són afirmacions diferents. Decidiu quines sessions han de reconnectar-se i deixeu en pau els fluxos no relacionats.

Accepteu l'arrencada en fred, la pèrdua i la recuperació

Proveu la passarel·la amb el túnel absent en arrencar, després amb ell present i després d'una caiguda i un retorn. Confirmeu que el reenviament prohibit continua denegat mentre falta el túnel, que un flux permès nou funciona un cop autenticat el par i que la recuperació no requereix netejar estat no relacionat. No esborreu tota la cadena POSTROUTING ni cada entrada de conntrack com a acció d'aturada d'un perfil, perquè altres serveis les comparteixen. Anoteu quin component ha canviat la interfície, la ruta i la política, en lloc de només que un ganxo d'inici ha sortit amb zero.

Una política que sobreviu a una reconnexió és aquella els propietaris de la qual estan nomenats i les regles de la qual s'han provat amb el túnel tant baixat com pujat. Un ganxo que informa d'èxit només demostra que el ganxo s'ha executat.