Fate in modo che l’inoltro IPv4 resista al riavvio di un gateway VPN

Il ping del gateway funziona e raggiungere qualsiasi cosa dietro di esso no, e questa è la forma di un problema di inoltro e non di un problema di tunnel. La consegna locale al gateway dimostra che il tunnel è salito e che l’assegnazione degli indirizzi ha funzionato; non dice nulla sul fatto che il kernel farà passare un pacchetto da un’interfaccia a un’altra. Prima di toccare qualsiasi sysctl, confermate che la macchina deve instradare questo traffico e individuate il contesto di rete che contiene l’interfaccia rivolta al client. Poi leggete il valore lì, non dove la guida che avete letto per ultima ha guardato per caso.

Raggiungere il gateway non è la stessa cosa che inoltrare

Dentro il kernel avvengono due decisioni separate. La consegna a un indirizzo locale termina il viaggio del pacchetto; l’inoltro lo rimanda fuori attraverso un’altra interfaccia, e quella seconda decisione è governata per spazio dei nomi di rete. Un gateway può essere perfettamente raggiungibile mentre l’inoltro è disattivato, e da un prompt ping i due guasti sembrano identici.

Annotate da quale interfaccia arriva il pacchetto del client e da quale interfaccia esce il percorso successivo. Entrambe appartengono a un solo spazio dei nomi, e quello spazio dei nomi contiene l’impostazione che conta.

Leggete il valore dove i pacchetti si trovano davvero

Su un gateway che instrada nello spazio dei nomi dell’host, un solo comando risponde alla domanda: sysctl net.ipv4.ip_forward. Quando il percorso in ingresso e quello successivo vivono in uno spazio dei nomi con nome, chiedete a quello spazio dei nomi: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Il valore dell’host non sostituisce il valore dello spazio dei nomi, e un uno sull’host non è prova di nulla.

Non ogni contesto di instradamento ha un’etichetta che potete passare a ip netns. Gli ambienti di esecuzione dei container e i servizi creano spazi dei nomi che non vengono mai registrati con un nome amichevole, e per quelli usate gli strumenti di ispezione dell’ambiente. Sostituite vpn-gw con il nome reale, o con il meccanismo dell’ambiente che raggiunge lo stesso contesto, e smettete di tirare a indovinare a livello di host.

Date all’impostazione un solo proprietario

Su un gateway host systemd convenzionale, la forma duratura è un file drop-in con un nome scelto dall’amministratore, come /etc/sysctl.d/60-vpn-forwarding.conf, che contenga net.ipv4.ip_forward = 1. Scrivete il file, poi caricate proprio quel file in modo che cambi anche lo stato attivo: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, seguito da una rilettura. Il nome del file è un esempio e non un percorso VPN riservato, e il numero iniziale conta perché i file ordinati più tardi vincono.

La precedenza è il punto in cui la persistenza si rompe in silenzio. Controllate sia il caricatore della distribuzione sia il vostro drop-in, perché procps sysctl --system legge anche /etc/sysctl.conf alla fine, mentre l’ordine sysctl.d di systemd è una sequenza del tutto diversa. Un’assegnazione successiva può rimettere la stessa chiave, lasciando il vostro file corretto e il valore effettivo sbagliato. Non sovrascrivete un file di amministratore esistente per vincere quella discussione; trovate il proprietario e cambiate lì.

Uno spazio dei nomi creato dopo l’avvio non è affatto governato da un drop-in dell’host. La sua impostazione appartiene a ciò che lo crea, che sia l’ambiente di esecuzione dei container o l’unità di provisioning dello spazio dei nomi. Concedere a un container ampi privilegi di host per eludere la domanda è uno scambio peggiore che dedicare dieci minuti a identificare il proprietario giusto.

Sappiate quanto costa l’interruttore prima di azionarlo

ip_forward non è un booleano innocuo. La documentazione del kernel osserva che cambiarlo ripristina diversi altri parametri IPv4 ai loro valori predefiniti di host o router, quindi un cambio diagnostico può buttare via regolazioni fatte altrove senza mai menzionarlo. Trattatelo come una modifica di configurazione con effetti collaterali e non come una sonda che si possa eseguire con leggerezza.

Ciò esclude anche di spegnerlo e riaccenderlo ogni volta che un client non raggiunge un host. Se il valore è già uno, il guasto è altrove sul percorso, e riscrivere la stessa chiave una terza volta non lo sposterà.

Dimostrate la persistenza, poi provate il resto del percorso

Rileggete il valore in quattro momenti: subito dopo la modifica, dopo la comparsa dell’interfaccia VPN, dopo una riconnessione e dopo un riavvio pianificato. Un valore che torna indietro in uno di questi punti ha un secondo proprietario, e un’altra scrittura occasionale lo nasconde solo fino al prossimo riavvio.

L’inoltro attivo lascia comunque tre cose da verificare. Il client ha bisogno di una rotta verso la destinazione, il gateway ha bisogno di una rotta successiva più il permesso di usarla, e la destinazione ha bisogno di un percorso di ritorno verso l’indirizzo del tunnel del client. Una LAN privata instradata non ha bisogno di NAT automaticamente, quindi non aggiungete masquerading prima di sapere quale delle tre manca, e provate dal client previsto invece che dal gateway stesso, perché una richiesta nata sul gateway non tocca mai il percorso di inoltro che avete appena attivato. IPv6 porta la propria politica di inoltro e instradamento, quindi un test IPv4 funzionante non dice nulla al riguardo.

Tenete insieme nel runbook il percorso del drop-in, il proprietario dello spazio dei nomi e il comando di rilettura. Chi riprenderà questo lavoro dovrebbe poter leggere il valore, vedere chi lo possiede e decidere in un minuto se il problema è la persistenza o il resto del percorso.