Un concentrador OpenVPN, tres LAN: plan de direcciones y archivos iroute

Tres LAN privadas pueden encontrarse en un solo concentrador sin que ningún sitio conozca el interior de los demás, y todo el diseño se apoya en cuatro decisiones breves de configuración. Lo que lo hace funcionar no es una característica exótica del protocolo, sino un plan de direcciones que nadie tiene que adivinar, más rutas por cliente que dicen al concentrador qué sucursal posee cada prefijo. Equivócate en cualquiera de las dos y el túnel seguirá levantándose, que es justo lo que vuelve confuso el fallo.

Recorre los pasos en orden. Cada uno depende del plan del paso anterior, y ninguno requiere una autoridad de certificación nueva.

Empieza con un plan que nadie tenga que adivinar

Anota cuatro prefijos disjuntos antes de tocar un archivo de configuración: la LAN propia del concentrador, la LAN de cada sucursal y el grupo que se entrega a los clientes itinerantes. La disyunción es lo que mantiene simple todo lo demás, porque los rangos solapados convierten el enrutamiento en un rompecabezas de coincidencia más larga que ninguna configuración por cliente repara. Después confirma qué máquina es la puerta de enlace predeterminada de cada LAN, porque un router de sucursal que no es la puerta de enlace de su LAN necesita las rutas remotas instaladas en otro lugar por completo. Por último, fija los nombres autenticados que identifican cada sucursal, porque esos nombres son las claves con las que se buscan los archivos por cliente.

Un plan ilustrativo mantiene el grupo bien lejos de las tres LAN. El tuyo será distinto, y la única regla estricta es que no se solapen dos rangos.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Dile al núcleo del concentrador dónde están las sucursales

El concentrador necesita dos datos por sucursal: una ruta en el núcleo que envíe el prefijo al dispositivo de túnel, y una iroute entrada que diga al OpenVPN proceso qué cliente la posee. La ruta del núcleo por sí sola entrega los paquetes al túnel y se detiene ahí, porque el demonio todavía tiene que decidir qué par debe recibirlos. La entrada iroute por sí sola deja esos paquetes en el núcleo sin una ruta que seguir. Ambas líneas pertenecen a la configuración que el demonio carga realmente, algo que conviene verificar antes de depurar cualquier otra cosa.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Desactiva cliente-a-cliente cuando se supone que el núcleo es el punto de aplicación. Esa opción retransmite el tráfico entre pares dentro del demonio, lo que es cómodo y también significa que tus reglas de reenvío nunca ven el flujo. Todo lo que sigue asume que el núcleo ve cada paquete entre sucursales.

Da a cada sucursal las rutas que necesita

Cada sucursal necesita rutas hacia las otras sucursales y hacia la LAN del concentrador, y no necesita una para su propia LAN conectada. Empuja los prefijos remotos desde el concentrador en lugar de pegarlos en cada router, de modo que un cuarto sitio después signifique un archivo nuevo por cliente en vez de cuatro ediciones. El archivo por cliente también lleva la línea iroute, que mantiene la propiedad y el anuncio en el mismo lugar. Haz que el directorio y sus archivos sean legibles según el modelo de privilegios del servidor, o la búsqueda falla sin mensaje.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Un cuarto sitio sigue el mismo patrón: un nombre autenticado distinto, un prefijo propio, una ruta en el núcleo del concentrador, una iroute entrada y anuncios solo a los sitios a los que se permite llegar a él.

Prueba en ambos sentidos antes de darlo por terminado

Activa el reenvío IPv4 en los tres routers y luego confirma que el cortafuegos permite los flujos previstos en ambos sentidos, porque una prueba unidireccional pasa con una ruta de retorno rota más a menudo de lo que nadie espera. Entre sitios no hace falta traducción de origen, y preservar el origen original es lo que permite a cada sucursal aplicar su propia política a una petición.

Prueba desde un equipo de la LAN de una sucursal hasta un servicio de otra, luego invierte el sentido y después prueba desde una sucursal hasta la LAN del concentrador. Esos tres resultados son pruebas distintas y ninguno implica los otros. Si un router de sucursal no es la puerta de enlace predeterminada de su LAN, instala los prefijos remotos en la puerta de enlace real e incluye también el grupo cuando los clientes del túnel deban iniciar conexiones hacia esa LAN.

Registra el plan, los archivos por cliente y las reglas del cortafuegos como un solo documento, porque la próxima incorporación de sitio se juzgará contra ellos.

El diseño se sostiene porque cada capa tiene una tarea: el plan mantiene los prefijos únicos, la ruta del núcleo mueve paquetes, la iroute nombra al propietario y el cortafuegos decide qué se permite. Cuando algo se rompe, esa lista es también el orden en que hay que revisarlo.