Verifica il routing VPN negli spazi dei nomi senza toccare le rotte dell’host

Due laboratori possono modellare la stessa topologia VPN e fallire in modi completamente diversi: uno vive negli spazi dei nomi di rete, l’altro sulle rotte proprie dell’host. La versione con spazi dei nomi tiene ogni interfaccia, rotta e socket in un contesto che puoi eliminare, mentre la versione sull’host si avvia più in fretta e lascia stato dietro di sé. Proprio questo stato residuo è il motivo per cui il secondo laboratorio è difficile da ripetere un mese dopo. Confronta prima la pulizia, perché decide se puoi eseguire l’esperimento due volte.

Due modi per costruire lo stesso laboratorio, e quando ciascuno vince

In un laboratorio di rotte dell’host aggiungi un’interfaccia tunnel e rotte alla macchina su cui lavori, così l’esperimento condivide il destino con la tua shell, il tuo gestore di pacchetti e ogni altra connessione. In un laboratorio di spazi dei nomi ogni ruolo riceve la propria pila di interfacce, indirizzi, rotte e socket, ed eliminare lo spazio dei nomi rimuove tutto. Nessuno dei due modelli è più corretto, perché rispondono a domande diverse. Scegli gli spazi dei nomi quando il tema è il routing e l’inoltro, e un laboratorio sull’host quando il tema è come si integra un client desktop.

Mescolare i due è l’errore abituale: un laboratorio di spazi dei nomi provato contro un client solo sull’host non dimostra nulla su nessuna delle due disposizioni. Decidi quale domanda stai ponendo prima di creare il primo collegamento.

Un contesto per ruolo, connesso di proposito

Crea uno spazio dei nomi per ruolo e sposta ogni estremità di ogni coppia veth nel contesto che la possiede. I primi quattro comandi bastano per vedere la forma:

ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns client

Assegna al laboratorio intervalli che non si sovrappongono a nulla sull’host, e annota prima di iniziare quale spazio dei nomi possiede quale indirizzo. Un laboratorio funzionante ha bisogno di due percorsi separati: uno esterno perché l’endpoint VPN raggiunga il suo pari, e un percorso di ritorno per la risorsa protetta. Modellali come due decisioni, perché un laboratorio che costruisce solo la metà uscente supera un test di stretta di mano e fallisce un test applicativo.

Il ruolo di inoltro è dove i laboratori diventano interessanti

Un ruolo deve inoltrare, il che significa abilitare l’inoltro dentro quello spazio dei nomi e aggiungere la regola che il progetto richiede. Lo stato di inoltro è per spazio dei nomi, quindi l’impostazione dell’host è irrilevante per il laboratorio e l’impostazione del laboratorio non filtra verso l’esterno, come descrive la documentazione sugli spazi dei nomi di rete. WireGuard documenta che un’interfaccia e il suo socket esterno possono vivere in spazi dei nomi diversi, il che è un trucco utile e un modo eccellente per confondersi. Non dare per scontato che spostare un’interfaccia sposti ogni parte della connessione allo stesso modo.

Controlla il contatore di inoltro dopo un pacchetto di prova, perché una regola che non ha mai corrisposto e una regola che ha scartato sembrano identiche nella tabella delle rotte. Solo i contatori le separano.

Registra una linea di base, poi rompi una rotta

Inizia registrando ciò che esiste, con il contesto scritto accanto a ogni riga. Leggi gli spazi dei nomi, poi la rotta che una destinazione di prova prenderebbe dentro uno di essi, poi i contatori sul collegamento che la trasporta:

ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-g

Il terzo comando è quello che la gente salta, ed è lì che vivono le prove: i contatori di scarti ed errori ti dicono se un pacchetto ha mai raggiunto il ruolo di inoltro. Registra le stesse tre viste dopo una modifica, e lascia che il diff sia la prova invece della tua memoria. Poi rompi esattamente una cosa, o eliminando una rotta o aggiungendo una regola di rifiuto sul percorso di inoltro, e conferma il sintomo che avevi previsto: una stretta di mano completata senza risposta, o un fallimento di risoluzione invece di un timeout. Un laboratorio che dimostra solo il successo insegna molto poco.

La pulizia è ciò che rende ripetibile l’esecuzione successiva

Mantieni la pulizia limitata alle risorse che hai nominato, perché un reset generale del firewall o la rimozione di una rotta dell’host non è riproducibilità, è un secondo incidente. Salva la topologia, i comandi esatti e le osservazioni che ti aspettavi, così l’esecuzione successiva riproduce lo stesso guasto invece di indovinare quale contesto deteneva lo stato precedente. Senza quel registro il laboratorio è una storia e non una procedura.

Usa credenziali generate localmente per il laboratorio e tieni gli account di produzione fuori dagli esempi condivisi. Poi elimina ogni spazio dei nomi e conferma che la vista dell’host è invariata, che è tutta la ragione per scegliere questo modello. Un laboratorio che non puoi rimuovere in modo pulito è una modifica all’host con passaggi extra.