Que pacote uma política VPN de dupla WAN precisa de corresponder?

Os pedidos para encaminhar a VPN pelo segundo uplink descrevem pelo menos duas tarefas diferentes, e a política que corrige uma não toca na outra. Na primeira tarefa, o transporte cifrado entre dois extremos passa para outro endereço WAN. Na segunda, o fluxo de aplicação decifrado de um utilizador ligado sai para outro salto seguinte. Ambas são legítimas, ambas usam encaminhamento e cada uma precisa de uma correspondência num pacote que exista no ponto onde a decisão é tomada. Percorra as verificações abaixo por ordem, porque a primeira determina que pacote as regras seguintes devem nomear.

Nomeie as duas conversas

Imagine um trabalhador remoto ligado a um gateway de escritório, que abre HTTPS para um servidor de aplicações interno. Há duas conversas independentes no fio, e têm endereços diferentes em cada extremo. A conversa exterior corre entre os dois extremos da VPN: do endereço do gateway ao endereço do par, com o protocolo e a porta que a implementação negociou. A conversa interior corre do endereço atribuído ao cliente até ao endereço do servidor de aplicações na porta 443.

A porta de destino da aplicação não é a porta de transporte da VPN, e nenhuma quantidade de política em TCP 443 moverá o túnel. Do mesmo modo, uma regra que redireciona o endereço de transporte do par não diz nada sobre para onde vai o pedido HTTP desse utilizador após a decifragem. Anote as duas conversas com os seus endereços reais antes de tocar numa regra, porque a maior parte da confusão nesta área vem de nomear uma e configurar a outra.

Descubra onde a sua política consegue realmente ver o pacote

A correspondência tem de ser avaliada na cadeia e no espaço de nomes onde o pacote ainda está na forma que descreveu. Uma regra ligada à entrada de LAN vê o pacote interior, sem cifra, antes de ser encaminhado para o túnel. Uma regra aplicada ao tráfego gerado localmente vê os pacotes que o próprio gateway gera, e não cobre automaticamente o tráfego que o gateway apenas reencaminha. A saída encapsulada é ainda um terceiro caso, normalmente tratado na interface que transporta o túnel e não do lado da LAN.

É por isso que o mesmo fragmento de configuração se comporta de forma diferente em duas plataformas: os pontos de ligação são diferentes, e o gancho de política de um fornecedor pode ficar antes ou depois do passo de cifra. Leia o caminho do pacote para o produto concreto em vez de assumir a ordem a partir do diagrama de outro fornecedor.

Confirme o transporte que negociou

Para IPsec encapsulado em UDP, RFC 3948 coloca ESP dentro de UDP e usa um marcador que não é ESP para manter o IKE distinguível na porta partilhada. O ESP simples é um protocolo IP, não uma porta TCP ou UDP, por isso uma regra de firewall escrita contra um número de porta não o fará corresponder de todo. Esta distinção decide se a sua política WAN precisa de uma regra UDP, de uma regra de protocolo ou de ambas.

Os valores negociados vencem os memorizados. Leia as portas e endereços atuais da associação a partir do equipamento em vez de acrescentar TCP 4500 ou uma porta antiga do fornecedor por precaução, o que captura tráfego não relacionado e esconde o problema real de classificação.

Verifique o caminho de retorno antes de se comprometer

O sucesso de saída prova metade de um projeto. Um pacote que regressa para o conjunto de clientes remotos deixa de ser visível sob o endereço do cliente quando a encapsulagem o substitui: o destino exterior é o endereço de transporte do par. Se o segundo uplink chegar a esse par através de outro operador, a sua tradução e filtragem podem discordar da primeira, e a associação pode precisar de ser reconstruída em vez de migrada.

O estado de tradução de endereços de rede é a vítima habitual de uma mudança de WAN. Registe o uplink escolhido, o endereço de origem exterior esperado, a tradução em uso e a acessibilidade do par de volta para ele, e depois mantenha o transporte acessível sem o enviar para o túnel que transporta.

Verifique ambas as camadas com duas capturas

Uma captura na interface WAN e outra dentro do túnel resolvem a questão mais depressa do que qualquer comparação de configuração. Execute-as a partir do gateway enquanto um cliente aprovado faz um único pedido, e guarde ambos os ficheiros.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

A primeira captura deve mostrar a conversa exterior a sair da interface que pretendia, com o endereço de origem esperado. A segunda deve mostrar a conversa interior uma vez, não duplicada, com o endereço do cliente como origem e o servidor de aplicações como destino. A consulta de rota confirma que tabela o router usaria para esse par origem e destino, e é aí que um erro de política costuma aparecer. Se qualquer das capturas não aparecer, o ponto de decisão está noutro local e não onde a regra foi ligada, e a correção pertence a esse local e não a uma correspondência mais ampla.