Cómo limitar el acceso entre dos oficinas conectadas por VPN

Un túnel de sitio a sitio responde una pregunta, si las dos oficinas pueden intercambiar paquetes, y deja abierta la importante: qué dispositivo de la sucursal puede llegar a qué servicio central. Tratar el túnel como confianza mutua es la forma en que un portátil de invitado acaba en la misma ruta que el servidor financiero. La solución no es un túnel mejor, sino una lista de permisos explícita aplicada tras el descifrado. Este manual lleva esa lista de la definición a una denegación probada.

Trabaje en este orden y no amplíe la ruta del túnel hasta que pasen los pasos de política siguientes.

Escriba la matriz antes de tocar la pasarela

Una fila útil nombra tres cosas: un grupo de origen, un host o red de servicio de destino, y el protocolo y el puerto que la aplicación usa realmente. La sucursal y el centro de datos no son entradas. El DNS privado y los servicios de autenticación merecen filas propias solo cuando la aplicación no puede funcionar sin ellos.

Agrupe los orígenes por rol y no por comodidad de subred: personal, invitados, administración. Cuando los tres comparten una LAN plana, la pasarela no puede distinguirlos en la capa de red, así que los controles de identidad o la segmentación deben ir primero. Después ponga la matriz por escrito con un responsable y una fecha de revisión en cada fila.

Aplíquelo donde se descifran los paquetes

Las reglas que permiten IKE y ESP solo construyen el túnel exterior. El tráfico interior llega en claro a la interfaz del túnel, y ahí es donde va la lista de permisos: una cadena de reenvío en el dispositivo que descifra, descarte predeterminado, una regla por fila de la matriz. En pasarelas Linux eso significa reenvío habilitado y reglas de filtrado en el dispositivo del túnel, no en el enlace físico, como explica la guía de reenvío de strongSwan.

Los selectores de tráfico son una decisión de enrutamiento, no de autorización. Un selector amplio que cubre ambas subredes puede ser correcto para el enrutamiento mientras el cortafuegos sigue permitiendo solo TCP 443 hacia un host. El selector se negocia para el túnel y describe qué puede entrar en él, no qué puede usar un dispositivo concreto. Nunca amplíe una regla de cortafuegos porque el selector sea amplio.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT y subredes superpuestas cambian las reglas

Cuando la pasarela de la sucursal traduce cada host a una sola dirección antes del túnel, cada fila basada en el origen colapsa en esa única dirección. O deje de traducir el tráfico del túnel, o acepte que las reglas deben apoyarse en otra cosa, como la dirección de origen original registrada antes de la traducción. El extremo remoto tiene el mismo problema, porque el host de destino ve la dirección posterior al NAT y no la original.

Los rangos superpuestos son la otra trampa. Dos oficinas que usan ambas 192.168.1.0/24 no se pueden describir en una sola tabla de política sin mapear un lado, y un mapeo no sustituye un direccionamiento que no colisiona. Corrija el plan antes de escribir reglas que tendrá que deshacer después.

Demuestre una denegación, no solo un éxito

Probar solo la aplicación permitida demuestra muy poco, porque una regla permisiva en algún punto anterior produce el mismo resultado.

Desde un dispositivo corriente de la sucursal, llegue al servicio previsto y confirme que toda la sesión funciona. Luego pruebe un destino que debe permanecer cerrado, como un puerto administrativo en un servidor con el que la sucursal no tiene nada que ver, y lea el contador o la entrada de registro que lo descartó. Desactivar el conjunto de reglas para comprobar si funciona invalida la prueba y deja la pasarela abierta mientras mira.

Mantenga viva la lista

Las aplicaciones se mueven, y una regla que sobrevive a su aplicación se convierte en un agujero que nadie posee. Ate la fecha de revisión a la fila y cambie el alcance del selector y la regla de cortafuegos en el mismo paso de mantenimiento cuando un servicio cambie de dirección.

Las restricciones a nivel de host siguen importando detrás del túnel: el cortafuegos propio del servidor debería aceptar el rango de la sucursal solo para el servicio que publica. Dos capas que coinciden son más fáciles de auditar que una sola en la que se confía por completo.