Inicias un cliente VPN por SSH? Fixa antes a túa propia ruta

Entras por SSH nun host de compilación, inicias alí o cliente VPN e a sesión deixa de responder. Nada fallou e nada parece mal configurado no sentido obvio. O cliente instalou unha ruta predeterminada, así que as respostas á túa estación de traballo agora saen polo túnel, onde o enderezo da túa estación de traballo non é encamiñable. O interesante é que este resultado era previsible, e a solución é unha ruta escrita antes de que arrinque o cliente. Supoñamos un servidor cunha soa tarxeta de rede, unha pasarela 192.0.2.254 e un administrador que se conecta desde 203.0.113.9.

Rexistra o camiño antes de comezar

ip route show default nomea a pasarela e a interface actuais, mentres que ip route get 203.0.113.9 mostra que interface e que enderezo de orixe usaría o núcleo para a túa sesión. Garda ambas saídas. Cando o túnel suba, eses dous comandos deberían seguir describindo o camiño físico, e se describen o túnel no seu lugar, a sesión xa vive de tempo prestado.

A conexión xa establecida é a que importa, así que non valides só cun inicio de sesión novo. Unha sesión nova pode ter éxito brevemente grazas a un estado que a vella xa non ten.

Fixa o enderezo na propia configuración do cliente

Unha ruta engadida a man desaparece ao reiniciar e compite coas actualizacións de táboa do propio cliente, así que pon a excepción onde se xestiona a táboa. En OpenVPN a palabra clave net_gateway resólvese á pasarela que existía antes do túnel, así que route 203.0.113.9 255.255.255.255 net_gateway mantén exactamente un enderezo fóra del. WireGuard necesita outro enfoque porque wg-quick xestiona as rutas el mesmo: estabelece Table = off e engade a excepción en PostUp, cun PostDown correspondente que a elimine. Ambas formas expresan a mesma intención, e ambas limitan a excepción a un enderezo en lugar de debilitar o túnel para todo.

Para IPv6 a mesma idea toma un prefixo dun só host, e o caso do transporte encapsulado paga a pena recordalo: se a conexión exterior do propio túnel vive nun enderezo fixo, ese enderezo ten que quedar fóra do túnel que transporta, ou o cliente encamiña o seu propio transporte cara a si mesmo.

Ou saca a táboa principal da ecuación

Cando varios servizos do host deben conservar o seu camiño normal, deixa de editar a táboa principal e dálle ao cliente a súa. Un espazo de nomes de rede cun par veth fai iso limpiamente: a ruta predeterminada do cliente vive noutra pila e só os procesos iniciados dentro usan o túnel. O encamiñamento por políticas chega a un lugar similar para un destino, enviando o tráfico coincidente a unha táboa dedicada cuxa ruta predeterminada segue apuntando á pasarela física. Calquera dos dous enfoques deixa a táboa principal do host sen unha nova ruta predeterminada, e esa é a propiedade que mantén SSH respondendo.

Ambos son máis maquinaria que unha soa ruta de host, e ambos paga a pena cando máis dunha cousa na máquina ten que sobrevivir ao túnel.

Asume que a fixación pode fallar

Unha ruta ligada ao teu enderezo público actual rompe no momento en que o teu provedor o reasigna. Un servidor remoto necesita entón un camiño que non dependa dese enderezo: unha consola, unha segunda interface de xestión ou un host de salto que quede fóra do túnel.

Dúas salvagardas custan dez minutos. Un vixiante que detén o cliente se non aparece un inicio de sesión de confirmación nuns minutos converte un bloqueo nun atraso, e unha segunda sesión SSH mantida aberta durante o cambio demostra que a excepción funciona mentres o túnel está arriba. Os keepalives por si sos non axudan aquí, porque o camiño desapareceu en lugar de estar inactivo; só fan que a morte sexa máis fácil de notar.

Verifica na orde que importa

Conecta o túnel, confirma que a ruta ao teu enderezo segue saíndo pola pasarela física e logo abre unha sesión nova. Se a sesión nova funciona e a vella morre de todos modos, a causa é o seguimento de conexións ou un cortalumes con estado, non o encamiñamento, o que é unha solución distinta.

Escribe o enderezo fixado e o comando que o demostrou no rexistro de cambios. A seguinte persoa que inicie un cliente nese host necesitará ambas as dúas cousas, e pode que o enderezo xa cambiase para entón.