Dos túneles OpenVPN en un solo host Linux: ¿quién es dueño de la ruta?

Dos perfiles conectados, y uno de ellos transporta en silencio tráfico destinado al otro. Un host Linux puede ejecutar ambos clientes OpenVPN a la vez sin dificultad. Lo que no puede hacer es decidir por usted qué proceso puede reclamar qué prefijo. Esa decisión debe tomarse antes de que suba el segundo túnel, no después de que un recurso deje de responder.

Empiece por el trabajo que debe hacer el segundo enlace

Una oficina accesible por un perfil y un laboratorio accesible por otro necesitan ambos túneles arriba y que ninguno lo reclame todo. Una sola aplicación testaruda que debe salir por el segundo perfil necesita una regla de política en lugar de una segunda ruta predeterminada. Un enlace de reserva solo necesita un túnel funcionando a la vez, así que el de repuesto no debería arrancar con la máquina.

Son tres configuraciones diferentes, y se confunden porque las tres empiezan igual: un segundo perfil y una conexión correcta. Escriba primero la disposición prevista y luego configure hacia ella. Una frase de intención ahorra una hora de capturas de paquetes.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

El primer comando lista las instancias que se están ejecutando, incluidas las iniciadas a mano fuera del gestor. El segundo imprime la reclamación de ruta predeterminada actual, que es el estado que tendrá que explicar más adelante.

Los pools superpuestos se rompen antes que el enrutamiento

Dos servidores asignarán alegremente direcciones del mismo 10.8.0.0/24. El cliente pasa a tener dos interfaces dentro de un mismo prefijo sin nada que diga qué destino pertenece a cuál, y el comportamiento resultante parece una falla de enrutamiento pero en realidad es una falla de numeración. Renumerar un pool cuesta una edición de configuración; cada solución de enrutamiento posterior cuesta un fin de semana. Revise el pool antes de añadirle una ruta.

Mire también la LAN local. Una LAN doméstica numerada 192.168.1.0/24 que un túnel también expone produce la misma ambigüedad, y el síntoma es un nombre de host que se resuelve mientras la conexión nunca se completa. Eso parece una falla de resolución de nombres hasta que imprime las rutas.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Compare ambas salidas con las dos configuraciones de servidor antes de tocar el cliente. Si los prefijos se superponen, deténgase y renumere, porque ninguna cantidad de reinicios los separará.

Dé a cada perfil su propia unidad y a cada prefijo un dueño

Cada perfil recibe su propio nombre de instancia y su propio archivo de configuración, así que la instancia llamada office carga office.conf mientras la llamada lab carga lab.conf. Confirme esa asignación a través del gestor de servicios en lugar de confiar en un listado de directorio, ya que un drop-in puede cambiar qué archivo se carga. Equivocar la asignación significa que está ajustando el perfil que no se ejecuta.

Luego decida quién instala las rutas. Cuando los servidores empujan conjuntos incompatibles, o rechaza el empuje y lista los prefijos usted mismo, o deja que un perfil conserve la predeterminada y dirige el otro con reglas de política. Dos procesos que instalan ambos una predeterminada acaban con un ganador silencioso y sin registro escrito de la decisión.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

El primero muestra la unidad con cualquier anulación que cambie sus argumentos. El segundo muestra si el perfil acepta las rutas empujadas, que es el interruptor que decide todo lo demás.

Las marcas mantienen las respuestas en la interfaz de la que llegaron

Cuando cada túnel sirve fuentes distintas, una respuesta puede salir por el enlace equivocado y la conexión muere tras el primer paquete. El patrón que aguanta es marcar los paquetes entrantes por interfaz de entrada, restaurar esa marca en la respuesta y dar a cada marca una tabla con su propia puerta de enlace predeterminada.

El filtrado laxo de ruta inversa normalmente tiene que relajarse para las interfaces afectadas, porque una respuesta llega legítimamente por un enlace que la tabla principal nunca elegiría. Mantenga las marcas estrechas para que nunca capturen el tráfico cifrado de los propios túneles, lo que enviaría el túnel a través de sí mismo.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Lea las reglas existentes antes de añadir otra. Las prioridades duplicadas y las tablas olvidadas son la razón habitual de que una política de marcas parezca no tener efecto alguno.

Demuestre el aislamiento deteniendo un enlace

Con ambos túneles arriba, registre la dirección de cada interfaz, la ruta a un host detrás de cada túnel y el camino que toma un destino no relacionado. Pregunte al kernel por la búsqueda en lugar de leer una sola tabla, porque una tabla nunca muestra la decisión final.

Luego detenga una instancia y observe cómo su interfaz y sus rutas desaparecen mientras la otra sigue. Una ruptura en la superviviente significa que las dos aún comparten un nombre de dispositivo, una ruta o una regla de firewall que nadie separó.

Devuelva el perfil detenido y repita las mismas comprobaciones. Cuando un túnel solo sobrevive al primer arranque tras un reinicio, está viendo un defecto de ciclo de vida y no un diseño de enrutamiento.