Un Pi, dos instancias de OpenVPN: qué lee cada unidad
Dos demonios de OpenVPN en un Pi leen archivos de configuración distintos y salen por ganchos distintos. Mapee cada instancia y luego pruebe la ruta de la carga por separado.
Cuente los procesos OpenVPN antes de tocar un perfil. Un Pi que admite usuarios itinerantes y además marca un servicio ascendente ejecuta dos demonios, y cada uno lee un archivo de configuración elegido por el nombre de instancia que escribió. Luego, las plantillas empaquetadas entregan a cada demonio su propio directorio de trabajo, su propio archivo de estado en tiempo de ejecución y su propio dispositivo de túnel. Si se equivoca en esa división, pasará una noche cambiando un ajuste correcto dentro de un archivo que el proceso en ejecución nunca abre.
Cada nombre de instancia elige su propio archivo
En los archivos de unidad que se distribuyen con OpenVPN 2.6, los argumentos de arranque llevan un marcador de posición de instancia que se rellena con el texto posterior al signo @. La plantilla del servidor se ejecuta desde el directorio de configuración del servidor y resuelve su argumento contra %i.conf allí, mientras que la plantilla del cliente hace lo mismo desde el directorio del cliente. Así, [email protected] lee admits.conf en el directorio del servidor, y [email protected] lee uplink.conf en el directorio del cliente, y ninguno de los dos nombres tiene significado en el otro directorio.
Confirme la asignación en la propia máquina en lugar de suponer que el paquete conservó los valores predeterminados del proyecto original. Un drop-in de la distribución puede reemplazar el directorio de trabajo o el argumento de configuración directamente.
systemctl cat [email protected]
systemctl cat [email protected]Lea la línea WorkingDirectory y el argumento de configuración en esa salida, porque la unidad habilitada es lo único que decide qué archivo se carga. Un drop-in que añade --config a ExecStart gana a la plantilla incluso cuando la ruta de la plantilla parece correcta. Pida las rutas del fragmento y del drop-in cuando quiera saber si hay una anulación local en juego. Si ambos roles se resuelven en un solo archivo, tiene un único proceso que intenta ser servidor y cliente, y la última opción de ese archivo gana en silencio.
El transporte local y la carga reenviada tocan ganchos distintos
La conexión cifrada del servidor con cada usuario itinerante se genera en el propio Pi, así que sus respuestas externas salen por el gancho de salida local. La conexión del cliente con su par ascendente también es salida generada localmente, aunque llega a una red remota. La carga reenviada es una tercera categoría, y el núcleo solo la hace coincidir después de haber elegido ya un dispositivo de salida para el paquete.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
Una regla que coincide con una interfaz de salida dentro de una cadena de reenvío puede permitir o descartar un paquete que el enrutamiento ya asignó a esa interfaz, pero nunca elige la interfaz. Cuando un host termina un túnel y origina otro, la política que envía la carga del usuario al túnel ascendente y la política que protege las respuestas cifradas del propio Pi son decisiones separadas. Casualmente aterrizan en la misma tarjeta de red física, y por eso se confunden.
Esa distinción explica un medio fallo habitual. Los usuarios se conectan, el handshake se completa y su tráfico sigue saliendo por el camino equivocado, porque el handshake era local y la carga era reenviada, y solo se había probado una de las dos cosas.
Una ruta importada puede tragarse las respuestas a sus usuarios
El ajuste de seguridad del perfil del cliente decide qué puede empujar el extremo ascendente a la tabla de enrutamiento del Pi, y una redirección amplia es la opción que convierte un host de doble rol que funciona en uno roto. Si la ruta empujada cubre las direcciones públicas de los usuarios itinerantes, las respuestas que el servidor genera hacia ellos pueden seguir la nueva ruta hacia el túnel ascendente en vez de salir por la capa base. La gente suele confirmar que el túnel hacia el proveedor sigue funcionando y se detiene ahí, porque ese tráfico es el transporte propio del túnel y sigue fluyendo mientras todo lo demás se comporta mal.
La política basada en origen o en marca es la forma de mantener separados los dos flujos. La opción de marca de Linux de OpenVPN marca los paquetes cifrados propios del demonio con una marca de cortafuegos, que una regla de enrutamiento puede enviar luego a una tabla dedicada. Las direcciones de origen funcionan igual de bien cuando las respuestas externas del servidor siempre salen de una única dirección de capa base. Cualquiera de los dos enfoques necesita rutas válidas en la tabla que elige y una excepción para el punto final del proveedor, o el túnel mismo deja de levantarse.
Pregunte al núcleo qué camino tomaría realmente una respuesta antes de escribir cualquier regla. Las direcciones siguientes son marcadores de posición para una dirección de capa base del Pi y la dirección pública de un usuario itinerante.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Verifique la división y luego detenga un rol a la vez
Pruebe tres flujos por separado, porque un handshake que funciona no demuestra nada sobre los otros dos. Acepte una nueva conexión entrante, envíe una aplicación permitida por la salida ascendente y confirme que ambos procesos siguen alcanzando a sus propios pares.
Luego detenga el rol de cliente y observe qué conserva el rol de servidor. Esta es la forma más barata de encontrar una regla de ruta o de marca que estaba pensada para una instancia y se aplicó a ambas.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerLo que quiere ver es el listener todavía vinculado, el dispositivo de túnel todavía presente y el registro libre de errores nuevos mientras el rol de cliente está detenido. Si detener el cliente también corta las respuestas del servidor a los usuarios existentes, los dos roles comparten algo que debería haberse limitado a uno de ellos. Anote qué instancia, qué archivo de configuración y qué propietario de flujo tocó cada cambio, porque la próxima persona que depure este host, si no, repetirá el mismo descubrimiento desde cero.