Como enviar un destino IPv4 fóra dun túnel OpenVPN

A maioría das configuracións de túnel completo envían cada paquete pola VPN, e redirect-gateway é a directiva que o fai posible. Un só destino aínda pode exceptuarse. Engadir unha ruta de host para ese enderezo co marcador net_gateway díxolle ao cliente que chegue a el pola porta de enlace orixinal da máquina, mentres todo o demais segue usando o túnel.

A liña parece inofensiva e adoita selo, pero só resolve unha pregunta: a onde van os paquetes desa dirección IPv4 exacta. Non cambia o DNS, IPv6, a política da devasa nin que proceso abriu a conexión, e cada un deses pode anular a excepción en silencio.

Que nomea realmente net_gateway

A entrada do perfil para esa excepción é unha liña: route 198.51.100.77 255.255.255.255 net_gateway. O primeiro enderezo é un marcador de documentación para o destino, a máscara convérteo nunha ruta dun só host, e o último token nomea o marcador da porta de enlace. OpenVPN resolve os marcadores de porta de enlace cando instala rutas. vpn_gateway significa a porta de enlace propia do túnel, o lado afastado da ligazón VPN. net_gateway significa a porta de enlace predeterminada que tiña o host antes de que a VPN cambiase nada, que normalmente é o router local da rede física.

Un terceiro marcador, remote_host, refírese ao enderezo do servidor VPN, e existe para que o túnel poida chegar ao servidor pola ruta física. Confundir estes tres é a razón máis común de que unha excepción vaia ao lugar equivocado ou non se instale en absoluto.

O valor lese no momento da conexión, non se escribe no ficheiro. Se a máquina se traslada a outra rede, a porta de enlace previa á VPN cambia e a ruta segue a nova. Iso é normalmente o que quere, pero tamén significa que o comportamento da excepción depende da rede desde a que arrancou o cliente.

Por que unha ruta de host gaña á ruta predeterminada do túnel

O encamiñamento decídese polo prefixo coincidente máis específico. redirect-gateway def1 normalmente non substitúe a ruta predeterminada; engade dúas metades, unha ruta para a metade inferior do espazo de enderezos e outra para a metade superior, de xeito que a ruta predeterminada orixinal se conserva para outros usos. Esas metades son máis amplas que un só enderezo.

Unha ruta para un enderezo con máscara 255.255.255.255 é unha /32, que é o máis específico que pode ser IPv4. Cando se avalia un paquete para ese enderezo, a /32 coincide e gaña sen importar que ruta se instalou primeiro. Ese é o mecanismo detrás da excepción, e funciona igual en Linux, macOS e Windows sempre que a ruta estea realmente presente.

Windows engade unha segunda dimensión. Cando dúas rutas son igual de específicas, gaña a de menor métrica, e un adaptador VPN pode levar unha métrica de interface que cambia o resultado. Unha /32 segue a ser máis específica que as metades, así que a excepción normalmente mantense, pero unha ruta obsoleta dunha sesión anterior pode producir un resultado confuso se é igual de específica.

O que a excepción non cobre

O DNS é a primeira fenda. O cliente pode empurrar axustes de resolución internos, e o sistema operativo seguirá usándoos para as consultas. Unha aplicación que resolve un nome antes de conectar pode recibir un enderezo interno para un servizo que debería ir directo, ou un enderezo externo que se resolve correctamente pero logo tropeza na seguinte fenda.

IPv6 é a segunda. A directiva de ruta só xestiona IPv4. Un destino de dobre pila pode preferir IPv6, que segue o túnel ou a ruta predeterminada IPv6 do host segundo a política, así que a excepción IPv4 nunca entra en xogo. Necesita unha ruta IPv6 coincidente, ou unha decisión deliberada de desactivar IPv6 para ese cliente.

O alcance de aplicación é a terceira. A regra baséase no destino, así que cada proceso que se conecta a ese enderezo usa a ruta directa, sexa ou non o que tiña en mente. Ao revés, un sitio web pode responder desde varios enderezos, así que exceptuar unha /32 non exceptúa o sitio. Se o requisito real é o encamiñamento por aplicación, a táboa de rutas do cliente Community é a ferramenta equivocada.

Comprobar a excepción sen enganarse

Empece pola ruta instalada, non por un navegador. En Linux, pregunte ao núcleo que ruta e que seguinte salto usará para o enderezo concreto; en Windows, lea a táboa de rutas para esa /32. Confirme que a porta de enlace é a física e non o túnel. Se falta a entrada, o perfil non se aplicou ou o cliente non tiña o privilexio de cambiar rutas.

Despois probe dous destinos. Unha petición ao enderezo exceptuado debería saír pola interface física, e unha petición a un enderezo interno de control debería seguir usando o túnel. Probar só o enderezo exceptuado non demostra nada sobre o resto do túnel, e probar un sitio web público proba o enderezo ao que ese sitio resolveu, que pode non ser o da regra.

Por último, revise os controis que poden anular a ruta. Un kill switch do lado do cliente ou un axuste block-outside-dns de Windows pode prohibir o tráfico directo, o que se manifesta como unha conexión que falla aínda que a ruta sexa correcta. Non desactive eses controis para que a excepción pareza funcionar; se a política prohibe a ruta directa, a excepción é un problema de deseño para quen sexa dono do servizo VPN.

Volva comprobalo tras reconectar ou cambiar de rede, porque a porta de enlace previa á VPN e a ruta dispoñible son propiedades do momento, non do perfil.