OpenVPN redirect-gateway: cosa fa ogni flag alle rotte

Connettiti con redirect-gateway nel profilo e la rotta predefinita della macchina può sparire, dividersi in due o restare esattamente dov’era, a seconda di flag che nessuno legge due volte. L’opzione modifica solo lo stato di routing e nient’altro, quindi l’unica prova affidabile di ciò che ha fatto è la tabella che il client ha installato dopo. Quello che segue è la tabella dopo una connessione, la rotta che tiene vivo il tunnel stesso e il traffico IPv6 che la direttiva non afferma mai di coprire. Ogni passo è un comando che puoi eseguire sul client mentre il tunnel è attivo.

Cosa fa ogni flag alla rotta predefinita

Senza alcun flag, l’opzione rimuove la rotta predefinita ordinaria e mette il tunnel al suo posto, così il vecchio gateway sparisce dalla tabella finché la connessione è attiva. Aggiungi def1 e quella rotta predefinita resta elencata, con due rotte più strette che fanno il lavoro. Aggiungi bypass-dhcp e anche la rotta DHCP sopravvive, cosa che conta su una rete dove il client deve ancora raggiungere il server DHCP locale. L’elenco dei flag nella pagina del manuale di OpenVPN 2.6 è abbastanza breve da leggerlo una volta, e ogni voce cambia quali rotte finiscono nella tabella.

Un’opzione spinta si comporta allo stesso modo quando arriva, quindi il profilo del client può non contenere nulla mentre la tabella sembra completamente reindirizzata. È normale: il server ha inviato i flag, il client li ha applicati e il file locale non ha mai menzionato la direttiva. Quando un push sembra non fare nulla, controlla il filtro lato client che accetta o scarta le opzioni estratte, perché un’opzione scartata non genera errori da nessuna delle due parti.

def1 vince per specificità senza toccare la tua rotta predefinita

Due rotte semi-predefinite coprono insieme lo spazio IPv4, 0.0.0.0/1 e 128.0.0.0/1. Ognuna è più specifica di 0.0.0.0/0, quindi una ricerca le preferisce mentre la vera rotta predefinita resta nella tabella per tutto ciò che chiede la corrispondenza meno specifica.

Leggi la tabella invece del profilo, perché solo la tabella mostra in quale di questi casi ti trovi. Due righe bastano per distinguerli:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Osserva l’interfaccia e la metrica su ogni riga, non solo la destinazione. Una rotta predefinita che punta al tunnel e una coppia di semi-predefinite che puntano al tunnel descrivono la stessa intenzione e falliscono in modo diverso quando il tunnel cade, perché in un caso il ripiego esiste ancora. Annota entrambi i campi nella nota di modifica. Un ripiego sopravvissuto è a volte ciò che tiene viva una sessione remota abbastanza a lungo da riparare il tunnel, ed è anche ciò che perde traffico quando l’intenzione era un tunnel completo.

Mantieni raggiungibile l’estremità del tunnel

Il client ha bisogno di una rotta verso l’estremità lontana del tunnel che non passi essa stessa dal tunnel. OpenVPN installa quella rotta host prima di cambiare qualsiasi altra cosa, e una modifica manuale delle rotte o un secondo client VPN possono toglierla. Il sintomo dopo è una connessione che dichiara di essere connessa e poi non fa passare nulla.

Chiedi al kernel quale interfaccia userebbe per l’indirizzo dell’estremità mentre il tunnel è attivo. La risposta deve nominare l’interfaccia fisica e il suo gateway, mai tun0:

ip route get 198.51.100.20

Se quella ricerca restituisce il dispositivo del tunnel, il tunnel trasporta il proprio traffico e collasserà appena un pacchetto dovrà uscire. I prefissi locali, un secondo adattatore e il routing basato su policy contano ancora qui, per questo un reindirizzamento che funziona su un portatile pulito può fallire su un host con un’interfaccia di gestione e due rotte predefinite. Di solito si dà la colpa al profilo per ciò che ha fatto il piano degli indirizzi.

Il traffico IPv6 continua a usare la sua tabella

Reindirizzare IPv4 lascia IPv6 tranquillo, e le due famiglie vengono cambiate da flag diversi. Su un host dual-stack con una rotta v6 predefinita funzionante, il traffico v4 può restare completamente dentro il tunnel mentre ogni destinazione capace di v6 esce dal collegamento fisico. Un host che sembra corretto in una tabella perde nell’altra.

Controlla la tabella v6 dopo la connessione invece di dare per scontato che il tunnel l’abbia coperta. La direttiva porta flag di famiglia di indirizzi proprio per questo motivo, e un profilo che li omette eredita ciò che la piattaforma fa per impostazione predefinita:

ip -6 route show default
ip -6 route get 2001:db8::10

Dimostra quale interfaccia usa un’applicazione

Uno stato connesso non è un blocco, e un cambio di rotta non è un interruttore di sicurezza. Se il traffico diretto deve fermarsi quando il tunnel fallisce, quella politica vive nel firewall e richiede un proprio test.

Prova il percorso che un’applicazione segue davvero invece del percorso che descrive il profilo. Chiedi prima la rotta, poi lega una richiesta a ogni interfaccia a turno e confronta ciò che riporta il lato remoto:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Se entrambe le richieste restituiscono lo stesso indirizzo, l’applicazione non sta usando il tunnel anche se la tabella di routing dice che dovrebbe. Se riesce solo la richiesta legata al tunnel, il percorso fisico è filtrato per quella destinazione e il tunnel fa ciò che hai chiesto. Scrivi i flag, le rotte installate, la ricerca dell’estremità ed entrambi i risultati di uscita nel registro delle modifiche, così la persona successiva eredita fatti invece di uno screenshot.