Que paquete debe facer coincidir unha política VPN de dobre WAN?

As peticións de encamiñar a VPN polo segundo enlace describen polo menos dúas tarefas distintas, e a política que arranxa unha non toca a outra. Na primeira tarefa, o transporte cifrado entre dous extremos pasa a outro enderezo WAN. Na segunda, o fluxo de aplicación descifrado dun usuario conectado sae cara a outro salto seguinte. Ambas son lexítimas, ambas usan encamiñamento e cada unha necesita unha coincidencia nun paquete que exista no punto onde se toma a decisión. Percorra as comprobacións de abaixo en orde, porque a primeira determina que paquete deben nomear as regras posteriores.

Nomee as dúas conversas

Imaxine un traballador remoto conectado a unha pasarela de oficina, que abre HTTPS cara a un servidor de aplicacións interno. Hai dúas conversas independentes no cable, e teñen enderezos distintos en cada extremo. A conversa exterior vai entre os dous extremos da VPN: do enderezo da pasarela ao enderezo do par, co protocolo e o porto que negociase o despregamento. A conversa interior vai desde o enderezo asignado ao cliente ata o enderezo do servidor de aplicacións no porto 443.

O porto de destino da aplicación non é o porto de transporte da VPN, e ningunha cantidade de política sobre TCP 443 moverá o túnel. Igualmente, unha regra que redirixe o enderezo de transporte do par non di nada sobre onde vai a petición HTTP dese usuario tras o descifrado. Anote as dúas conversas cos seus enderezos reais antes de tocar unha regra, porque a maior parte da confusión neste terreo vén de nomear unha e configurar a outra.

Atope onde pode ver realmente o paquete a súa política

A coincidencia debe avaliarse na cadea e no espazo de nomes onde o paquete segue tendo a forma que describiu. Unha regra enganchada á entrada de LAN ve o paquete interior, sen cifrar, antes de que se encamiñe cara ao túnel. Unha regra aplicada ao tráfico orixinado localmente ve os paquetes que xera a propia pasarela, e non cobre automaticamente o tráfico que a pasarela só reenvía. A saída encapsulada é outra vez un terceiro caso, normalmente xestionado na interface que leva o túnel e non no lado da LAN.

Por iso o mesmo fragmento de configuración compórtase distinto en dúas plataformas: os puntos de enganche difiren, e o gancho de política dun fabricante pode estar antes ou despois do paso de cifrado. Lea a ruta do paquete para o produto concreto en lugar de supoñer a orde a partir do diagrama doutro fabricante.

Confirme o transporte que negociou

Para IPsec encapsulado en UDP, RFC 3948 coloca ESP dentro de UDP e usa un marcador que non é ESP para manter IKE distinguible no porto compartido. O ESP simple é un protocolo IP, non un porto TCP ou UDP, así que unha regra de cortafuegos escrita contra un número de porto non o fará coincidir en absoluto. Esta distinción decide se a súa política WAN necesita unha regra UDP, unha regra de protocolo ou ambas.

Os valores negociados gañan aos recordados. Lea os portos e enderezos actuais da asociación desde o dispositivo en lugar de engadir TCP 4500 ou un porto antigo do fabricante por se acaso, o que captura tráfico non relacionado e oculta o problema real de clasificación.

Comprobe o camiño de volta antes de comprometerse

O éxito de saída demostra a metade dun deseño. Un paquete que volve cara ao conxunto de clientes remotos xa non é visible baixo o enderezo do cliente cando a encapsulación a substitúe: o destino exterior é o enderezo de transporte do par. Se o segundo enlace chega a ese par por un operador distinto, a súa tradución e filtrado poden discrepar do primeiro, e a asociación podería necesitar reconstruírse en lugar de migrarse.

O estado de tradución de enderezos de rede é a vítima habitual dun cambio de WAN. Anote o enlace elixido, o enderezo de orixe exterior esperado, a tradución en uso e a accesibilidade do par de volta cara a ela, e despois manteña o transporte accesible sen envialo dentro do túnel que transporta.

Verifique ambas as capas con dúas capturas

Unha captura na interface WAN e outra dentro do túnel resolven a cuestión máis rápido que calquera comparación de configuración. Execúteas desde a pasarela mentres un cliente aprobado fai unha soa petición, e garde 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 debería mostrar a conversa exterior saíndo da interface que pretendía, co enderezo de orixe esperado. A segunda debería mostrar a conversa interior unha vez, non duplicada, co enderezo do cliente como orixe e o servidor de aplicacións como destino. A consulta de ruta confirma que táboa usaría o encamiñador para ese par orixe e destino, que é onde adoita aparecer un erro de política. Se algunha captura non aparece, o punto de decisión está noutro sitio distinto de onde se enganchou a regra, e a corrección pertence alí e non a unha coincidencia máis ampla.