Primeiro o gateway da VLAN, depois a decisão de saída da VPN

Duas VLAN precisam de saídas VPN diferentes, e a primeira pergunta não é qual política escrever, mas qual dispositivo responde ao gateway predefinido. Se um switch encaminha entre as VLAN, uma regra de firewall pode descrever um caminho que os pacotes nunca percorrem. Percorra a topologia antes de tocar na política de saída.

Primeiro passo: encontre o gateway que cada VLAN usa

Pergunte a cada cliente qual é o seu gateway e pergunte ao switch qual interface possui a VLAN. O gateway predefinido determina a primeira decisão de encaminhamento do tráfego que sai da sub-rede, por isso também determina qual dispositivo pode aplicar uma política.

ip route show default
show ip interface brief

São comuns duas disposições coerentes. Ou o firewall possui as interfaces VLAN e encaminha entre elas, ou o switch multicamada possui-as e encaminha localmente, enviando apenas os destinos externos para o firewall. Ambas funcionam, e colocam a política em locais diferentes.

Escolha uma deliberadamente, porque uma disposição mista é a forma como as regras acabam no dispositivo errado.

Segundo passo: decida onde vive a política local

Se o switch encaminha entre o pessoal e o laboratório, uma regra de firewall não consegue inspecionar uma troca que nunca chega ao firewall. A política local tem de viver nos controlos de acesso do próprio switch, ou o tráfego tem de ser conduzido de propósito por um ponto de inspeção.

A escolha inversa também tem um custo. Tornar o firewall o gateway de cada VLAN coloca o tráfego encaminhado localmente no plano de capacidade e disponibilidade desse equipamento, pelo que reiniciar o firewall se torna uma interrupção entre VLAN. Avalie o hardware real em vez de assumir que os switches não têm estado ou que os firewalls são lentos. O planeamento de capacidade é mais fácil quando o dispositivo que reinicia não é também o caminho entre duas sub-redes ocupadas.

O que importa é se a política escolhida está no caminho que os pacotes realmente seguem.

Terceiro passo: dê aos dois dispositivos um único trânsito

Quando o switch encaminha, uma única sub-rede de trânsito mantém a topologia legível, em vez de pendurar as duas caixas em cada VLAN de cliente como routers rivais. O switch possui as sub-redes de cliente e o firewall possui 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 switch envia os destinos externos para o endereço de trânsito do firewall, e o firewall tem rotas de retorno para ambos os prefixos de cliente através do switch. Mantenha intactos o acesso de gestão, as definições de gateway DHCP e a pertença à VLAN durante a migração, porque são essas três coisas que transformam uma mudança limpa numa tarde com um cabo de consola.

Um desenho de trânsito também faz da próxima substituição do firewall uma mudança de encaminhamento em vez de um projeto de recablagem.

Quarto passo: escolha a saída pela origem que chega

Com encaminhamento comum e sem tradução de origem pelo meio, o firewall recebe o endereço original do pessoal ou do laboratório na interface de trânsito. Ambas as VLAN chegam por uma única ligação, e as suas identidades IP sobrevivem a isso.

Expresse a escolha da VPN com esse endereço de origem e os destinos previstos no caminho de entrada real. A documentação de regras do OPNsense distingue uma definição de gateway predefinido, que segue o encaminhamento do sistema, de um gateway explícito, que invoca o encaminhamento baseado em políticas. Use a forma explícita quando a escolha depende de onde veio o pacote. Uma rota predefinida normal não tem qualquer razão para olhar para a origem.

Mantenha os destinos locais fora de uma regra de saída demasiado ampla, e verifique o modelo de gateway suportado para a versão que executa.

Quinto passo: prove ambos os caminhos

Escreva o resultado em duas frases: o tráfego do pessoal para destinos aprovados sai pela saída A, e o tráfego do laboratório para destinos aprovados sai pela saída B. Acrescente as rotas de retorno, as regras de tradução e o comportamento pretendido quando uma saída está em baixo.

traceroute -n 198.51.100.10

Depois teste em separado um serviço local entre VLAN, porque exercita uma decisão diferente no mesmo desenho.

Um fluxo novo de cada VLAN, um serviço local funcional e um caminho de falha documentado provam juntos o desenho; um único ping bem-sucedido prova apenas que existia um caminho naquele momento.