Mantenete stabile la politica di nftables mentre arriva l'interfaccia VPN

I tunnel sono usa e getta; la politica non dovrebbe esserlo. Su un gateway Linux, una regola nftables che abbina l'interfaccia del tunnel per nome può essere caricata una volta e continua ad applicarsi ogni volta che quell'interfaccia appare. L'interfaccia ha comunque un ciclo di vita: viene creata, scompare, e le rotte e le traduzioni attorno ad essa seguono il proprio calendario. È la separazione di questi proprietari che mantiene l'accesso stabile durante una riconnessione.

Una corrispondenza per nome sopravvive all'interfaccia

nftables offre corrispondenze numeriche per indice di interfaccia e le corrispondenze dinamiche per nome iifname e oifname. Le regole che usano questi nomi si caricano in modo pulito anche quando il dispositivo del tunnel non è ancora stato creato, che è esattamente ciò di cui ha bisogno un insieme di regole all'avvio. La corrispondenza smette se l'interfaccia viene rinominata e riprende quando una nuova interfaccia prende quel nome. Un indice numerico non ha questa proprietà, per questo la forma con nome è la scelta abituale per un tunnel.

Il nome è una chiave di corrispondenza, non una prova di chi c'è dall'altra parte. L'autenticazione del peer resta compito della VPN.

Leggete la catena prima di aggiungere regole

Guardate cosa contiene ora l'insieme di regole e dove si collocherebbe una nuova regola, perché l'ordine decide l'esito.

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

L'elenco mostra catene, regole e handle, e la modalità di controllo convalida un file candidato senza caricarlo. Un permesso riservato al tunnel, inserito dopo un'accettazione precedente per lo stesso flusso, non cambia nulla, perché vince la prima regola corrispondente. Per questo una regola tardiva può sembrare corretta e non avere alcun effetto. Leggete la catena in ordine e confermate che il divieto per il traffico dal client al collegamento ascendente precede ancora qualsiasi cosa più ampia.

Rotte, traduzione e flussi hanno altri proprietari

La presenza dell'interfaccia non crea rotte e non autentica il peer. Quelle spettano al gestore VPN, mentre la traduzione ha un terzo ciclo di vita.

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

L'elenco di conntrack mostra i flussi esistenti con i loro valori originali e tradotti, e l'elenco delle rotte mostra ciò che il gestore ha installato per l'interfaccia. Le regole NAT stabiliscono lo stato di tracciamento della connessione al primo pacchetto, quindi un flusso stabilito conserva la sua traduzione anche dopo che la regola cambia. Per questo una regola aggiornata e un flusso che usa il nuovo percorso sono due affermazioni diverse. Decidete quali sessioni devono riconnettersi e lasciate in pace i flussi non correlati.

Accettate avvio a freddo, perdita e ripristino

Provate il gateway con il tunnel assente all'avvio, poi presente, poi dopo un'interruzione e un ritorno. Confermate che l'inoltro vietato resta negato mentre manca il tunnel, che un nuovo flusso consentito funziona una volta autenticato il peer e che il ripristino non richiede di svuotare stato non correlato. Non cancellate l'intera catena POSTROUTING né ogni voce conntrack come azione di arresto di un profilo, perché altri servizi le condividono. Annotate quale componente ha cambiato l'interfaccia, la rotta e la politica, invece di solo che un hook di avvio è uscito con zero.

Una politica che sopravvive a una riconnessione è quella i cui proprietari sono nominati e le cui regole sono state provate con il tunnel sia abbassato sia alzato. Un hook che segnala successo dimostra solo che l'hook è stato eseguito.