Come inviare una destinazione IPv4 fuori da un tunnel OpenVPN

La maggior parte delle configurazioni a tunnel completo invia ogni pacchetto attraverso la VPN, e redirect-gateway è la direttiva che lo rende possibile. Una singola destinazione può comunque essere esentata. Aggiungere una rotta host per quell’indirizzo con il segnaposto net_gateway dice al client di raggiungerla attraverso il gateway originale della macchina, mentre tutto il resto continua a usare il tunnel.

La riga sembra innocua e spesso lo è, ma risolve solo una domanda: dove vanno i pacchetti per quell’indirizzo IPv4 esatto. Non cambia il DNS, IPv6, la politica del firewall né quale processo ha aperto la connessione, e ciascuno di questi elementi può annullare l’eccezione in silenzio.

Che cosa nomina davvero net_gateway

La voce del profilo per quell’eccezione è una riga: route 198.51.100.77 255.255.255.255 net_gateway. Il primo indirizzo è un segnaposto documentale per la destinazione, la maschera lo rende una rotta a host singolo, e l’ultimo token nomina il segnaposto del gateway. OpenVPN risolve i segnaposto dei gateway quando installa le rotte. vpn_gateway significa il gateway del tunnel stesso, il lato remoto del collegamento VPN. net_gateway significa il gateway predefinito che l’host aveva prima che la VPN cambiasse qualcosa, di solito il router locale della rete fisica.

Un terzo segnaposto, remote_host, si riferisce all’indirizzo del server VPN, ed esiste perché il tunnel possa raggiungere il server lungo il percorso fisico. Confondere questi tre è la ragione più comune per cui un’eccezione finisce nel posto sbagliato o non viene installata affatto.

Il valore viene letto al momento della connessione, non scritto nel file. Se la macchina passa a un’altra rete, il gateway precedente alla VPN cambia e la rotta segue quello nuovo. Di solito è ciò che si vuole, ma significa anche che il comportamento dell’eccezione dipende dalla rete da cui il client è partito.

Perché una rotta host vince sulla rotta predefinita del tunnel

L’instradamento è deciso dal prefisso corrispondente più specifico. redirect-gateway def1 di solito non sostituisce la rotta predefinita; aggiunge due metà, una rotta per la metà inferiore dello spazio degli indirizzi e una per quella superiore, così la rotta predefinita originale resta conservata per altri usi. Quelle metà sono più ampie di un singolo indirizzo.

Una rotta per un indirizzo con maschera 255.255.255.255 è una /32, cioè il massimo di specificità che IPv4 consente. Quando si valuta un pacchetto per quell’indirizzo, la /32 corrisponde e vince indipendentemente da quale rotta è stata installata prima. È questo il meccanismo dietro l’eccezione, e funziona allo stesso modo su Linux, macOS e Windows purché la rotta sia davvero presente.

Windows aggiunge una seconda dimensione. Quando due rotte sono ugualmente specifiche, vince quella con la metrica più bassa, e una scheda VPN può portare una metrica di interfaccia che cambia il risultato. Una /32 resta più specifica delle metà, quindi l’eccezione di solito regge, ma una rotta obsoleta di una sessione precedente può dare un risultato confuso se è ugualmente specifica.

Ciò che l’eccezione non copre

Il DNS è la prima lacuna. Il client può spingere impostazioni interne del resolver, e il sistema operativo continuerà a usarle per le risoluzioni. Un’applicazione che risolve un nome prima di connettersi può ricevere un indirizzo interno per un servizio che dovrebbe andare diretto, o un indirizzo esterno che si risolve correttamente ma poi inciampa nella lacuna successiva.

IPv6 è la seconda. La direttiva di rotta gestisce solo IPv4. Una destinazione a doppio stack può preferire IPv6, che segue il tunnel o la rotta predefinita IPv6 dell’host secondo la politica, così l’eccezione IPv4 non entra mai in gioco. Serve una rotta IPv6 corrispondente, oppure una decisione deliberata di disattivare IPv6 per quel client.

L’ambito delle applicazioni è la terza. La regola è basata sulla destinazione, quindi ogni processo che si connette a quell’indirizzo usa il percorso diretto, che sia quello che avevate in mente o no. Al contrario, un sito web può rispondere da più indirizzi, quindi esentare una /32 non esenta il sito. Se il requisito reale è l’instradamento per applicazione, la tabella di routing del client Community è lo strumento sbagliato.

Verificare l’eccezione senza ingannarsi

Cominciate dalla rotta installata, non dal browser. Su Linux, chiedete al kernel quale rotta e quale salto successivo userà per l’indirizzo specifico; su Windows, leggete la tabella di routing per quella /32. Confermate che il gateway è quello fisico e non il tunnel. Se la voce manca, il profilo non è stato applicato o il client non aveva il privilegio di modificare le rotte.

Poi provate due destinazioni. Una richiesta all’indirizzo esentato dovrebbe uscire dall’interfaccia fisica, e una richiesta a un indirizzo interno di controllo dovrebbe continuare a usare il tunnel. Provare solo l’indirizzo esentato non dimostra nulla sul resto del tunnel, e provare un sito web pubblico prova l’indirizzo a cui quel sito è stato risolto, che potrebbe non essere quello della regola.

Infine, controllate i meccanismi che possono prevalere sulla rotta. Un kill switch lato client o un’impostazione block-outside-dns di Windows può vietare il traffico diretto, e questo si manifesta come una connessione che fallisce anche se la rotta è corretta. Non disattivate quei meccanismi per far sembrare che l’eccezione funzioni; se la politica vieta il percorso diretto, l’eccezione è un problema di progettazione per chi possiede il servizio VPN.

Ricontrollate dopo una riconnessione o un cambio di rete, perché il gateway precedente alla VPN e il percorso disponibile sono proprietà del momento, non del profilo.