O túnel completo matou a túa sesión SSH: fixa a ruta de retorno

Inicia un OpenVPN cliente na máquina na que traballas por SSH, e a metade do comando a sesión conxélase. O túnel declara estar conectado, o host chega a internet a través del e as túas pulsacións seguen chegando mentres non volve nada. O que cambiou non é o túnel: é a ruta de retorno dos paquetes dirixidos a ti, que agora coincide coa nova ruta por defecto e entra nun túnel que a pasarela remota non vai usar para chegar ao teu escritorio.

Que instala realmente redirect-gateway

Na súa forma def1 redirect-gateway engade 0.0.0.0/1 e 128.0.0.0/1 en lugar de sobrescribir a ruta por defecto. Esas dúas metades cobren todo o espazo de enderezos e ambas seguen sendo prefixos máis longos que 0.0.0.0/0, así que calquera destino sen unha coincidencia máis específica entra agora no túnel. Ese é o mecanismo que hai que reter, porque cada arranxo de aquí abaixo funciona instalando unha coincidencia máis específica.

O teu enderezo administrativo é un deses destinos.

O servidor VPN reenvía o tráfico dos seus clientes cara a internet. Non ten ruta para o enderezo público desde o que te conectas, nin motivo para tratar eses paquetes como algo distinto do tráfico que chega dun cliente, así que os descarta. Mentres tanto, a petición que enviaches si chegou ao host, e por iso a sesión parece viva só dun lado.

ip route show table main | head -n 20
ip route get 198.51.100.23

Atopa o teu enderezo de orixe e a ruta anterior ao túnel

No servidor, lista a conexión SSH establecida e anota o enderezo do par desde o que chegou. Ese enderezo é o que debe cubrir a túa ruta de retorno, e non sempre é o que cres: un host de salto, unha pasarela NAT ou un tradutor da operadora poden substituír a orixe por outra.

Despois atopa a pasarela física e a interface que transportaban o tráfico antes de que arrincase o túnel. Na def1 disposición a ruta por defecto segue presente baixo as medias rutas por defecto, así que a información está dispoñible, aínda que ler a ollo unha táboa de rutas longa invita a erros.

Anota os dous valores e o nome da interface xuntos, porque a ruta que vas engadir necesita os tres. Se o host usaba unha regra de enrutamento por políticas para escoller o seu enlace ascendente, pode que unha ruta simple non se consulte en absoluto, e esa posibilidade cambia o arranxo.

Fixa unha ruta de host que supere as medias rutas por defecto

Unha ruta /32 é máis longa que calquera das dúas medias rutas por defecto, así que as respostas ao teu enderezo tómana con preferencia ao túnel. O seguinte salto é a pasarela anterior ao túnel e o dispositivo é a interface física, o que mantén o paquete no camiño que usaba antes de que existise o túnel.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Verifica cunha consulta en lugar de inspeccionar a táboa: a resposta debe nomear eth0 e a pasarela, nunca tun0.

OpenVPN xa engade unha ruta de host cara ao propio enderezo do servidor VPN polo mesmo motivo, así que o patrón resulta familiar e o enderezo administrativo é simplemente outra excepción. Non recorras a route-nopull para arranxar isto, porque descarta as rutas empurradas que o túnel necesita, incluída a rede remota e as opcións de DNS.

Fai que sobreviva a unha reconexión

Unha ruta engadida a man desaparece cando o cliente se reconecta e reinstala a súa, o que converte un arranxo nunha caída recorrente. Engancha o comando a algo que se execute despois de instalárense as rutas.

Tanto un script route-up como o gancho pre-up do xestor de rede serven, e a comprobación fiable é unha reconexión seguida da mesma consulta.

En Windows o equivalente é unha ruta persistente engadida con -p, que sobrevive aos reinicios pero aínda debe apuntar á pasarela correcta tras un cambio de rede. Sexa cal sexa a plataforma, escribe o motivo xunto á ruta: o seguinte administrador necesita saber que existe para protexer unha sesión de xestión, non porque o deseño da rede o esixise.

Cando unha ruta fixada aínda non abonda

O filtrado de ruta inversa pode descartar un paquete que chega por unha interface e sae por outra, que é exactamente o que crea unha ruta fixada. Comproba o valor rp_filter efectivo antes de desactivar nada de forma global, e prefire corrixir a asimetría a apagar a comprobación. A configuración por interface é a que se aplica, e o modo loose a miúdo só rexistra a asimetría en lugar de descartar o paquete. Le as dúas cousas antes de concluír que o filtro ten a culpa.

Os hosts con enrutamento por políticas necesitan unha regra ademais dunha ruta, porque a base de regras escolle a táboa antes de que se consulte a ruta que contén. Unha ruta da táboa main é invisible para un fluxo que coincide cunha regra que apunta a outra táboa. Le as regras antes de engadir nada a main. Se unha regra xa cobre o tráfico de xestión, a excepción pertence á táboa desa regra.

Mantén aberta unha consola fóra de banda mentres probas, e volve comprobalo desde un segundo inicio de sesión antes de desconectar o que estás usando. Unha ruta que manda o teu propio tráfico de xestión ao túnel corta a conexión a través da cal a estás reparando. Volver entrar entón esixe unha consola serie ou un arrinque de rescate, que é un mal intercambio por saltarse un paso de verificación.