Com el traversal NAT embolcalla l'ESP dins d'UDP

Dos clients darrere del mateix encaminador parlen amb una sola passarel·la IPsec, i un no para de caure mentre l'altre es manté. L'ESP nadiu és el protocol IP 50 sense ports, així que un traductor no té res on basar una assignació quan diversos clients comparteixen una adreça. El traversal NAT tanca aquesta escletxa embolcallant l'ESP en UDP al 4500, i aquesta capçalera explica la majoria dels símptomes que segueixen. També assenyala el dispositiu que cal canviar.

Per què el pla de dades es mou al port 4500

Durant la configuració, l'IKEv2 compara les adreces i els ports que cada costat creu que utilitza, intercanviant resums en les seves notificacions de detecció de NAT. Quan els resums no coincideixen, hi ha un traductor en algun punt del camí, i tots dos iguals passen el trànsit protegit a encapsulació UDP. Per això una sessió que s'ha trobat amb un traductor es veu diferent d'una que no.

L'embolcall és un sobre, no un canvi de protocol: L'ESP conserva la seva capçalera, la comprovació d'integritat i el xifratge, i l'UDP només proporciona els ports que el traductor necessita. El port 500 porta l'intercanvi IKE; el 4500 porta les dades encapsulades després de la detecció, i sovint també els missatges IKE posteriors. Cap dels dos ports no converteix el flux en una connexió TCP, una suposició que enganya la majoria de la gent que llegeix una captura.

Comproveu les dues etapes per ordre

Demostreu primer l'intercanvi de control, després el camí de dades, i manteniu els dos separats a les notes. Una captura que mostra trànsit al 500 i mai al 4500 normalment vol dir que el camí de dades està filtrat, així que la solució és a la regla del tallafoc i no al client.

Vigileu tots dos ports amb tcpdump -ni any 'udp port 500 or udp port 4500', i llegiu la taula de traducció de l'encaminador mentre la sessió és viva. Aquesta taula mostra el port d'origen que la passarel·la veurà realment, i una captura a l'ordinador portàtil no hi coincideix per disseny: el portàtil creu que és 500 mentre la passarel·la veu 4500 amb un port d'origen traduït, i tots dos tenen raó. El mateix flux, abans i després de la traducció:

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

Símptomes que l'embolcall explica, i dos que no

Un encaminador que permet l'intercanvi de control i bloqueja les dades encapsulades produeix l'informe que el túnel està aixecat però no hi passa res. Les taules d'assignació caduquen, així que una sessió inactiva necessita trànsit de manteniment que els iguals envien a propòsit, i aquests paquets no són comprovacions de salut. Quan diversos clients darrere d'una passarel·la fallen alhora, examineu la traducció d'aquella passarel·la i qualsevol funció antiga de pas directe. L'embolcall no explica una aplicació que falla a tots els clients després d'aixecar el túnel, ni un avís de certificat en una pàgina de bloqueig; tots dos són per sobre d'aquesta capa.

Llegiu la taula d'assignació per a dos clients alhora: si tots dos mostren el mateix port traduït, el dispositiu no els separa com la passarel·la requereix. Un mode de pas directe que lliura l'ESP nadiu a un sol amfitrió no equival a servir diversos clients traduïts, encara que els fabricants descriguin tots dos com a compatibles amb IPsec. El NAT doble afegeix una capa d'assignació i un altre punt de caducitat, però no trenca automàticament les connexions sortints.

El trànsit de manteniment mereix una línia pròpia al manual d'operacions, perquè és el que manté obert el camí de resposta durant els períodes d'inactivitat. Activeu-lo on el fabricant ho documenta, i comproveu-lo primer quan una sessió mor després de minuts de silenci en lloc de la primera vegada.

Canvieu el propietari de l'assignació i torneu a provar

Seguiu la configuració de traversal NAT suportada als dos iguals en lloc d'endevinar un port. Editar el port d'origen local en un client no pot canviar el servei que escolta a l'altre extrem, i normalment trenca l'assignació ja creada. Si el client és darrere d'un dispositiu que no controleu, el canvi correspon al seu propietari.

Després de qualsevol canvi, repetiu les dues comprovacions d'etapa i confirmeu que un paquet de dades travessa, no només que la pantalla d'estat s'ha posat verda. Manteniu les tuples, la sortida de la taula d'assignació i el canvi de regla en una sola nota, perquè la següent persona no comenci de nou des de l'intercanvi de control. Les notes de strongSwan sobre el traversal NAT cobreixen la configuració d'encapsulació i de manteniment darrere de les dues etapes.