Come distinguere le rotte spinte dalla VPN da quelle statiche su Linux

Un prefisso appare sul portatile quando il tunnel sale, quindi sembra che l'abbia installato la VPN. Forse è così, ma lo stesso risultato può venire da uno script client eseguito alla connessione, da un profilo di connessione che elenca la sottorete, o da una rotta statica presente da sempre che ha iniziato a funzionare solo quando l'interfaccia esisteva. Scegliere il proprietario sbagliato significa che la rotta torna dopo ogni pulizia, e la persona successiva ripete la stessa correzione. La sequenza seguente separa i tre prima di cambiare qualsiasi cosa.

Passo 1: nominare il meccanismo che installa i prefissi

Protocolli diversi forniscono raggiungibilità in modi diversi, e chiamare tutto questo annuncio nasconde la distinzione. Un server OpenVPN spinge una direttiva di rotta sul canale di controllo e il client la installa a meno che un filtro pull la blocchi. Una configurazione WireGuard elenca localmente i prefissi consentiti, che il client usa sia per l'instradamento delle chiavi crittografiche sia per le rotte che aggiunge. Un tunnel IPsec concorda selettori di traffico con il peer, e il kernel installa rotte da quei selettori.

Identificate quale di questi usa il vostro tunnel prima di leggere qualsiasi tabella. Una rotta spinta alla connessione non è un annuncio di un protocollo di instradamento e non promette che il prefisso sia raggiungibile dietro l'estremità remota. Annotate il meccanismo accanto al prefisso, perché decide dove va la correzione.

Passo 2: confrontare la tabella lungo una connessione

Salvate la tabella principale con il tunnel abbassato, alzatelo, salvatela di nuovo e confrontate le due catture. Tutto ciò che è apparso appartiene al ciclo di vita della connessione, e tutto ciò che è rimasto appartiene alla configurazione locale.

Catturatela con ip route show table main > /tmp/route-down.txt, connettetevi e catturate di nuovo. Fate lo stesso per ip -6 route se il sito usa IPv6, perché un prefisso mancante lì produce guasti che sembrano non avere relazione con l'instradamento.

Passo 3: leggere la metrica, non solo la presenza

Due voci per lo stesso prefisso possono coesistere, e il kernel sceglie la metrica più bassa. Una rotta statica con metrica 50 continuerà a vincere su una rotta spinta a 100 anche se entrambe sono visibili, per questo «la rotta è lì» e «il traffico la usa» sono affermazioni diverse.

Chiedete direttamente al kernel con ip route get 10.20.5.7 e leggete l'interfaccia che riporta. Se il traffico esce dall'adattatore fisico mentre una rotta del tunnel siede nella tabella, lo spiega la metrica o la lunghezza del prefisso, non il client VPN. Ripetete la ricerca per un host che sapete essere dietro il tunnel e per uno che sapete non esserlo, e la differenza mostra se la suddivisione si comporta come previsto.

Passo 4: trovare le voci che sopravvivono al tunnel

Le rotte statiche sopravvivono a una disconnessione per progetto, ed è da lì che vengono le voci obsolete. Una rotta persistente che punta a un'interfaccia che non esiste più può inghiottire una sottorete in silenzio, e una che punta a un nome di interfaccia riutilizzato può mandare traffico privato dalla porta sbagliata dopo un riavvio.

Controllate il lato persistente nel posto usato dalla vostra distribuzione, che sia un'unità systemd-networkd, un profilo NetworkManager o uno script nella directory up del client. Correggere la tabella viva con ip route del regge solo fino alla prossima connessione. Trattate quella cancellazione come una prova dell'ipotesi e non come la riparazione.

Dove l'estremità remota fornisce la copertura sbagliata, sollevatelo con l'operatore invece di filtrare tutto. Scartare tutte le impostazioni spinte scarta anche DNS e politica del tunnel diviso da cui dipende il profilo.

Passo 5: confermare il percorso di ritorno prima di incolpare il client

Per un sito a sito o una sottorete dietro il tunnel, il lato remoto ha bisogno di una rotta di ritorno verso l'indirizzo del vostro client e dell'inoltro attivo sul gateway. Un percorso a senso unico sembra esattamente un bug di instradamento del client, tranne che la stretta di mano e il pacchetto in uscita riescono entrambi.

Il filtraggio del percorso inverso aggiunge una seconda trappola sui gateway Linux. Una risposta che arriva su un'interfaccia diversa da quella prevista dalla rotta viene scartata in modalità stretta, e i percorsi asimmetrici attraverso due fornitori lo innescano in modo affidabile. I contatori di scarto sul gateway, non sul client, vi dicono se il filtraggio è la causa.

Passo 6: testare la risorsa, non il ping

Una volta che la rotta scelta è corretta, aprite la risorsa reale e confermate il traffico di ritorno. Una risposta al ping prova il percorso in una direzione e nulla sul servizio, e un servizio che risponde su una connessione in cache prova ancora meno.

Poi ripetete l'intera verifica dopo una riconnessione. Il valore della sequenza è che predice cosa farà la prossima connessione, per questo sia il confronto sia la metrica appartengono al ticket.