Dous clientes detrás do mesmo router falan cunha soa pasarela IPsec, e un non deixa de caer mentres o outro se mantén. O ESP nativo é o protocolo IP 50 sen portos, así que un tradutor non ten onde ancorar unha asignación cando varios clientes comparten un enderezo. O tránsito por NAT pecha esa fenda envolvendo o ESP en UDP no 4500, e esa cabeceira explica a maioría dos síntomas que seguen. Tamén sinala o dispositivo que hai que cambiar.

Por que o plano de datos se traslada ao porto 4500

Durante a configuración, IKEv2 compara os enderezos e os portos que cada lado cre usar, intercambiando hashes nas súas notificacións de detección de NAT. Cando os hashes non coinciden, hai un tradutor nalgún punto da ruta, e ambos os pares cambian o tráfico protexido a encapsulación UDP. Por iso unha sesión que se atopou cun tradutor vese distinta dunha que non.

O envoltorio é un sobre, non un cambio de protocolo: O ESP conserva a súa cabeceira, a súa comprobación de integridade e o seu cifrado, e UDP só achega os portos que o tradutor necesita. O porto 500 leva o intercambio IKE; o 4500 leva os datos encapsulados tras a detección, e a miúdo tamén as mensaxes IKE posteriores. Ningún dos dous portos converte o fluxo nunha conexión TCP, unha suposición que engana a maioría de quen le unha captura.

Comprobe as dúas etapas en orde

Demostre primeiro o intercambio de control, logo a ruta de datos, e manteña ambos separados nas súas notas. Unha captura que mostra tráfico no 500 e nunca no 4500 adoita significar que a ruta de datos está filtrada, así que a corrección corresponde á regra da devasa e non ao cliente.

Vixíe ambos os portos con tcpdump -ni any 'udp port 500 or udp port 4500', e lea a táboa de tradución do router mentres a sesión está activa. Esa táboa mostra o porto de orixe que a pasarela verá realmente, e unha captura no portátil discrepa por deseño: o portátil cre 500 mentres a pasarela ve 4500 cun porto de orixe traducido, e ambos teñen razón. O mesmo fluxo, antes e despois da tradución:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

Síntomas que explica o envoltorio, e dous que non

Un router que permite o intercambio de control e bloquea os datos encapsulados produce o informe de que o túnel está levantado pero non pasa nada. As táboas de asignación caducan, así que unha sesión inactiva necesita tráfico de mantemento que os pares envían a propósito, e eses paquetes non son comprobacións de estado. Cando varios clientes detrás dunha pasarela fallan á vez, examine a tradución desa pasarela e calquera función antiga de paso directo. O envoltorio non explica unha aplicación que falla en todos os clientes tras levantar o túnel, nin un aviso de certificado nunha páxina de bloqueo; ambos viven por riba desta capa.

Lea a táboa de asignación para dous clientes á vez: se ambos mostran o mesmo porto traducido, o dispositivo non os separa como esixe a pasarela. Un modo de paso directo que entrega o ESP nativo a un só equipo non equivale a servir varios clientes traducidos, aínda que os fabricantes describan ambos como compatibles con IPsec. O NAT dobre engade unha capa de asignación e outro punto de caducidade, pero non rompe automaticamente as conexións saíntes.

O tráfico de mantemento merece a súa propia liña no manual de operacións, porque é o que mantén aberta a ruta de resposta durante os períodos de inactividade. Actíveo onde o fabricante o documenta, e compróbeo primeiro cando unha sesión morre tras minutos de silencio en lugar de no primeiro uso.

Cambie o propietario da asignación e volva probar

Siga os axustes de tránsito por NAT admitidos en ambos os pares en lugar de adiviñar un porto. Editar o porto de orixe local nun cliente non pode cambiar o servizo que escoita no outro extremo, e normalmente rompe a asignación xa construída. Se o cliente está detrás dun dispositivo que vostede non controla, o cambio corresponde ao seu propietario.

Tras calquera cambio, repita ambas as comprobacións de etapa e confirme que un paquete de datos atravesa, non só que a pantalla de estado se puxo verde. Garde as tuplas, a saída da táboa de asignación e o cambio de regra nunha soa nota, para que a seguinte persoa non comece de novo desde o intercambio de control. As notas de strongSwan sobre o tránsito por NAT cobren os axustes de encapsulación e de mantemento tras ambas as etapas.

Artigos relacionados