¿Enrutar los clientes de OpenVPN a través de Cloudflare? Compruebe primero el rol
Un cliente de dispositivo no es un enrutador. Confirme que el rol de Cloudflare reenvía paquetes de otros hosts y mantenga el túnel propio del servidor en su ruta antigua.
Tiene un servidor OpenVPN en funcionamiento y un host que también ejecuta el software de dispositivo de Cloudflare, y el siguiente paso obvio parece dirigir el tráfico de los clientes hacia él. Dos conexiones en funcionamiento en una máquina no suman una puerta de enlace de tránsito. Lo que falta es un rol documentado para reenviar paquetes que pertenecen a otra persona, y una política que clasifique esos paquetes cuando llegan.
Antes de cualquier regla hay cuatro preguntas: qué tráfico entra, adónde va después, cómo encuentran el camino de vuelta las respuestas y qué hace el diseño cuando falla ese segundo camino. Las dos primeras son preguntas de capacidad.
Dos servicios en un mismo host no son un camino de tránsito
Un cliente de dispositivo está hecho para manejar el tráfico que se origina en la máquina donde se ejecuta. Intercepta la resolución de nombres, o el tráfico de aplicaciones seleccionado, y lo envía por su propio túnel, y su política está escrita para el usuario de ese dispositivo y los procesos de ese dispositivo. Un paquete reenviado desde un cliente OpenVPN no es salida local, así que las mismas reglas no lo clasifican. Eso no es un detalle de configuración que pueda taparse con una regla más amplia, porque decide si el software ve el paquete siquiera.
Por eso la pregunta de diseño es una pregunta de capacidad. O el producto instalado tiene un rol documentado que reenvía tráfico para otras redes, o la función de tránsito pertenece a otro lugar por completo.
Qué rol de Cloudflare puede reenviar
El cliente de dispositivo de Cloudflare ofrece modos que difieren en alcance: solo resolución de nombres, tráfico del dispositivo y a veces ambos. Ninguno de esos modos convierte al host en un enrutador para un rango privado que llega por otro túnel. El rol de enrutamiento dedicado es un producto aparte con su propio conector, registro y modelo de red.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
Compruebe el rol instalado antes de diseñar rutas a su alrededor. Lea qué interfaz crea el conector, si anuncia prefijos concretos o una ruta predeterminada, y si la política local se aplica a los paquetes reenviados igual que a los locales. Si solo se maneja tráfico local, el servidor OpenVPN no puede ser el punto de tránsito por mucho que se escriba la regla de traducción.
Aquí también hay que formular con precisión el requisito de salida pública. Una salida proporcionada por Cloudflare para el tráfico de clientes reenviado es un caso de uso concreto, y hay que confirmarlo contra el servicio que realmente tiene.
Mantenga el túnel exterior independiente de la nueva ruta
En el momento en que añade una ruta predeterminada hacia la nueva interfaz, el tráfico saliente propio del servidor empieza a competir por ella, y eso incluye las respuestas a los clientes OpenVPN y su sesión SSH a la máquina. El síntoma habitual es un túnel que se establece y luego muere, o un administrador bloqueado fuera mientras parece que el cambio ha funcionado. Compare ip route get para el punto final antes y después, y use enrutamiento por políticas o una ruta al host para mantener el transporte propio del servidor donde estaba. Ejecute esa comparación desde la propia máquina, porque la visión del servidor sobre su propia ruta es la que importa.
Una excepción para la dirección pública del servidor no basta por sí sola, porque el camino de vuelta de cada administrador remoto es un flujo distinto. Decida cuáles de esos flujos deben sobrevivir al cambio y luego verifique cada uno en lugar de suponer que el primero cubre al resto.
Limite el reenvío y la traducción a un solo flujo
Los paquetes recibidos siguen el camino de reenvío, no el de salida local, así que la regla que importa vive en el hook forward. Donde la interfaz siguiente necesita traducción, limite el origen al grupo de clientes, el destino a lo permitido y la salida a esa única interfaz. Una regla masquerade ligada solo a una interfaz no elige ninguna ruta por sí misma y no permite reenviar más allá de ningún otro filtro.
Decida el comportamiento de cierre ante fallos de antemano y luego pruébelo. Detenga el camino siguiente y confirme que los clientes pierden la salida prevista en lugar de volver en silencio al enlace ascendente habitual, porque ese es el resultado que nadie nota hasta que el tráfico sale por la puerta equivocada. Repita la comprobación para la resolución de nombres y para IPv6, porque un conjunto de reglas solo para v4 deja un camino v6 abierto.
Anote las cuatro respuestas con las que se quedó y la observación que demuestra cada una. Un camino de tránsito que puede describir es uno que puede defender en la próxima revisión de incidentes.