Encaminhe uma sub-rede de filial pela saída de Internet do SonicWall da matriz

Os telefones da filial devem sair pela matriz enquanto os notebooks da filial continuam usando o WAN local, e a política de roteamento sozinha não fará isso. Uma rota da filial pode selecionar o túnel, mas a política do túnel precisa aceitar o tráfego, a matriz precisa encaminhá-lo e traduzi-lo, e a resposta precisa voltar pelo mesmo caminho. Se qualquer um dos três faltar, o sintoma será um subconjunto de clientes que perdem Internet exatamente enquanto o túnel está ativo.

Comece pelo seletor, não pela rota

A política de roteamento corresponde a uma origem, então a origem precisa ser estável antes de tudo. Coloque os dispositivos escolhidos em um grupo de endereços mantido por um administrador ou, melhor, em um segmento dedicado cuja associação siga a função do dispositivo. Quando a troca normal de DHCP pode mover um endereço correspondente para outra máquina, a política escolhe silenciosamente o cliente errado, e o primeiro relato geralmente é sobre navegação lenta que na verdade é um desvio.

Nomeie o grupo pela política que ele serve, não por um andar ou departamento, porque a regra de roteamento sobreviverá aos dois. Registre quais dispositivos estão nele e quem pode adicionar um.

Adicione a política da filial e depois defenda sua ordem

No SonicWall da filial, uma política de rota seleciona o grupo de origem, nomeia os destinos pretendidos e define a interface do túnel como gateway, que é exatamente para isso que existe o projeto de interface de túnel suportado. Mantenha as regras de destinos locais e privados acima da regra ampla de Internet, porque a primeira correspondência vence e um prefixo privado empurrado para o túnel chega à matriz apenas para ser descartado. Preserve também a rota do próprio firewall para seu par VPN, ou o transporte do túnel seguirá a política da qual depende. Nada disso obriga você a converter cada túnel existente baseado em política; uma interface de túnel é uma opção suportada entre várias.

A ordem é a parte que muda por acidente. Quem adiciona uma exceção precisa inseri-la acima da regra ampla, e quem edita a regra ampla pode inverter todo o projeto com um único salvamento. Escreva a ordem pretendida ao lado da política e verifique novamente após atualizações de firmware, porque a nomenclatura de interfaces e a renderização de políticas realmente mudam entre versões.

Conclua o caminho na matriz

A política do túnel na matriz precisa aceitar o tráfego que a rota da filial agora seleciona. Um seletor interescritórios limitado à LAN privada da matriz não é permissão para transportar destinos públicos arbitrários, então a política precisa da origem da filial e da faixa de destinos que você realmente pretende. A matriz então encaminha esse tráfego de entrada para seu uplink de Internet segundo suas próprias regras de acesso, e o exemplo de saída central da SonicWall inclui tradução de origem para a rede remota no WAN central. Sem essa tradução, o lado remoto vê um endereço privado da filial e não tem rota de volta.

As respostas são a outra metade do contrato. Elas precisam voltar pelo túnel ou pela tradução com estado criada para elas, e o tráfego para sites privados pode exigir tratamento NAT diferente do de saída pública. Mantenha essas regras distinguíveis, porque uma regra de tradução ampla que oculta cada origem interna torna o registro e a solução de problemas posteriores muito mais difíceis de ler.

Decida o que o grupo faz quando o túnel cai

Se a saída central é um requisito e não uma preferência, voltar ao WAN local é uma falha de conformidade mesmo que os usuários permaneçam online. O SonicOS documenta uma rota de descarte da interface do túnel como a forma suportada de impedir que o tráfego selecionado tome um caminho alternativo não intencional.

Ajuste o escopo e a prioridade dessa rota à versão instalada, e teste-a derrubando o túnel em vez de confiar no rótulo. Um grupo que nunca deve sair localmente deveria falhar fechado, enquanto um grupo em que a disponibilidade importa mais pode recuar legitimamente; ambos são decisões, e nenhuma deveria acontecer por padrão.

Verifique a partir de três clientes e então reverta com limpeza

Um ping para o gateway central testa a coisa errada, porque parte do firewall e não de um cliente selecionado. Teste a partir dos dispositivos, e teste três deles: um dispositivo selecionado, um dispositivo comum que deve permanecer local e um que depende de serviços locais.

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

Compare onde a solicitação pública realmente apareceu. Um cliente selecionado deve alcançar a Internet pela saída da matriz, e um cliente comum deve continuar apresentando o endereço próprio da filial no lado remoto; 203.0.113.10 é um endereço de documentação usado como substituto do destino que lhe importa. Inclua DNS na mesma passagem, porque um cliente que consulta o resolvedor da filial pode produzir uma consulta originada no roteador com outra origem e, portanto, outra rota.

A reversão é a ordem de políticas salva mais o grupo de endereços. Restaure a ordem anterior, remova o grupo da política e teste novamente as duas classes de dispositivos. Guarde a configuração exportada com o registro da mudança, porque o próximo engenheiro precisa saber qual regra era a ampla antes de alguém editá-la.