Mantén varios túneles vpnc activos con sondeos por perfil

Un perfil vpnc se reconecta limpiamente tras un roaming; tres de ellos se turnan para romperse los sockets, las rutas y el estado del resolutor. El script de reconexión del paquete está escrito para un solo túnel, así que reinicia cada perfil cada vez que uno cualquiera está caído. Arreglar eso exige tres cosas: puertos locales separados, un sondeo que pruebe un servicio real por perfil y una cadena ordenada que nunca ejecute dos conexiones a la vez.

Dale a cada perfil su propio puerto local

Un perfil vpnc que se deja en el puerto local predeterminado compite con el perfil que ya está en marcha. La segunda conexión falla mientras la primera retiene el puerto, y la línea del registro parece un problema de puerta de enlace más que un conflicto local. En su lugar, pon una línea por archivo de perfil:

Local Port 0

El cero deja que el núcleo elija un puerto efímero, así que dos perfiles pueden establecerse al mismo tiempo. Nombra cada archivo por la puerta de enlace y el grupo al que sirve, mantenlo legible solo para root y conéctate siempre con el perfil correspondiente en lugar de con un valor predeterminado compartido. Un archivo predeterminado compartido es la forma en que un script reconecta el túnel equivocado después de que alguien cambie el nombre de un perfil.

Los archivos de perfil llevan credenciales, así que los permisos forman parte del diseño y no de la limpieza. Un archivo legible por todos bajo /etc/vpnc entrega el secreto del grupo a cada usuario local. Mantén el modo en 0600 con root como propietario y deja que los scripts lean el archivo como root en lugar de copiar secretos en los argumentos. Por eso también un script de sondeo nunca debería volcar el contenido del archivo en un registro.

Sondea un servicio por perfil, no la dirección del túnel

Una solicitud de eco a la propia dirección del túnel demuestra sobre todo que la interfaz existe. No dice nada sobre si el host que hay detrás todavía alcanza la aplicación que justifica el túnel. La interfaz puede estar activa mientras la ruta que hay más allá ya ha desaparecido.

Sondea un servicio por perfil con un tiempo de espera TCP corto y reconecta solo el perfil cuyo sondeo falló. Dos segundos separan un camino muerto de uno lento, y un sondeo TCP no depende de que se permita ICMP en ningún punto del camino. Cambia solo el objetivo y el nombre de la configuración entre perfiles:

#!/bin/bash
set -eu
if ! nc -z -w 2 10.63.7.20 8443; then
  /usr/sbin/vpnc-connect ops.conf
fi

Guarda eso como /usr/local/bin/ensure-vpn-ops.sh, hazlo ejecutable y repítelo para cada perfil cambiando solo el objetivo del sondeo y el nombre de la configuración. Un sondeo que responde una pregunta de protocolo sobrevive a puertas de enlace que descartan el eco pero siguen reenviando los servicios que importan a los usuarios.

Encadena los sondeos para que nunca compitan

El script de reconexión del paquete puede llamar a tus sondeos en secuencia, y la secuencia es todo el objetivo. Dos llamadas de vpnc-connect que se ejecutan juntas reescriben la tabla de enrutamiento en un orden que nadie controla, y así es como un perfil sano pierde su ruta.

Mantén las llamadas en primer plano, añade una breve pausa de asentamiento para la interfaz subyacente y programa la cadena desde la tabla cron de root, ya que solo root puede reescribir las rutas del túnel:

#!/bin/bash
sleep 20
/usr/local/bin/ensure-vpn-ops.sh
/usr/local/bin/ensure-vpn-lab.sh

Mantén el orden idéntico entre el script de arranque y la entrada de cron, ya que una cadena que al arrancar se ejecuta en otro orden es en la práctica otro programa. Cuando un perfil depende de las rutas de otro, coloca la dependencia primero y deja que el sondeo posterior falle sin daño mientras el túnel anterior todavía está subiendo.

Vigila el registro y luego rompe uno a propósito

Registra una línea por ejecución con el perfil, el objetivo del sondeo, el resultado y la acción tomada. Sin eso, un túnel que oscila cada minuto se ve exactamente igual que uno que nunca cayó, y un fallo del sondeo es indistinguible de una caída de la puerta de enlace. El registro también demuestra que la cadena tocó solo el perfil que falló. Escríbelo en un lugar que sobreviva a un reinicio, o la evidencia se va con el proceso.

Luego rompe un túnel a propósito y observa qué pasa. Detén un solo perfil y confirma qué procesos y rutas siguen presentes:

pgrep -a vpnc
ip -4 route show | grep -E '10[.]63|10[.]90'
tail -n 5 /var/log/ensure-vpn.log

Solo el perfil detenido debería reconectarse, y las otras sesiones deberían conservar tanto sus procesos como sus rutas. Si dos perfiles se reinician, tu cadena se está ejecutando en paralelo en algún lugar que no esperabas.

Lo que el vigilante no debe hacer

Un vigilante que reinicia todo cuando algo falla parece saludable durante las pruebas y provoca una caída en una ventana de mantenimiento. Reinicia por perfil, nunca globalmente.

Prefiere un cliente mantenido cuando la puerta de enlace ofrece uno para el mismo protocolo, y nunca codifiques una contraseña en el script ni la pases en una línea de comandos, porque el archivo de perfil ya guarda el secreto. Si una tarea debe ejecutarse como usuario normal una vez que el túnel está activo, reduce privilegios desde dentro del script en lugar de hacer que toda la cadena corra bajo esa cuenta. Por último, vuelve a leer las rutas tras una reconexión, porque un perfil puede volver con otra dirección asignada y dejar una ruta obsoleta que ningún sondeo dirigido a la dirección del túnel notará nunca.