L'accelerazione NAT hardware rompe le tue regole di routing VPN?

Attivare l'accelerazione NAT hardware può rendere più rapida una configurazione VPN, e può anche far sì che una policy di routing smetta di applicarsi ad alcuni pacchetti senza alcun errore. Quale delle due cose accade dipende da cosa salta il percorso veloce, e questo varia tra firmware, versione del kernel e tipo di accelerazione in uso. Il menu delle impostazioni raramente ti dice quale hai appena abilitato.

Due affermazioni meritano di essere separate prima di dare la colpa all'acceleratore: che una regola ha smesso di essere applicata, e che un contatore ha smesso di essere aggiornato. Non sono la stessa osservazione.

Tre accelerazioni diverse vengono confuse

L'offload dell'inoltro, l'accelerazione crittografica e l'offload del canale dati del tunnel sono meccanismi separati che spesso condividono un solo commutatore. L'offload dell'inoltro consente ai flussi consolidati di saltare parte dello stack normale, l'accelerazione crittografica rende meno costoso il lavoro di cifratura, e l'offload del tunnel sposta l'incapsulamento nell'hardware. Un router che accelera il traffico instradato ordinario può lasciare il traffico del tunnel interamente sul percorso lento, il che è un esito di prestazioni e non un cambio di policy. Esiste anche il caso inverso, in cui il traffico del tunnel viene offloadato mentre la policy circostante viene ancora valutata.

Le flowtable di Linux sono il caso documentato che vale più la pena leggere, dato che i flussi consolidati possono essere affidati a un percorso veloce. La loro contabilizzazione e gestione dello stato differiscono allora dall'inoltro classico, ed è per questo che i contatori iniziano a sembrare strani.

Un contatore che smette di muoversi dimostra poco

I contatori delle regole contano i pacchetti che attraversano la regola, e un flusso offloadato potrebbe non attraversarla mai più dopo il primo pacchetto. Questo produce un contatore che si blocca mentre il traffico continua, e sembra esattamente un bypass se ti fidi del numero. Osservare il contatore resta utile come indizio che il flusso ha lasciato il percorso contato. Il resto della diagnosi deve venire da dove vanno davvero i pacchetti.

L'inferenza opposta fallisce altrettanto male. Un download veloce non dimostra che le tue regole di eccezione e la gestione dei guasti si applichino ancora, perché esercita un flusso e non la policy.

Tre condizioni decidono se l'offload rompe la policy

La prima condizione è se il percorso veloce consulta l'hook da cui dipende la tua policy, poiché una policy espressa come marcature e rotte sopravvive più spesso di una costruita sul filtraggio per pacchetto. La seconda è se il firmware permetta del tutto quella combinazione, perché alcune build disattivano automaticamente l'offload quando è attivo un tunnel o una funzione del firewall. La terza è se il traffico è idoneo, poiché l'accelerazione è di solito legata ai flussi consolidati e può escludere pacchetti frammentati o insoliti. Dove tutte e tre favoriscono l'accelerazione la policy si applica ancora, e dove fallisce la prima nessuna messa a punto la ripristina.

Leggi la documentazione del fornitore per la combinazione che esegui, non per il modello di router in generale. Le versioni del firmware cambiano queste risposte in silenzio.

Metti alla prova la policy, non il throughput

Misura cosa la policy dovrebbe garantire prima di misurare quanto è veloce. I comandi seguenti mostrano se è installata una flowtable, cosa vede il tracciamento delle connessioni e da quale indirizzo esce il client. Confronta una nuova connessione dopo la modifica, poiché una consolidata può conservare il vecchio percorso.

nft list flowtables
conntrack -L | head -n 20
curl -sS --max-time 8 https://api.ipify.org; echo
ping -c 3 192.168.50.20

Una voce di flowtable che copre il traffico del tunnel ti dice che il percorso veloce è in gioco, e la tabella delle connessioni mostra se il flusso è tracciato come ti aspetti. Il controllo dell'indirizzo conferma l'uscita quando la policy riguarda l'egress internet, mentre il ping conferma una destinazione privata che deve restare raggiungibile. Esegui lo stesso insieme con l'accelerazione disattivata e poi attiva, e confronta i risultati anziché i tempi.

Annota l'impostazione precedente perché l'esperimento resti reversibile. Un'istruzione generica a disattivare l'offload ovunque conta come soluzione tampone, non come constatazione.