Com enviar una destinació IPv4 fora d’un túnel OpenVPN

La majoria de configuracions de túnel complet envien cada paquet a través de la VPN, i redirect-gateway és la directiva que ho fa possible. Una sola destinació encara es pot eximir. Afegir una ruta d’amfitrió per a aquesta adreça amb el marcador net_gateway diu al client que hi arribi a través de la porta d’enllaç original de la màquina, mentre que tota la resta continua utilitzant el túnel.

La línia sembla inofensiva i sovint ho és, però només resol una pregunta: on van els paquets per a aquesta adreça IPv4 exacta. No canvia el DNS, l’IPv6, la política del tallafoc ni quin procés va obrir la connexió, i cadascun d’aquests pot anul·lar l’excepció sense fer soroll.

Què anomena realment net_gateway

L’entrada del perfil per a aquesta excepció és una línia: route 198.51.100.77 255.255.255.255 net_gateway. La primera adreça és un marcador de documentació per a la destinació, la màscara la converteix en una ruta d’un sol amfitrió, i l’últim testimoni anomena el marcador de la porta d’enllaç. OpenVPN resol els marcadors de porta d’enllaç quan instal·la rutes. vpn_gateway significa la porta d’enllaç pròpia del túnel, el costat llunyà de l’enllaç VPN. net_gateway significa la porta d’enllaç predeterminada que tenia l’amfitrió abans que la VPN canviés res, que normalment és el router local de la xarxa física.

Un tercer marcador, remote_host, fa referència a l’adreça del servidor VPN, i existeix perquè el túnel pugui arribar al servidor pel camí físic. Confondre aquests tres és el motiu més habitual que una excepció vagi al lloc equivocat o que no s’instal·li gens.

El valor es llegeix en el moment de la connexió, no s’escriu al fitxer. Si la màquina es trasllada a una altra xarxa, la porta d’enllaç prèvia a la VPN canvia i la ruta segueix la nova. Normalment és el que voleu, però també vol dir que el comportament de l’excepció depèn de la xarxa des de la qual va arrencar el client.

Per què una ruta d’amfitrió guanya la ruta predeterminada del túnel

L’encaminament es decideix pel prefix coincident més específic. redirect-gateway def1 normalment no substitueix la ruta predeterminada; afegeix dues meitats, una ruta per a la meitat inferior de l’espai d’adreces i una per a la meitat superior, de manera que la ruta predeterminada original es conserva per a altres usos. Aquestes meitats són més àmplies que una sola adreça.

Una ruta per a una adreça amb màscara 255.255.255.255 és una /32, que és tan específica com pot arribar a ser l’IPv4. Quan s’avalua un paquet per a aquesta adreça, la /32 coincideix i guanya independentment de quina ruta es va instal·lar primer. Aquest és el mecanisme darrere de l’excepció, i funciona igual a Linux, macOS i Windows sempre que la ruta hi sigui realment.

Windows afegeix una segona dimensió. Quan dues rutes són igual de específiques, guanya la de mètrica més baixa, i un adaptador VPN pot portar una mètrica d’interfície que canvia el resultat. Una /32 segueix sent més específica que les meitats, així que l’excepció normalment es manté, però una ruta antiga d’una sessió anterior pot produir un resultat confús si és igual de específica.

Què no cobreix l’excepció

El DNS és la primera escletxa. El client pot empènyer configuracions de resolució internes, i el sistema operatiu continuarà utilitzant-les per a les consultes. Una aplicació que resol un nom abans de connectar-se pot rebre una adreça interna per a un servei que hauria d’anar directe, o una adreça externa que es resol correctament però després ensopega amb la següent escletxa.

L’IPv6 és la segona. La directiva de ruta només gestiona IPv4. Una destinació de doble pila pot preferir IPv6, que segueix el túnel o la ruta predeterminada IPv6 de l’amfitrió segons la política, així que l’excepció IPv4 mai no entra en joc. Necessiteu una ruta IPv6 coincident, o una decisió deliberada de desactivar IPv6 per a aquest client.

L’abast d’aplicació és la tercera. La regla es basa en la destinació, així que cada procés que es connecta a aquesta adreça utilitza el camí directe, tant si és el que teníeu al cap com si no. A la inversa, un lloc web pot respondre des de diverses adreces, així que exceptuar una /32 no exceptua el lloc. Si el requisit real és l’encaminament per aplicació, la taula de rutes del client Community és l’eina equivocada.

Comprovar l’excepció sense enganyar-se

Comenceu per la ruta instal·lada, no per un navegador. A Linux, pregunteu al nucli quina ruta i quin salt següent utilitzarà per a l’adreça concreta; a Windows, llegiu la taula de rutes per a aquesta /32. Confirmeu que la porta d’enllaç és la física i no la del túnel. Si l’entrada falta, el perfil no s’ha aplicat o el client no tenia el privilegi de canviar rutes.

Després proveu dues destinacions. Una petició a l’adreça exceptuada hauria de sortir per la interfície física, i una petició a una adreça interna de control hauria de continuar utilitzant el túnel. Provar només l’adreça exceptuada no demostra res sobre la resta del túnel, i provar un lloc web públic prova l’adreça que aquest lloc ha resolt, que pot no ser la de la regla.

Finalment, reviseu els controls que poden passar per sobre de la ruta. Un kill switch del costat del client o una configuració block-outside-dns de Windows poden prohibir el trànsit directe, cosa que es veu com una connexió que falla encara que la ruta sigui correcta. No desactiveu aquests controls per fer que l’excepció sembli funcionar; si la política prohibeix el camí directe, l’excepció és un problema de disseny per a qui posseeixi el servei VPN.

Torneu a comprovar-ho després de reconnectar o canviar de xarxa, perquè la porta d’enllaç prèvia a la VPN i el camí disponible són propietats del moment, no del perfil.