Prefijo público por OpenVPN: arreglar el camino de vuelta

Observe cómo sube el túnel y el cliente hace ping al otro lado, y luego una dirección pública que pertenece detrás de la VPN responde desde otro sitio, o no responde. Ese síntoma normalmente no tiene nada que ver con el cifrado ni con los certificados. Un prefijo enrutado por el proveedor se entrega como una ruta IP, y llevarlo por OpenVPN significa reproducir esa ruta en dos niveles y preservar la dirección de origen en el camino de vuelta. No hace falta puentear la WAN, y añadir la dirección a una interfaz no crea la ruta ascendente.

El prefijo primero tiene que enrutarse hacia usted

Pregunte al proveedor cómo se entrega el bloque. Un prefijo enrutado a la dirección principal de su servidor es algo distinto de las direcciones que el proveedor espera alcanzar directamente en un segmento WAN. Solo el primer modelo funciona con el diseño de aquí.

Si el proveedor enruta 198.51.100.64/28 a su servidor de entrada, los paquetes de ese rango llegan al servidor y se detienen allí a menos que los reenvíe. Si el proveedor, en cambio, puentea el rango hacia su enlace ascendente, el servidor debe responder ARP por él, que es otro problema.

Pruebe el modelo de entrega antes de tocar OpenVPN: desde fuera, haga ping a una dirección del bloque y observe qué interfaz la recibe. Si no llega nada, ninguna configuración del túnel ayudará. Si la dirección responde directamente en la WAN, el proveedor está puenteando en lugar de enrutar, y el diseño de abajo no se aplica.

Dos niveles de enrutamiento: ruta del núcleo e iroute

OpenVPN necesita el prefijo en dos sitios. El núcleo debe saber que el prefijo pertenece al dispositivo del túnel, para que los paquetes reenviados entren en OpenVPN en lugar de la ruta por defecto. OpenVPN también debe saber qué cliente autenticado posee el prefijo, que es la entrada iroute en el directorio específico del cliente.

La ruta del lado del servidor tiene este aspecto, con el prefijo y la máscara coincidiendo con la asignación:

ip route add 198.51.100.64/28 dev tun0

La configuración específica del cliente asigna la propiedad. Póngala en el archivo CCD nombrado según el nombre común del certificado del cliente, y confirme que ese directorio es el que el servidor lee realmente:

iroute 198.51.100.64 255.255.255.240

La documentación de OpenVPN sobre redes enrutadas describe ambos niveles y por qué están separados. Una ruta del núcleo sin iroute envía paquetes al túnel sin propietario, y OpenVPN los descarta. Un iroute sin la ruta del núcleo deja los paquetes en la ruta por defecto del servidor. Ambos errores parecen un túnel roto desde el lado del cliente.

Dónde vive la dirección del servicio

El prefijo delegado no es lo mismo que las direcciones propias del túnel. Numere el enlace desde el espacio privado si quiere, y coloque la dirección pública del servicio donde el servicio se ejecuta realmente.

En un cliente Linux que termina el servicio localmente, basta una dirección de host individual:

ip address add 198.51.100.70/32 dev lo

Si el prefijo se enruta hacia un host VM u otra LAN, configure en su lugar ese camino descendente y su ruta de vuelta. Asignar cada dirección del bloque al cliente VPN no es necesario y crea conflictos después.

Mantenga el origen público en el camino de vuelta

Una respuesta del prefijo delegado debe salir por el túnel y llegar a la ruta del proveedor. Si el host remoto la envía por su propio ISP, la dirección de origen parece falsificada, y el proveedor o el destino la descartan. La solución es una regla basada en el origen o una tabla de enrutamiento dedicada, no un NAT más amplio. Sin ella, el servicio funciona desde el par del túnel y falla desde cualquier otro sitio.

En el servidor de entrada, una regla de masquerade amplia es el culpable habitual. Reescribe el origen público a la dirección principal del servidor, y el cliente nunca ve la real:

iptables -t nat -S POSTROUTING

Limite el NAT a los clientes VPN privados que lo necesitan y deje el prefijo delegado sin traducir. Luego confirme que el servidor reenvía el prefijo, porque una cadena de reenvío con denegación por defecto lo descarta en silencio.

Verifique ambas direcciones antes de confiar en él

La verificación son cuatro observaciones, no una. Confirme que llega la ruta del proveedor, que el núcleo envía el prefijo al túnel, que OpenVPN lo atribuye al cliente correcto y que la respuesta vuelve con el origen público intacto. Cada observación tiene su propio comando, así que un fallo apunta a una capa y no a todo el diseño. Ejecútelas en ese orden después de cada cambio de configuración.

Pregunte al núcleo qué camino toma una dirección delegada, y observe el túnel mientras se ejecuta una petición:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

El filtrado de ruta inversa puede deshacer una ruta correcta. Compruebe el ajuste efectivo en el túnel y en el enlace ascendente, y recuerde que el modo estricto rechaza el tráfico cuyo origen no coincide con la interfaz por la que llegó:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Por último, pruebe el caso de fallo. Detenga el túnel y confirme que el prefijo público no se filtra por el enlace ascendente ordinario. Restaurar la VPN debería devolver el servicio sin ampliar qué puertos expone el host.