IKEv2 fa servir UDP 500 i 4500: quin dels dos transporta les dades?

Obrir l'UDP 500 al tallafoc fa que el túnel negociï, i després la connexió deixa de passar trànsit. La llista de ports era incompleta, no incorrecta. L'IKEv2 comença en un sòcol i, en moltes implantacions reals, continua en un altre, mentre que la càrrega útil pot no ser cap port. Llegir les etapes en ordre explica quina regla falta.

Dos ports, dues feines

L'IKEv2 comença amb un intercanvi de claus a l'UDP 500, on els parells s'autentiquen i estableixen una associació de seguretat per al túnel. El camí de dades que segueix és una altra qüestió: pot ser ESP natiu, que és un número de protocol IP i no un port, o trànsit encapsulat dins d'UDP al 4500. Mantenir-ho separat en una revisió del tallafoc és la diferència entre un túnel que negocia i un túnel que funciona. Un sòcol porta el control i l'altre porta la càrrega.

Per això una regla que només permet el 500 produeix el símptoma més confús de tota la família de protocols: la negociació té èxit i no en segueix res d'útil. L'estat mostra un parell, el registre mostra una IKE SA establerta, i l'aplicació encara expira. El permís que falta pertany a un flux diferent del que acaba de funcionar.

Per què existeix el 4500

Molts dispositius NAT no poden reenviar cap altre protocol que no sigui TCP o UDP, i alguns reescriuen adreces de maneres que trenquen la comprovació d'integritat de l'ESP. Encapsular l'ESP dins d'UDP resol tots dos problemes, a canvi d'una capçalera extra i d'un segon port per permetre. Aquest encapsulament és la raó per la qual el segon port existeix.

Quan es detecta NAT, l'IKE mateix també passa al 4500 perquè tot el trànsit comparteixi un sol camí a través del traductor. Un marcador de quatre bytes que no és ESP distingeix els missatges de control de les dades en aquell sòcol. El canvi és una decisió del protocol, no una preferència de l'administrador.

On canvia el port d'origen

Un traductor pot reescriure el port d'origen del client, de manera que la tupla que veu el servidor no coincideix amb la tupla del client. Mira els dos costats de cada salt NAT abans de concloure que s'ignora una regla. Diagnosticar només al client pot produir una regla que sembla correcta i tot i així falla.

Les implementacions compatibles amb MOBIKE també poden passar al 4500 sense cap NAT detectat, i algunes implantacions forcen aquest camí deliberadament. Veure 4500 és, per tant, evidència d'una decisió, no prova d'un router domèstic.

Comprova els dos fluxos a cada frontera

Recorre les tres fronteres: la xarxa del client, qualsevol tallafoc intermedi i el servidor. Cadascuna necessita els fluxos que documenta la implantació, no els fluxos d'un article sobre un altre cas.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

La línia ESP d'una llista de tallafoc és una coincidència de protocol, així que una regla de port mai la cobreix. Si l'operador fa servir un port personalitzat, segueix la configuració documentada als dos extrems, perquè un client no pot crear un oient al servidor triant un número familiar.

Registra on es va aturar la negociació i si es va instal·lar una associació de seguretat filla, perquè aquest parell separa un camí bloquejat d'un error d'autenticació o de política. Després repeteix la prova amb la verificació del servidor activada, perquè la connectivitat no és autenticació. Aquest últim pas separa un port permès d'un parell de confiança.