Perché una rotta VPN eliminata torna dopo la riconnessione

Una rotta che hai eliminato a mano torna dopo la prossima riconnessione, e la tabella è esattamente come prima. Non è un bug di routing: qualcosa ricrea la voce dalla configurazione o da un’azione del ciclo di vita della connessione. La maggior parte dei runbook si ferma alla tabella attiva, ed è per questo che l’eliminazione sembra funzionare per un minuto e poi fallisce. Identifica il proprietario, modificalo e dimostralo a una riconnessione.

Chi ha installato la rotta

Inizia con un elenco di candidati invece che con una correzione. Un profilo VPN può portare le proprie rotte, un server può spingerle al momento della connessione, un profilo del gestore di rete può dichiararle, un’unità di avvio o uno script può aggiungerle, e le implementazioni IPsec installano rotte per i selettori di traffico che negoziano. Anche le regole di routing basate su policy possono reindirizzare il traffico del tutto verso un’altra tabella.

Il momento in cui compaiono le separa più in fretta dell’archeologia della configurazione. Una voce che appare nell’istante in cui l’interfaccia sale appartiene al client; una che arriva un secondo dopo di solito viene da un push del server; una presente all’avvio appartiene alla configurazione salvata. Registra la tabella prima e dopo una connessione, una disconnessione e un riavvio, e lo schema nominerà il proprietario. Una rotta che torna solo quando il servizio si riavvia punta a un’unità, non alla VPN.

Leggi la tabella prima di modificarla

Guarda la vista del kernel stesso invece di un file salvato. La colonna del protocollo mostra cosa ha installato ogni voce:

ip route show
ip route show table all
ip rule show

Il campo protocollo, la metrica e il numero di tabella ti dicono se stai guardando una voce statica, una creata dal kernel o qualcosa aggiunto da un demone. L’elenco delle regole conta perché una ricerca può lasciare del tutto la tabella principale, il che rende invisibile una modifica lì all’applicazione che stai diagnosticando. Leggi la riga da sinistra a destra: destinazione, gateway, dispositivo, protocollo e metrica.

Poi chiedi al kernel quale rotta userebbe davvero. Un indirizzo protetto è una sonda migliore di uno pubblico:

ip route get 10.20.5.7

Cambia il proprietario, non il sintomo

Una volta noto il proprietario, la modifica appartiene a quel proprietario. Rimuovi la rotta dal profilo del client, correggi la rotta inviata sul server o modifica la connessione del gestore di rete invece di aggiungere una rotta persistente concorrente che vince per metrica. Due regole che si combattono producono una tabella che nessuno saprà spiegare in seguito.

Mantieni l’esclusione dell’endpoint. Una rotta host che invia l’indirizzo pubblico del server VPN stesso attraverso il gateway fisico è ciò che tiene in flusso i pacchetti esterni del tunnel; eliminala e il tunnel cerca di portare se stesso. Su un profilo split tunnel, la stessa cura vale per le sottoreti locali che devono aggirare il tunnel.

Riconnettiti e verifica entrambi i percorsi

Riconnettiti, poi controlla entrambe le destinazioni in un solo passaggio. L’indirizzo protetto e l’endpoint escluso rispondono a domande diverse:

ip route get 10.20.5.7
ip route get 198.51.100.20

La prima dovrebbe risolversi tramite l’interfaccia del tunnel e la seconda tramite il gateway fisico. Se entrambe si risolvono tramite il tunnel, manca l’esclusione; se nessuna lo fa, la modifica del profilo non ha avuto effetto e stai guardando un proprietario diverso da quello che pensavi.

Annota lo scopo della rotta, il suo proprietario e quanto a lungo dovrebbe vivere. Quella nota è ciò che impedisce alla persona successiva di ripetere lo stesso ciclo di eliminazione e riconnessione.