Dúas VLAN necesitan saídas VPN distintas, e a primeira pregunta non é que política escribir senón que dispositivo responde á pasarela predeterminada. Se un conmutador encamiña entre as VLAN, unha regra de devasa pode describir un camiño que os paquetes nunca toman. Percorra a topoloxía antes de tocar a política de saída.

Primeiro paso: atope a pasarela que usa cada VLAN

Pregunte a cada cliente pola súa pasarela, e pregunte ao conmutador que interface posúe a VLAN. A pasarela predeterminada determina a primeira decisión de encamiñamento do tráfico que sae da subrede, así que tamén determina que dispositivo pode aplicar unha política.

ip route show default
show ip interface brief

Son habituais dous deseños coherentes. A devasa posúe as interfaces VLAN e encamiña entre elas; ou o conmutador multicapa as posúe e encamiña localmente, enviando só os destinos externos á devasa. Ambos funcionan, e colocan a política en lugares distintos.

Escolla un deliberadamente, porque un deseño mixto é a forma en que as regras acaban no dispositivo equivocado.

Segundo paso: decida onde vive a política local

Se o conmutador encamiña entre o persoal e o laboratorio, unha regra de devasa non pode inspeccionar un intercambio que nunca chega á devasa. A política local debe vivir nos controis de acceso propios do conmutador, ou o tráfico debe dirixirse a propósito por un punto de inspección.

A elección inversa tamén ten un custo. Facer da devasa a pasarela de cada VLAN sitúa o tráfico encamiñado local no plan de capacidade e dispoñibilidade dese equipo, así que reiniciar a devasa convértese nunha interrupción entre VLAN. Avalíe o hardware real en lugar de supoñer que os conmutadores non teñen estado ou que as devasas son lentas. A planificación de capacidade é máis doada cando o dispositivo que reinicia non é tamén a ruta entre dúas subredes ocupadas.

O que importa é se a política escollida está na ruta que os paquetes seguen realmente.

Terceiro paso: dea aos dous dispositivos un único tránsito

Cando o conmutador encamiña, unha soa subrede de tránsito mantén a topoloxía lexible, en lugar de colgar as dúas caixas de cada VLAN de cliente como encamiñadores rivais. O conmutador posúe as subredes de cliente e a devasa posúe o 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

O conmutador envía os destinos externos ao enderezo de tránsito da devasa, e a devasa ten rutas de retorno a ambos os prefixos de cliente a través do conmutador. Manteña intactos o acceso de xestión, a configuración da pasarela DHCP e a pertenza á VLAN durante a migración, porque esas tres cousas son as que converten un cambio limpo nunha tarde cun cable de consola.

Un deseño de tránsito tamén fai que a próxima substitución da devasa sexa un cambio de encamiñamento en lugar dun proxecto de recableado.

Cuarto paso: escolla a saída segundo a orixe que chega

Con encamiñamento ordinario e sen tradución de orixe entre medias, a devasa recibe o enderezo orixinal do persoal ou do laboratorio na interface de tránsito. Ambas as VLAN chegan por unha soa ligazón, e as súas identidades IP sobreviven a iso.

Exprese a elección de VPN con ese enderezo de orixe e os destinos previstos na ruta de entrada real. A documentación de regras de OPNsense distingue unha configuración de pasarela predeterminada, que segue o encamiñamento do sistema, dunha pasarela explícita, que invoca o encamiñamento baseado en políticas. Use a forma explícita cando a elección dependa de onde veu o paquete. Unha ruta predeterminada normal non ten motivo algún para mirar a orixe.

Manteña os destinos locais fóra dunha regra de saída demasiado ampla, e comprobe o modelo de pasarela compatible coa versión que executa.

Quinto paso: demostre ambas as rutas

Escriba o resultado como dúas frases: o tráfico do persoal cara a destinos aprobados sae pola saída A, e o tráfico do laboratorio cara a destinos aprobados sae pola saída B. Engada as rutas de retorno, as regras de tradución e o comportamento previsto cando unha saída está caída.

traceroute -n 198.51.100.10

Despois probe por separado un servizo local entre VLAN, porque exercita unha decisión distinta dentro do mesmo deseño.

Un fluxo novo de cada VLAN, un servizo local que funciona e unha ruta de fallo documentada demostran xuntos o deseño; un só ping correcto demostra unicamente que nese momento existía unha ruta.

Artigos relacionados