Servidor y cliente OpenVPN en un mismo host: por qué se caen los clientes

Añada un perfil de cliente a una máquina que ya ejecuta un servidor VPN y el primer damnificado será el servicio original. El túnel nuevo puede no establecerse nunca, o puede levantarse mientras los clientes existentes del servidor dejan de recibir respuestas sin hacer ruido. Dos colisiones producen ambos resultados: un grupo de túneles que ya está en uso y una ruta predeterminada instalada por la mitad cliente nueva que cubre toda la tabla. Ninguna de las dos genera un mensaje de error de OpenVPN, por eso el fallo se lee como un problema del servidor.

Una máquina, dos roles y dos respuestas incompatibles sobre adónde deben ir las respuestas.

Mismo grupo, dos servidores: cuál gana

Cada instancia de servidor necesita su propia subred de túnel. Copiar una línea como server 10.8.0.0 255.255.255.0 en la segunda configuración da a las dos instancias el mismo prefijo, y el resultado es o bien una negativa a arrancar o bien una competición silenciosa en la que los clientes de un servidor reciben direcciones que el otro también cree suyas. Los puertos UDP distintos y los nombres de dispositivo distintos no ayudan, porque ninguno de los dos toca el espacio de direcciones. Cambie el segundo grupo y cámbielo en todos los sitios donde las rutas lo mencionan.

Enumere qué está activo antes de editar: ip -4 addr show lista los dispositivos de túnel, ss -lunp lista los oyentes y systemctl list-units nombra las unidades. Un vistazo a las direcciones del túnel decide si los grupos chocan.

Qué añade el perfil de cliente a la tabla

La mitad cliente escribe rutas en cuanto se conecta. redirect-gateway def1 parte la ruta predeterminada en 0.0.0.0/1 más 128.0.0.0/1, ambas enrutadas por el dispositivo nuevo, junto con una ruta de host al servidor remoto que está deliberadamente fijada a la interfaz física. Esa fijación existe para que el túnel conserve un camino para su propio transporte. Todo lo demás, incluidas las respuestas que el servidor local debe a sus propios clientes, sigue ahora la nueva ruta predeterminada y sale por el enlace remoto.

Así que la segunda colisión no es un túnel roto. Es un túnel que funciona en el lugar equivocado de la tabla.

Tres formas de mantener los roles separados

La corrección menos invasiva mantiene la ruta predeterminada fuera del perfil de cliente: route-nopull más líneas route explícitas para los prefijos remotos, de modo que la tabla local solo cambie donde usted lo pidió. El paso siguiente es una regla de política que exima la subred de túnel local, dejando que las respuestas a los clientes locales salgan por la interfaz por la que llegaron incluso cuando existe una ruta predeterminada. La más completa es un espacio de nombres de red aparte para el rol de cliente, que elimina del todo la tabla compartida y cuesta un segundo contexto de enrutamiento que mantener.

Sea cual sea el camino que tome, la excepción debe nombrar la subred de túnel local y no la LAN. La respuesta que envía el servidor local tiene como destino una dirección de túnel, así que una excepción con forma de LAN nunca coincide con ella.

Cuál de las dos instancias tiene la culpa

Detenga la instancia cliente y vuelva a probar los clientes originales. Una recuperación inmediata significa enrutamiento, no servidor. Vuelva a levantar el cliente y rastree una sola respuesta con ip route get al que se le dan tanto una dirección de origen como de destino, lo que muestra el camino que elegiría el núcleo, y luego observe la interfaz que los paquetes usan de verdad con tcpdump -ni any port 1194. El archivo de estado del servidor, escrito cada pocos segundos mediante la directiva status, contiene la lista de clientes conectados y contadores de bytes en ambos sentidos.

Lea esos contadores unos contra otros. El tráfico que sale y nunca vuelve es una respuesta de enrutamiento, no un problema de handshake.