La tua vecchia rotta predefinita sopravvive di proposito a OpenVPN

Connetti il tunnel, esegui ip route, e il gateway predefinito originale è ancora lì. Il pensiero successivo è che il client non abbia preso in carico la rotta, quindi elimini la predefinita a mano e perdi del tutto la connettività. Quella voce deve restare. Con redirect-gateway def1, OpenVPN installa due rotte più specifiche che superano la rotta predefinita ordinaria invece di sostituirla. Il vecchio gateway resta e smette di portare il traffico che stavi testando.

Cosa fa davvero def1

Il flag aggiunge 0.0.0.0/1 e 128.0.0.0/1, entrambe dirette al tunnel. 0.0.0.0/1 copre ogni indirizzo il cui primo ottetto va da 0 a 127, e 128.0.0.0/1 copre da 128 a 255, quindi ogni destinazione IPv4 ha una corrispondenza più specifica della vecchia rotta predefinita. La lunghezza del prefisso, non la metrica, decide quale rotta vince.

Lasciare la rotta predefinita originale al suo posto è deliberato. Il client non deve ricordare cosa ha sostituito e non riscrive la rotta che porta la propria connessione al server VPN. Alla disconnessione rimuove le due semi-rotte e la tabella torna com’era.

Perché /1 e non /0

L’instradamento sceglie il prefisso corrispondente più lungo, non la metrica più bassa, quindi una /1 batte una /0 qualunque cosa dica la metrica della predefinita. Entrambe le metà esistono perché una /1 copre solo metà dello spazio; con solo 0.0.0.0/1 presente, tutto ciò che parte da 128.0.0.0 segue ancora la vecchia rotta predefinita, il che produce il sintomo confuso per cui alcuni siti funzionano e altri no.

Alzare o abbassare la metrica della vecchia rotta predefinita non cambia nulla, e una rotta predefinita con metrica più bassa su un’altra interfaccia non ruba il traffico. Prima decide la lunghezza del prefisso, e solo i prefissi uguali ricorrono alla metrica.

Leggi una tabella di instradamento reale

Un host connesso può mostrare tutte e tre le voci insieme, con il tunnel che porta le metà e il gateway originale ancora in elenco. Gli indirizzi sono esempi e non una configurazione da copiare, perché i nomi delle interfacce, la topologia del tunnel e le rotte aggiuntive variano per piattaforma e client.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

L’importante è la relazione: due metà specifiche sopra una rotta predefinita generale. La riga del vecchio gateway resta perché nulla l’ha sostituita.

Controlla quale rotta prende davvero il pacchetto

Rotte più specifiche possono ancora vincere: una rotta per un intervallo privato, una sottorete locale o l’indirizzo stesso del server VPN è più lungo di una /1. Il tunnel ha bisogno di un percorso esterno verso il suo server, e rimandare quella connessione nel tunnel lo romperebbe subito. Su Linux chiedi al kernel invece di leggere la tabella a occhio: ip route get con la destinazione che ti interessa stampa la rotta scelta, l’interfaccia e l’origine. Se è configurato l’instradamento basato su policy, esamina anche le regole, perché una regola può selezionare un’altra tabella prima che venga consultata quella principale.

Se solo una parte di IPv4 si comporta male, verifica che entrambe le metà siano installate e poi cerca un’eccezione che corrisponda alla destinazione che fallisce. Eliminare la vecchia rotta predefinita non è una soluzione, e rimuove la rotta di cui il client ha bisogno per smontare il tunnel in modo pulito.

Cosa non copre def1

Due voci IPv4 non dicono nulla su IPv6: un host con connettività IPv6 continua a usare la propria rotta predefinita finché qualcosa non reindirizza quella famiglia separatamente, ed è per questo che su una rete dual-stack parte del traffico sembra aggirare il tunnel. Altri client e gestori di rete implementano l’instradamento a tunnel completo in modo diverso, e le loro tabelle non coincideranno. Il comportamento di def1 descritto qui appartiene al flag documentato di OpenVPN, non a ogni VPN della macchina.

Un kill switch risponde a un’altra domanda: cosa fa la macchina quando il tunnel cade. La precedenza delle rotte decide dove va il traffico mentre il tunnel è attivo; non decide cosa fa dopo un firewall. Ordine di lavoro: leggi la tabella, verifica che entrambe le metà esistano, esegui ip route get per la destinazione che fallisce, controlla le regole di policy e poi guarda IPv6 separatamente. Lascia la vecchia rotta predefinita dove si trova.