A túa antiga ruta predeterminada sobrevive a OpenVPN a propósito

Conectas o túnel, executas ip route e a pasarela predeterminada orixinal segue aí. O seguinte pensamento é que o cliente non asumiu a ruta, así que borras a predeterminada á man e perdes a conectividade por completo. Esa entrada debe permanecer. Con redirect-gateway def1, OpenVPN instala dúas rutas máis específicas que superan a predeterminada normal en lugar de substituíla. A pasarela antiga queda e deixa de transportar o tráfico que estaba a probar.

Que fai def1 en realidade

O indicador engade 0.0.0.0/1 e 128.0.0.0/1, ambas apuntando ao túnel. 0.0.0.0/1 abrangue todo enderezo cuxo primeiro octeto vai de 0 a 127, e 128.0.0.0/1 abrangue de 128 a 255, así que cada destino IPv4 ten unha coincidencia máis específica que a ruta predeterminada antiga. A lonxitude do prefixo, non a métrica, decide que ruta gaña.

Deixar a ruta predeterminada orixinal no seu sitio é deliberado. O cliente non ten que lembrar que substituíu e non reescribe a ruta que leva a súa propia conexión ao servidor VPN. Ao desconectar elimina as dúas medias rutas e a táboa volve a como era.

Por que /1 e non /0

O encamiñamento escolle o prefixo coincidente máis longo, non a métrica máis baixa, así que unha /1 vence a unha /0 diga o que diga a métrica da predeterminada. Ambas as metades existen porque unha /1 só cobre a metade do espazo; con só 0.0.0.0/1 presente, todo o que hai desde 128.0.0.0 en diante segue a ruta predeterminada antiga, o que produce o síntoma confuso de que algúns sitios funcionan e outros non.

Subir ou baixar a métrica da ruta predeterminada antiga non cambia nada, e unha predeterminada con métrica máis baixa noutra interface tampouco rouba o tráfico. Primeiro decide a lonxitude do prefixo, e só os prefixos iguais recorren á métrica.

Le unha táboa de encamiñamento real

Un host conectado pode mostrar as tres entradas á vez, co túnel levando as metades e a pasarela orixinal aínda na lista. Os enderezos son exemplos e non unha configuración que copiar, porque os nomes de interface, a topoloxía do túnel e as rutas adicionais varían segundo a plataforma e o cliente.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

O importante é a relación: dúas metades concretas por riba dunha predeterminada xeral. A liña da pasarela antiga queda porque nada a substituíu.

Comproba que ruta colle realmente o paquete

As rutas máis específicas aínda poden gañar: unha ruta para un rango privado, unha subrede local ou o propio enderezo do servidor VPN é máis longo que unha /1. O túnel necesita un camiño exterior cara ao seu servidor, e devolver esa conexión ao túnel romperíao de inmediato. En Linux pregúntalle ao núcleo en vez de ler a táboa a ollo: ip route get co destino que che interesa imprime a ruta escollida, a interface e a orixe. Se hai encamiñamento por políticas configurado, revisa tamén as regras, porque unha regra pode escoller outra táboa antes de consultar a principal.

Se só parte de IPv4 se comporta mal, confirma que ambas as metades están instaladas e despois busca unha excepción que coincida co destino que falla. Borrar a ruta predeterminada antiga non é unha solución, e elimina a ruta que o cliente necesita para desmontar o túnel limpiamente.

Que non cobre def1

Dúas entradas IPv4 non din nada sobre IPv6: un host con conectividade IPv6 segue usando a súa propia ruta predeterminada ata que algo redirixa esa familia por separado, e por iso nunha rede de dobre pila parte do tráfico parece evitar o túnel. Outros clientes e xestores de rede implementan o encamiñamento de túnel completo de forma distinta, e as súas táboas non coincidirán. O comportamento de def1 descrito aquí pertence ao indicador documentado de OpenVPN, non a cada VPN da máquina.

Un kill switch responde a outra pregunta: que fai a máquina cando cae o túnel. A precedencia de rutas decide cara a onde vai o tráfico mentres o túnel está activo; non decide que fai despois unha devasa. Orde de traballo: le a táboa, confirma que existen ambas as metades, executa ip route get para o destino que falla, revisa as regras de política e despois mira IPv6 por separado. Deixa a ruta predeterminada antiga onde está.