Chi possiede l’indirizzo, la rotta, il DNS e il firewall su una VPN Linux?

Due script che si contendono la stessa rotta è la forma abituale di un problema VPN Linux che viene archiviato come bug di routing. Un componente crea il dispositivo tunnel, un altro aggiunge una rotta predefinita, un terzo riscrive la configurazione del resolver e un quarto ricarica le regole del firewall. Ognuno di essi può annullare il lavoro di un altro, e il vincitore è semplicemente chi è stato eseguito per ultimo. La domanda a cui vale la pena rispondere non è quale pacchetto installare, ma quale componente ha autorità su ogni pezzo di stato.

Scrivete quella mappa una volta, e la maggior parte dei guasti di riconnessione smette di essere misteriosa. Quattro oggetti contano: il dispositivo e i suoi indirizzi, le rotte e le regole di policy, la configurazione DNS e il firewall.

Il dispositivo e i suoi indirizzi

Un dispositivo tunnel viene creato o da un gestore che conosce il profilo, o da un demone che qualcuno ha avviato a mano. Entrambe le disposizioni funzionano da sole; mescolarle no. Se NetworkManager possiede il profilo, lasciate che possieda anche il dispositivo, e non avviate un OpenVPN non gestito contro lo stesso nome di tunnel.

Annotate chi rimuove il dispositivo quando la sessione termina. Un dispositivo che sopravvive alla sua sessione è la fonte più comune di indirizzi obsoleti e della confusione che ne segue.

Rotte e regole di policy

È sulle rotte che i conflitti di proprietà fanno danni visibili. Un gestore di connessioni installa una rotta predefinita per il tunnel più una rotta più specifica per la rete remota; poi uno script scritto a mano aggiunge la propria rotta predefinita con una metrica diversa e vince o perde in silenzio a seconda dei tempi. Decidete quali voci sono legate alla connessione, quali sono policy permanente e quale componente le aggiorna dopo una riconnessione. Poi tenete gli altri componenti fuori da quella tabella.

Le regole di policy meritano la stessa chiarezza, perché una regola che punta a una tabella che nessuno riempie produce un buco nero che sembra esattamente un tunnel morto. Se esiste una regola per forzare il traffico da qualche parte, la tabella che seleziona deve essere mantenuta dallo stesso proprietario.

Il DNS è sempre un proprietario separato

Un demone resolver gira come processo proprio sotto la propria identità, quindi non eredita per caso le decisioni di routing del tunnel. Quando la VPN spinge server DNS, qualcosa deve tradurlo in una configurazione per collegamento che il resolver rispetti, e qualcosa deve rimuoverla dopo.

Il mito qui è che scrivere un name server nel profilo cambi dove vanno le query. Cambia ciò che viene detto al resolver, non quale socket il resolver usa a monte. Testate con una query più una ricerca di rotta invece di fidarvi del file.

Lo stato del firewall, e chi lo ripristina

Le regole del firewall sono l’oggetto più spesso sovrascritto su un host VPN. Un gestore può aggiungere regole NAT o di inoltro per connessione, mentre un servizio firewall all’avvio ricarica un insieme di regole salvato e le cancella. Scegliete una sola autorità per la policy e fate dell’altra un consumatore, oppure accettate che un riavvio cambi il comportamento in silenzio. Le eccezioni legate alla connessione appartengono a un file che carica lo stesso proprietario, non a un comando iptables digitato durante la risoluzione dei problemi.

Se le regole devono sopravvivere a una riconnessione, ditelo esplicitamente. Se non devono, ditelo comunque, perché il prossimo ingegnere assumerà la risposta più comoda.

Ciclo di vita: avvio, riconnessione, smontaggio

Date un proprietario a ciascuno di quei tre momenti. All’avvio, decidete cosa prepara i prerequisiti e in quale ordine. In un riavvio morbido, ricordate che il dispositivo può sopravvivere mentre lo stato della sessione no, quindi deve girare un validatore invece di un creatore. Allo smontaggio, rimuovete solo ciò che questa connessione ha creato, perché reimpostare ogni rotta o svuotare l’intero firewall non è la stessa cosa che mettere fuori servizio un solo tunnel.

Per l’osservazione, ip monitor link address route mostra le modifiche del kernel mentre accadono, ma riporta eventi anziché intenzioni: una rotta eliminata non dice nulla su quale processo l’abbia eliminata. Abbinalo alla mappa di proprietà, e un arresto confuso diventa una breve lista di candidati.

Anche le esclusioni hanno un costo. Marcare un’intera classe di dispositivi come non gestita per sfuggire a un conflitto affida quello stato a nessuno, il che è una decisione e non una correzione.