strongSwan ESP-in-UDP: quan no hi ha cap NAT per detectar

La detecció de NAT respon una pregunta: han canviat les adreces o els ports en trànsit? No respon si un tallafoc permet el protocol IP 50. Les passarel·les de lloc sense cap traducció poden estar igualment darrere d'una política que descarta l'ESP natiu, i aquest requisit s'ha de configurar en lloc de descobrir-se. El mecanisme és ESP-in-UDP, i és una decisió, no un recurs alternatiu que aparegui sol.

La detecció és aritmètica sobre adreces, no una sonda del tallafoc

IKEv2 porta càrregues útils de detecció de NAT amb hashes de les adreces i els ports d'origen i destinació. Cada costat compara el que ha rebut amb el que veu localment, i una discrepància li diu que alguna cosa ha traduït el paquet. Res d'aquest intercanvi no comprova si un encaminador intermedi reenvia el protocol 50.

Val la pena dir la conseqüència pràctica sense embuts. Un túnel que funcionava amb ESP natiu no descobrirà per si sol un tallafoc nou més restrictiu, i el seu intent següent falla a l'etapa de dades mentre IKE continua tenint èxit. Veureu associacions de seguretat IKE establertes i cap trànsit protegit, cosa que sembla una fallada d'encaminament fins que capturau a la xarxa.

L'encapsulació és, per tant, una propietat de la connexió que configureu, no un resultat que els parells negociïn a partir del comportament de la xarxa.

Com canvia l'encap l'intercanvi

En un desplegament modern de strongSwan gestionat mitjançant swanctl.conf, l'opció encap = yes a la connexió influeix en l'intercanvi de detecció de NAT perquè tots dos parells facin servir encapsulació UDP per a ESP. Els paquets protegits viatgen llavors dins d'UDP, convencionalment al port 4500, i tots dos extrems s'han de posar d'acord sobre aquesta disposició.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Aquest fragment pertany dins d'una definició de connexió real i no és un perfil de lloc complet. Mantingueu les adreces dels parells, l'autenticació i els selectors de trànsit child que ja feu servir; l'única clau afegida canvia com s'embolcalla la informació protegida, no què protegeix.

La guia de strongSwan sobre NAT-traversal descriu aquest comportament, inclosa la interacció amb el port flotant quan s'utilitza MOBIKE.

Feu servir l'opció que correspon al vostre backend

strongSwan té dos backends de configuració, i la clau difereix entre ells. Una swanctl.conf connexió pren encap, mentre que una ipsec.conf connexió heretada pren forceencaps. Posar la paraula clau d'un backend a l'altre produeix una configuració que es carrega sense queixes i no canvia res, cosa pitjor que un error.

Comproveu quin dimoni s'executa realment abans d'editar res. En moltes distribucions tots dos fitxers existeixen perquè un és una resta d'una migració anterior, i l'actiu és el que arrenca la unitat de servei. Llegiu aquesta unitat en lloc d'endevinar-ho per les marques de temps dels fitxers. Una comprovació de cinc segons aquí evita hores de proves d'una opció que res no ha carregat.

Apliqueu el canvi a través del propietari de la connexió i restabliu l'associació durant una finestra controlada. Un child ja instal·lat conserva la seva encapsulació actual fins que es reemplaça, així que editar el fitxer no demostra per si sol que la nova disposició estigui en ús.

Verifiqueu les dades embolcallades, no només el port

Captureu a la passarel·la mentre circula trànsit protegit i compareu-ho amb la visió pròpia de strongSwan:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

L'ESP natiu apareix com a protocol IP 50 i no s'assembla gens a UDP. L'ESP embolcallat apareix com a datagrames UDP al 4500 la càrrega útil dels quals no és IKE. El trànsit IKE en aquest mateix port no és prova d'encapsulació, perquè MOBIKE pot moure IKE allà mentre el camí de dades continua sent natiu, així que llegiu la càrrega útil, no el número de port.

Tingueu en compte també l'MTU del camí. L'embolcall afegeix sobrecost, i un camí que portava ESP natiu pot necessitar ajustos quan els paquets creixin. La gestió d'ICMP necessària ja hauria de formar part del disseny; l'encapsulació no elimina aquesta dependència.

Accepteu el canvi quan el trànsit nou d'aplicacions dins del túnel sigui visible a la captura com a ESP embolcallat als dos extrems, i quan el servei intern i la seva ruta de retorn encara funcionin. Qualsevol cosa menys és una configuració que sembla correcta en un fitxer.