OpenVPN redirect-gateway: que fai cada indicador nas rutas

Conéctate con redirect-gateway no perfil e a ruta predeterminada da túa máquina pode desaparecer, dividirse en dúas ou quedar exactamente onde estaba, segundo indicadores que ninguén le dúas veces. A opción cambia o estado de enrutamento e nada máis, así que a única proba fiable do que fixo é a táboa que o cliente instalou despois. O que segue é a táboa tras unha conexión, a ruta que mantén vivo o túnel e o tráfico IPv6 que a directiva nunca afirma cubrir. Cada paso é un comando que podes executar no cliente mentres o túnel está activo.

Que fai cada indicador na ruta predeterminada

Sen ningún indicador, a opción elimina a ruta predeterminada normal e pon o túnel no seu lugar, así que a antiga porta de enlace desaparece da táboa mentres a conexión está activa. Engade def1 e esa ruta predeterminada segue na lista, con dúas rutas máis estreitas facendo o traballo. Engade bypass-dhcp e a ruta DHCP tamén sobrevive, o que importa nunha rede onde o cliente aínda ten que chegar ao servidor DHCP local. A lista de indicadores da páxina do manual de OpenVPN 2.6 é o bastante curta para lela unha vez, e cada entrada cambia que rutas acaban na táboa.

Unha opción empurrada compórtase igual en canto chega, así que o perfil do cliente pode non conter nada mentres a táboa parece completamente redirixida. É normal: o servidor enviou os indicadores, o cliente aplicounos e o ficheiro local nunca mencionou a directiva. Cando un envío parece non facer nada, revisa o filtro do lado do cliente que acepta ou descarta as opcións extraídas, porque unha opción descartada non xera erro en ningún dos dous extremos.

def1 gaña por especificidade sen tocar a túa ruta predeterminada

Dúas rutas de medio defecto cobren entre ambas o espazo IPv4, 0.0.0.0/1 e 128.0.0.0/1. Cada unha é máis específica que 0.0.0.0/0, así que unha consulta prefire as dúas mentres a ruta predeterminada real queda na táboa para todo o que pide a coincidencia menos específica.

Le a táboa en lugar do perfil, porque só a táboa mostra en cal deses casos estás. Dúas liñas abondan para distinguilos:

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

Fíxate na interface e na métrica de cada liña, non só no destino. Unha ruta predeterminada que apunta ao túnel e un par de medias rutas que apuntan ao túnel describen a mesma intención e fallan de forma distinta cando o túnel cae, porque nun caso o respaldo segue existindo. Anota ambos os campos na nota de cambio. Un respaldo supervivente é ás veces o que mantén viva unha sesión remota o tempo suficiente para reparar o túnel, e tamén é o que filtra tráfico cando a intención era un túnel completo.

Mantén accesible o extremo do túnel

O cliente necesita unha ruta cara ao extremo afastado do túnel que non pase ela mesma polo túnel. OpenVPN instala esa ruta de host antes de cambiar calquera outra cousa, e unha edición manual de rutas ou un segundo cliente VPN poden quitarlle. O síntoma despois é unha conexión que di estar conectada e logo non pasa nada.

Pregunta ao núcleo que interface usaría para o enderezo do extremo mentres o túnel está activo. A resposta debe nomear a interface física e a súa porta de enlace, nunca tun0:

ip route get 198.51.100.20

Se esa consulta devolve o dispositivo do túnel, o túnel leva o seu propio transporte e colapsará en canto un paquete teña que saír. Os prefixos locais, un segundo adaptador e o enrutamento por políticas seguen importando aquí, por iso unha redirección que funciona nun portátil limpo pode fallar nun host cunha interface de xestión e dúas rutas predeterminadas. Normalmente cúlpase o perfil do que fixo o plan de enderezos.

O tráfico IPv6 segue usando a súa propia táboa

Redirixir IPv4 deixa IPv6 tranquilo, e as dúas familias cámbianse con indicadores distintos. Nun host de dobre pila cunha ruta v6 predeterminada que funciona, o tráfico v4 pode quedar completamente dentro do túnel mentres cada destino capaz de v6 sae pola ligazón física. Un host que parece correcto nunha táboa filtra na outra.

Revisa a táboa v6 despois de conectar en lugar de supor que o túnel a cubriu. A directiva leva indicadores de familia de enderezos xusto por iso, e un perfil que os omite herda o que a plataforma fai por defecto:

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

Demostra que interface usa unha aplicación

Un estado conectado non é un bloqueo, e un cambio de ruta non é un interruptor de seguridade. Se o tráfico directo ten que parar cando o túnel falla, esa política vive na devasa e necesita a súa propia proba.

Proba o camiño que unha aplicación segue realmente en lugar do camiño que describe o perfil. Pide primeiro a ruta, despois liga unha solicitude a cada interface por quenda e compara o que informa o lado afastado:

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

Se ambas as solicitudes devolven o mesmo enderezo, a aplicación non usa o túnel aínda que a táboa de enrutamento diga que debería. Se só ten éxito a solicitude ligada ao túnel, o camiño físico está filtrado para ese destino e o túnel fai o que pediches. Escribe os indicadores, as rutas instaladas, a consulta do extremo e ambos os resultados de saída no rexistro de cambios, para que a seguinte persoa herde feitos en lugar dunha captura de pantalla.