Servidor o cliente: qué unidad de OpenVPN en un Pi con doble papel

Dos procesos de OpenVPN se ejecutan en un Pi que a la vez admite usuarios itinerantes y llega a un proveedor superior, y no comparten casi nada salvo el hardware. Uno escucha los túneles entrantes mientras el otro marca hacia fuera. Cada uno lee su propio directorio, y cada uno tiene su propio modo de fallo. Reiniciar el equivocado es la forma más común de que una corrección del cliente acabe sacudiendo al oyente.

Haz coincidir el nombre de la unidad con el directorio que carga

Upstream 2.6 incluye dos unidades de plantilla, [email protected] y [email protected]. La plantilla del servidor arranca en /etc/openvpn/server y carga %i.conf desde allí. La plantilla del cliente arranca en /etc/openvpn/client. Una instancia llamada roaming puede existir en ambos sitios a la vez, como servidor y como cliente, con dos configuraciones sin relación y ningún vínculo entre ellas más allá de la cadena.

Pregunta a systemd en lugar del sistema de archivos, porque los empaquetadores añaden archivos adicionales que pueden cambiar el directorio de trabajo o los argumentos que recibe el binario.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

El primer comando enumera cada unidad instanciada, incluidas las que fallaron y quedaron cargadas. El segundo imprime el archivo de la unidad junto con cualquier sustitución. El tercero es la forma más rápida de ver los dos hechos que deciden la cuestión: el directorio en el que arranca el proceso, y la ruta de configuración que se le entregó.

Decide por la dirección de los paquetes, no por el nombre de la interfaz

Una instancia de servidor posee un socket de escucha y acepta conexiones. Su transporte cifrado es entrada local y salida local en el Pi, mientras que el tráfico que reenvía para los usuarios sigue la ruta de reenvío y responde a otro conjunto de reglas. Una instancia de cliente no tiene oyente en ese sentido: marca hacia un par, así que su transporte cifrado es salida local hacia la capa inferior.

Esa diferencia te dice a dónde pertenece una regla. Una regla que coincide con una interfaz dentro de una cadena de reenvío solo permite el tráfico que el enrutamiento ya seleccionó; nunca selecciona la ruta. Cuando los paquetes de un usuario itinerante salen por el camino equivocado, la cadena que hay que inspeccionar es forward, no output.

Mira los sockets antes de teorizar. Un servidor ligado a udp/1194 muestra un socket de escucha. El cliente muestra una asociación con la dirección del proveedor y nada que escuche.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

La ruta por defecto de una instancia puede capturar las respuestas de la otra

Un redirect-gateway empujado por el cliente superior instala una ruta por defecto que compite con todo lo demás de la máquina, incluida las respuestas que el servidor envía a los usuarios itinerantes. OpenVPN hace una excepción para su propia dirección de par para que el túnel siga siendo alcanzable, pero esa excepción no dice nada sobre un teléfono en una red de hotel.

El síntoma suele ser asimétrico. El handshake se completa, el cliente informa de que está conectado, y el tráfico muere tras el primer paquete de respuesta. El enrutamiento de políticas basado en la fuente, o una marca de paquete puesta en la instancia del servidor con --mark, mantiene los dos flujos separados; ninguna de las dos cosas es un conjunto completo de reglas por sí sola, y ambas necesitan rutas válidas en la tabla que elijan.

Prueba la decisión local en lugar del estado del túnel, porque el núcleo elige la fuente y la interfaz antes de que OpenVPN vea el paquete.

ip route get 203.0.113.44
ip rule show

Reinicia un papel y demuestra que el otro sobrevivió

El orden importa cuando ambos papeles dependen de la misma capa inferior. Reinicia el cliente primero si la ruta superior debe existir antes de que se pueda reenviar el tráfico de los usuarios, y reinicia el servidor primero cuando solo cambias su oyente o su grupo. En cualquier caso, confirma las dos unidades después, porque un reinicio fallido puede dejar el otro papel funcionando con un estado obsoleto.

Escribe la condición de parada antes del cambio: ¿perder el túnel superior bloquea a los usuarios itinerantes o recae en el enlace ascendente propio del Pi? DNS e IPv6 también necesitan una respuesta explícita, porque un resolutor empujado a menudo sobrevive a la ruta que lo hizo útil.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Acepta el cambio solo cuando se cumplan tres cosas a la vez: se completa una nueva conexión entrante, una aplicación reenviada llega a su destino por la salida prevista, y ambos procesos siguen informando de su par esperado. Si una de las tres falla, cambiaste la instancia equivocada o la ruta equivocada, y el siguiente paso es releer la unidad en lugar de reiniciar cualquier otra cosa.