Primero la puerta de enlace de la VLAN, después la decisión de salida de la VPN

Dos VLAN necesitan salidas VPN distintas, y la primera pregunta no es qué política escribir sino qué dispositivo responde a la puerta de enlace predeterminada. Si un conmutador enruta entre las VLAN, una regla de cortafuegos puede describir una ruta que los paquetes nunca toman. Recorra la topología antes de tocar la política de salida.

Primer paso: encuentre la puerta de enlace que usa cada VLAN

Pregunte a cada cliente por su puerta de enlace y pregunte al conmutador qué interfaz posee la VLAN. La puerta de enlace predeterminada determina la primera decisión de enrutamiento del tráfico que sale de la subred, así que también determina qué dispositivo puede aplicar una política.

ip route show default
show ip interface brief

Son habituales dos diseños coherentes. El cortafuegos posee las interfaces VLAN y enruta entre ellas; o el conmutador multicapa las posee y enruta localmente, enviando solo los destinos externos al cortafuegos. Ambos funcionan y colocan la política en lugares distintos.

Elija uno a propósito, porque un diseño mixto es la forma en que las reglas acaban en el dispositivo equivocado.

Segundo paso: decida dónde vive la política local

Si el conmutador enruta entre el personal y el laboratorio, una regla de cortafuegos no puede inspeccionar un intercambio que nunca llega al cortafuegos. La política local debe vivir en los controles de acceso propios del conmutador, o el tráfico debe dirigirse a propósito por un punto de inspección.

La elección inversa también tiene un coste. Hacer del cortafuegos la puerta de enlace de cada VLAN sitúa el tráfico enrutado local en el plan de capacidad y disponibilidad de ese equipo, así que reiniciar el cortafuegos se convierte en una interrupción entre VLAN. Evalúe el hardware real en lugar de suponer que los conmutadores no tienen estado o que los cortafuegos son lentos. La planificación de capacidad es más fácil cuando el dispositivo que reinicia no es también la ruta entre dos subredes ocupadas.

Lo que importa es si la política elegida está en la ruta que los paquetes siguen realmente.

Tercer paso: dé a los dos dispositivos un solo tránsito

Cuando el conmutador enruta, una sola subred de tránsito mantiene la topología legible, en lugar de colgar las dos cajas de cada VLAN de cliente como enrutadores rivales. El conmutador posee las subredes de cliente y el cortafuegos posee el exterior.

# on the switch
ip route 0.0.0.0/0 10.255.0.2
# on the firewall
ip route add 10.20.10.0/24 via 10.255.0.1
ip route add 10.20.20.0/24 via 10.255.0.1

El conmutador envía los destinos externos a la dirección de tránsito del cortafuegos, y el cortafuegos tiene rutas de retorno a ambos prefijos de cliente a través del conmutador. Mantenga intactos el acceso de gestión, la configuración de puerta de enlace DHCP y la pertenencia a la VLAN durante la migración, porque esas tres cosas son las que convierten un cambio limpio en una tarde con un cable de consola.

Un diseño de tránsito también hace que la próxima sustitución del cortafuegos sea un cambio de enrutamiento en lugar de un proyecto de recableado.

Cuarto paso: elija la salida según el origen que llega

Con enrutamiento ordinario y sin traducción de origen entre medias, el cortafuegos recibe la dirección original del personal o del laboratorio en la interfaz de tránsito. Ambas VLAN llegan por un solo enlace, y sus identidades IP lo sobreviven.

Exprese la elección de VPN con esa dirección de origen y los destinos previstos en la ruta de entrada real. La documentación de reglas de OPNsense distingue una configuración de puerta de enlace predeterminada, que sigue el enrutamiento del sistema, de una puerta de enlace explícita, que invoca el enrutamiento basado en políticas. Use la forma explícita cuando la elección dependa de dónde vino el paquete. Una ruta predeterminada normal no tiene motivo alguno para mirar el origen.

Mantenga los destinos locales fuera de una regla de salida demasiado amplia, y compruebe el modelo de puerta de enlace compatible con la versión que ejecuta.

Quinto paso: demuestre ambas rutas

Escriba el resultado como dos frases: el tráfico del personal hacia destinos aprobados sale por la salida A, y el tráfico del laboratorio hacia destinos aprobados sale por la salida B. Añada las rutas de retorno, las reglas de traducción y el comportamiento previsto cuando una salida está caída.

traceroute -n 198.51.100.10

Después pruebe por separado un servicio local entre VLAN, porque ejercita una decisión distinta dentro del mismo diseño.

Un flujo nuevo de cada VLAN, un servicio local que funciona y una ruta de fallo documentada demuestran juntos el diseño; un solo ping correcto demuestra únicamente que en ese momento existía una ruta.