Evite la pérdida de la conexión SSH después de iniciar sesión en VPN en la máquina del servidor

Encontré un problema que no puedo resolver. Cuando estoy conectado a un VPS a través de SSH e intento estabilizar la conexión VPN en ese VPS, la conexión SSH entre VPS y mi máquina se pierde. Supongo que es porque la configuración de VPN cambió el enrutamiento. ¿Cómo prevenir eso?

Debe agregar la route-nopullopción (y eliminarla redirect-gatewaysi existe) al archivo de configuración de su cliente OpenVPN en su VPS.

De esa manera, conectarse a un servidor VPN no modificará ninguna ruta en su VPS, por lo que podrá configurar las que necesita por sí mismo.

Consideremos el siguiente escenario:

1. su VPS tiene una única interfaz de ethernet, configurada con la dirección IP 4.3.2.1/24;
2. su VPS puede acceder a Internet a través de una puerta de enlace predeterminada 4.3.2.254
3. su VPS aún no ha activado ninguna conexión OpenVPN; por lo tanto no hay interfaz de tun activa

En tal escenario, desde su máquina (supongamos que su máquina es 9.8.7.6/24 con def-gw 9.8.7.254) puede establecer con éxito una conexión SSH a 4.3.2.1. Por lo tanto, ambos hosts 4.3.2.1 y 9.8.7.6 pueden comunicarse exitosamente entre sí.

Ahora, con una conexión SSH establecida, supongamos:

4. inicia una conexión OpenVPN desde su VPS 4.3.2.1;
5. como tal, una nueva interfaz tun0 se configurará dinámicamente (supongamos que se le asignará una IP 10.10.10.2, con un PTP 10.10.10.1).

En este punto:

• SI no se enviará ninguna ruta desde el servidor remoto OpenVPN a su VPS local, entonces nada cambiará en términos de enrutamiento, y su conexión SSH sobrevivirá sin ningún problema. En este caso, el único tráfico que atraviesa la VPN es el que se dirige hacia el servidor remoto OpenVPN (10.10.10.1);

• SI el servidor remoto OpenVPN retrasará alguna ruta, y especialmente si la puerta de enlace predeterminada de VPS se reemplazará con 10.10.10.1 (punto final remoto de OpenVPN), ENTONCES está teniendo problemas. En este caso, está tunelizando TODO el tráfico IP saliente (con la excepción de OpenVPN) dentro de la VPN.

En este segundo caso (reemplazando def-gw justo después de establecer la conexión VPN), su conexión SSH anterior se "colgará", debido al enrutamiento asimétrico:

• El tráfico de su máquina (9.8.7.6) a VPS (4.3.2.1) fluirá a través de la ruta anterior, nunca cambiada;
• Tráfico de VPS (4.3.2.1) a su máquina (9.8.7.6):
  • sin la VPN (por lo tanto, inicialmente) fue enrutada a través de la puerta de enlace 4.3.2.254;
  • después del establecimiento del enlace VPN, con el reemplazo de def-gw relacionado, se enruta a través de la VPN (10.10.10.1).

En otras palabras: tan pronto como se establezca el enlace VPN, su ruta de regreso de VPS a su máquina va a cambiar y ... esto no es algo bueno (varios dispositivos de red, a lo largo de la ruta de retorno, pueden reconocer tal asimétrica ruta y simplemente descartar paquetes).

Además, es muy probable que su servidor remoto OpenVPN esté actuando como una caja NAT: todo el tráfico proveniente de la VPN será NATizado con la dirección IP pública del servidor remoto OpenVPN. Si esto es cierto, las cosas ya no son ... "no es bueno", pero definitivamente "malo", en cuanto a su conexión SSH: el tráfico de retorno, además de regresar por una ruta diferente, regresa a su máquina con una IP de origen diferente (la de la interfaz pública del servidor VPN).

¿Cómo resolver este problema?

Muy fácilmente, de hecho.

Simplemente indique a su servidor VPS que no enrute el tráfico a su máquina a lo largo de la VPN, sino que confíe en la ruta anterior . Debería ser tan fácil como agregar, antes de iniciar OpenVPN:

     route add -host 9.8.7.6 gw 4.3.2.254

dónde:

• 9.8.7.6 es la dirección IP pública de su máquina
• 4.3.2.254 es la puerta de enlace predeterminada original de su VPS.

PD: al proporcionar una pregunta mucho más detallada, habría obtenido una respuesta mucho más rápida :-)

Esto puede ayudar:

poner TCPKeepAlive=yesen su/etc/ssh/sshd_config

Desde

man sshd_config | less +/'^ *TCPKeepAlive'

TCPKeepAlive

Especifica si el sistema debe enviar mensajes de actividad TCP al otro lado. Si se envían, se notará correctamente la muerte de la conexión o el bloqueo de una de las máquinas. Sin embargo, esto significa que las conexiones morirán si la ruta se corta temporalmente, y algunas personas lo encuentran molesto. Por otro lado, si no se envían mensajes de alerta TCP, las sesiones pueden colgar indefinidamente en el servidor, dejando a los usuarios `` fantasmas '' y consumiendo recursos del servidor.

El valor predeterminado es yes'' (to send TCP keepalive messages), and the server will notice if the network goes down or the client host crashes. This avoids infinitely hanging sessions. To disable TCP keepalive messages, the value should be set tono ''.

Tuve este problema y probé todas las soluciones recomendadas, y aún así, ¡mi problema no se resolvió!

Después de muchos intentos de solución, usé el screencomando. (mi cliente VPN es cisco-any-connect).

$ screen -R VPN
$ openconnect -b "your server"

Después de proporcionar su credencial, presione ctrl + a + d inmediatamente y vuelva a su sesión.

Personalmente, prefiero que todas las conexiones a SSH se enruten a través de VPN. En caso de conexión ssh activa antes de que se establezca la VPN, debe volver a conectarse debido a que la ruta ha cambiado.

Recomiendo usar autossh Bajo su configuración de cliente ssh solo agregue.ssh/config

Host *
   ServerAliveInterval 300
   ServerAliveCountMax 2
   BatchMode yes

• BatchMode significa reconexión automática
• ServerAlive son las siglas de Keeping Alive

Una vez después de conectar VPN, ssh se desconecta porque el tráfico ssh del servidor va a través del servidor VPN. Para evitar esto, ejecute el siguiente comando antes de conectar VPN.

route add -host your-machine-public-ip gw Server-gatway-ip dev eth0

your-machine-public-ip: IP de su máquina desde donde está haciendo SSH. Server-gatway-ip: IP de Gatway / enrutador de ese servidor

El comando anterior redirigirá el tráfico a través de la puerta de enlace dada, no a través del servidor VPN.