Dos clientes OpenVPN en un mismo host Linux: ¿quién es dueño de la ruta?

Ambos perfiles informan que están conectados y uno de ellos transporta en silencio tráfico destinado al otro. Dos clientes en un mismo host es una disposición admitida; dos clientes sin dueño para cada prefijo no lo es. El trabajo trata menos de levantar el segundo túnel y más de decidir qué proceso puede reclamar qué ruta. Recorra el orden de abajo y la configuración se desprende de las respuestas.

Empiece preguntando para qué sirve el segundo túnel

Tres situaciones se ven idénticas en la línea de estado y necesitan diseños distintos. Una división por destinos envía un prefijo por el perfil de oficina y otro por el de laboratorio, sin que ninguno reclame una ruta por defecto. Una división por aplicación suele mantener un túnel completo y dirigir tráfico concreto con reglas de política. La conmutación por error mantiene exactamente un túnel activo a la vez, lo que significa que el segundo no debe arrancar automáticamente.

Escriba el caso antes de abrir cualquier archivo de configuración, porque esa respuesta decide todo lo que viene después.

La disposición rota más común son dos túneles completos que ambos empujaron una ruta por defecto, donde gana el que se conectó último y el primero sigue fingiendo. Ese estado parece intencional desde la línea de estado y desperdicia un día de la tabla de rutas. Nombrar el caso primero lo vuelve imposible, no solo improbable.

Mire los pools antes que las rutas

Dos servidores pueden repartir fácilmente direcciones de un solo rango privado y, cuando lo hacen, el cliente acaba con dos interfaces dentro de un mismo prefijo. Ningún destino puede entonces atribuirse a una interfaz por dirección, porque ambos parecen igual de correctos. Renumere un pool en lugar de inventar una regla para romper el empate.

Revise también la red local, porque una LAN doméstica o de oficina que se solape con un rango de túnel crea la misma ambigüedad desde el otro lado. Compare las direcciones del host con ambas configuraciones de servidor antes de culpar al cliente. Un cambio de pool en un servidor de laboratorio es una corrección de cinco minutos, mientras que un rodeo de enrutamiento por política para un prefijo solapado es un impuesto permanente para todo el que lea la configuración después. Decida cuál de los dos quiere antes de elegir dónde intervenir.

Dos familias de direcciones significan dos rondas de esta comprobación. Los pools IPv6 chocan tan silenciosamente como los IPv4.

Dé a cada perfil un dueño

Una instancia por perfil, un archivo de configuración por instancia y un nombre que identifique al par. En el empaquetado al estilo Debian, el nombre después del signo @ selecciona el archivo, por lo que dos perfiles que comparten un nombre de instancia nunca pueden funcionar ambos. Confirme la correspondencia desde la unidad instalada y no desde un tutorial.

systemctl cat [email protected]
ip -4 addr show

Luego decida quién instala las rutas, que es una cuestión de política y no de sintaxis.

Cuando los dos servidores empujen conjuntos incompatibles, o bien añada route-nopull y enumere solo los prefijos que cada perfil necesita, o bien deje que uno conserve su ruta por defecto y dirija el resto con una regla de política. Dos procesos que ambos instalan una ruta por defecto acaban con un solo ganador y nadie puede decir por qué. En cuanto los dos túneles llevan tráfico de fuentes distintas, una respuesta puede salir por el equivocado, y el patrón que aguanta es una marca de conexión restaurada en las respuestas y dirigida a su propia tabla. Limite las marcas para que los paquetes cifrados propios de los túneles nunca coincidan con ellas.

Verifique por túnel y luego detenga uno

Cuando ambos estén arriba, tome tres lecturas: la dirección de cada dispositivo de túnel, la ruta a un host que viva detrás de cada uno y el camino que tomaría un destino fuera de ambos. Un listado de rutas corriente deja de describir la consulta final en cuanto entran reglas en juego, así que pregunte al núcleo qué elegiría de verdad. Luego detenga una instancia y observe qué desaparece. Si detener la primera perturba la segunda, algo sigue compartido entre ellas: una ruta, un nombre de dispositivo o una regla de cortafuegos que nadie separó.

ip rule show
ip route get 203.0.113.9

Vuelva a levantar el perfil detenido y repita las mismas comprobaciones, porque un túnel que funciona una vez tras un reinicio y nunca más es un error de ciclo de vida disfrazado de enrutamiento.

Anote en las notas de despliegue qué perfil posee qué prefijo, junto a los rangos de pools. Dos túneles son una disposición deliberada, y el siguiente lector necesita ver el límite antes de tocar cualquier perfil. Sin esa nota, el límite lo redescubre quien esté de guardia cuando el prefijo compartido por fin se rompa.