Perché net.ipv4.conf.default.forwarding lascia tun0 in pace

Hai impostato net.ipv4.conf.default.forwarding=1, hai riavviato la VPN e il tunnel continua a scartare pacchetti che il gateway dovrebbe instradare. L'impostazione sembra corretta nel file e l'interfaccia continua a segnalare che l'inoltro è disattivato. Niente è rotto: hai cambiato il valore che le interfacce future ereditano, non quello che usa il tunnel attivo.

Ripercorri tutto sull'host che possiede il tunnel, nel namespace di rete in cui il tunnel esiste davvero. Un container o un namespace di rete può tenere l'interfaccia mentre l'host mostra numeri diversi.

Leggi i tre valori insieme

Inizia confrontando l'interruttore dell'intero gateway, il modello per le nuove interfacce e l'interfaccia che ti interessa. Sostituisci tun0 con l'interfaccia di ingresso reale e leggi anche l'interfaccia di ritorno, perché l'inoltro viene valutato nel punto in cui arriva il pacchetto.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Un risultato comune è ip_forward = 0, default.forwarding = 1 e tun0.forwarding = 0. I primi due non concordano sul ruolo dell'host, e il terzo mostra cosa fa realmente l'interfaccia. Questa combinazione è coerente con un host mai configurato come router, a cui è stato dato solo un valore di modello. I tre numeri non si contraddicono; rispondono a tre domande diverse. Anche scrivere il valore del modello non decide il ruolo dell'host.

Perché è l'interruttore globale quello che si muove

net.ipv4.ip_forward è il controllo dell'intero gateway. Modificarlo aggiorna le impostazioni di inoltro per interfaccia come parte della stessa operazione, per questo una sola scrittura può far iniziare l'inoltro di un tunnel esistente. default.forwarding semina solo le interfacce inizializzate dopo, quindi un tunnel già esistente mantiene il valore con cui è nato.

La documentazione del kernel segnala ip_forward come speciale per un motivo collegato: modificarlo ripristina una serie di altri parametri IPv4 ai valori predefiniti di host o router. Questo lo rende uno strumento grossolano. Impostarlo una volta come parte della definizione del ruolo di gateway va bene; commutarlo ripetutamente come trucco di debug può riscrivere in silenzio una configurazione su cui hai speso tempo.

Anche i valori per interfaccia esistono per un motivo. Un gateway gestito di proposito può tenere l'inoltro spento su un'interfaccia che non dovrebbe mai instradare, anche mentre l'host inoltra altrove. Per questo è importante leggere l'interfaccia attiva e per questo il valore globale da solo non è tutta la risposta. Leggi un'eccezione del genere come una decisione deliberata e annota perché quell'interfaccia è diversa. Altrimenti il prossimo ingegnere la "aggiusterà" con premura.

Rendi l'impostazione permanente nel posto giusto

Un sysctl -w isolato e riuscito dimostra che il kernel accetta il valore. Non sopravvive a un riavvio, e non sopravvive a un gestore di rete che alla riconnessione riapplica la propria idea della configurazione dell'interfaccia. Metti il ruolo di gateway nel file di configurazione sysctl o nel gestore di rete che possiede l'host, poi riavvia il servizio che lo applica.

L'ordine conta con i tunnel. Se il gestore crea l'interfaccia all'avvio e applica l'inoltro dopo, l'interfaccia può ereditare il vecchio valore predefinito. Anche un riavvio del servizio che ricrea il tunnel è un evento di creazione, ed è facile trascurarlo quando l'unità sembra sana. Controlla la sequenza, non solo il contenuto finale del file.

Rileggi gli stessi tre valori dopo che la VPN si riconnette e di nuovo dopo un riavvio. Un tunnel appena creato è una nuova interfaccia, e una nuova interfaccia prende il valore predefinito in vigore al momento della creazione. Se i numeri cambiano tra questi eventi, la configurazione è applicata da qualcosa che non hai ancora identificato.

Non ripararlo con lo strumento sbagliato

Quando l'inoltro sembrava rotto, la tentazione è svuotare il firewall o aggiungere masquerading. Nessuno dei due affronta l'interruttore di inoltro. Lo stato di inoltro, il permesso di inoltrare, una rotta per la destinazione e un percorso di ritorno sono quattro requisiti separati, e solo il primo è il sysctl.

Prova anche con il flusso giusto. Una richiesta fatta sul gateway stesso non esercita affatto l'inoltro; è traffico generato localmente. La domanda è se un pacchetto che arriva da un client VPN o da un host della LAN venga accettato e instradato oltre, quindi il test deve partire da dietro il gateway.

Tieni separato il caso IPv6

Qui è tutto IPv4. L'inoltro IPv6, gli annunci dei router e il comportamento di accept_ra hanno i propri controlli, e copiare un percorso ipv4 in un'impostazione ipv6 produce un file che sembra plausibile e non fa nulla di utile. Un gateway dual-stack ha bisogno che entrambi gli insiemi siano configurati di proposito.

Un ultimo controllo: dopo che i valori coincidono, conferma che la rotta del tunnel sia scelta per la destinazione e che il percorso di risposta esista. L'inoltro attivo su un'interfaccia senza rotta resta un buco nero, e quel guasto appare identico dal lato del client.