Controlla il routing per policy di Linux prima di modificare la rotta predefinita

Un host VPN risponde su un’interfaccia e rifiuta di rimandare le risposte attraverso il tunnel, e la rotta predefinita sembra corretta. È qui che la tabella principale smette di essere tutta la storia. Linux può selezionare una tabella di routing per pacchetto tramite regole di policy, e la VPN potrebbe averne installata una. Leggi le regole prima di toccare la rotta predefinita.

L’ordine conta: prima le regole, poi la tabella che ciascuna regola seleziona.

Leggi le regole in ordine di priorità

Esegui ip rule show e leggi dall’alto verso il basso. Il numero di priorità controlla l’ordine di valutazione, e un numero più basso viene controllato prima. La regola predefinita a 32766 è di solito l’ultima che conta. Se l’elenco è lungo, salvalo in un file prima di cambiare qualcosa.

Per ogni regola, annota la priorità, la corrispondenza (origine, marcatura, interfaccia o destinazione) e la tabella a cui fa riferimento. Una regola senza una tabella utilizzabile è un vicolo cieco, non una rotta.

Fai lo stesso per IPv6 con ip -6 rule show. Una policy che esiste solo nella famiglia IPv4 lascia l’altra famiglia sulla tabella principale.

Leggi la tabella che ciascuna regola seleziona

Usa ip route show table <name or number> per ogni tabella referenziata. Confronta le sue rotte con l’interfaccia e il prossimo salto che ti aspetti. Una tabella vuota o incompleta spiega un guasto che la tabella principale non può spiegare.

La tabella principale può ancora contenere la rotta predefinita, e va bene. Se una regola manda il tuo flusso prima alla tabella 51820, la rotta predefinita principale è irrilevante per quel pacchetto.

Cerca il nome della tabella in /etc/iproute2/rt_tables se il numero non ti è familiare. Quella ricerca richiede un secondo ed evita un lungo giro.

Scopri chi ha installato la regola

NetworkManager, wg-quick e altri script possono installare regole dinamicamente. Eliminare una regola a runtime può essere annullato alla prossima riconnessione. Controlla la configurazione del gestore prima di aggiungere una regola concorrente.

wg-quick, per esempio, aggiunge una regola marcata e una tabella per gli indirizzi consentiti del tunnel. È quella regola a far bypassare la rotta predefinita principale al traffico verso quegli indirizzi. Se la rimuovi senza cambiare la configurazione, il prossimo avvio la ripristinerà.

Preserva la rotta esterna dell’endpoint e l’accesso di gestione durante la revisione. Non svuotare tutte le regole su un gateway remoto attivo per semplificare l’output. Una sessione di gestione che sopravvive alla modifica fa parte del test.

Prova il contesto di origine che conta

Un ip route get generico risponde a una domanda diversa dal flusso dell’applicazione. Aggiungi l’indirizzo di origine, e la marcatura se la VPN ne usa una, per vedere il percorso che fa il pacchetto reale. Prova una destinazione inclusa e una esclusa con lo stesso contesto di origine. Poi ripeti per IPv6 se l’host usa il doppio stack.

Dopo una correzione approvata, riesegui le stesse due ricerche e confrontale. Tieni un registro della regola prevista, della tabella e di quanto la regola sopravvive a un riavvio. È quel registro a rendere spiegabile il prossimo riavvio del servizio invece che misterioso. La pagina di manuale di ip-rule documenta i selettori di corrispondenza e la sintassi delle tabelle.