strongSwan ESP-in-UDP: når der ikke er nogen NAT at opdage

NAT-detektion besvarer ét spørgsmål: er adresserne eller portene ændret undervejs? Den besvarer ikke, om en firewall tillader IP-protokol 50. Site-gateways uden nogen oversættelse kan stadig ligge bag en politik, der dropper native ESP, og det krav skal konfigureres frem for at blive opdaget. Mekanismen er ESP-in-UDP, og det er en beslutning frem for en reserve, der dukker op af sig selv.

Detektion er aritmetik på adresser, ikke en firewall-scanning

IKEv2 bærer NAT-detektionsnyttelaster med hashes af kilde- og destinationsadresserne og -portene. Hver side sammenligner det modtagne med det, den ser lokalt, og en uoverensstemmelse fortæller den, at noget har oversat pakken. Intet i den udveksling tester, om en router i midten videresender protokol 50.

Den praktiske konsekvens er værd at sige ligeud. En tunnel, der virkede med native ESP, opdager ikke selv en ny restriktiv firewall, og dens næste forsøg fejler i datastadiet, mens IKE fortsætter med at lykkes. Du vil se etablerede IKE-sikkerhedsassociationer og ingen beskyttet trafik, hvilket ligner en routingfejl, indtil du fanger på kablet.

Indkapsling er derfor en egenskab ved den forbindelse, du konfigurerer, ikke et resultat, parterne forhandler ud fra nettets adfærd.

Hvordan encap ændrer udvekslingen

I en moderne strongSwan-installation, der styres via swanctl.conf påvirker indstillingen encap = yes på forbindelsen NAT-detektionsudvekslingen, så begge parter bruger UDP-indkapsling til ESP. De beskyttede pakker rejser derefter inde i UDP, typisk på port 4500, og begge ender skal enes om den ordning.

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

Det uddrag hører inde i en rigtig forbindelsesdefinition og er ikke en fuld site-profil. Behold de peer-adresser, godkendelse og child-trafikvælgere, du allerede kører; den eneste tilføjede nøgle ændrer, hvordan de beskyttede data pakkes ind, ikke hvad de beskytter.

Vejledningen strongSwan om NAT-traversal beskriver denne adfærd, herunder samspillet med port floating, når MOBIKE bruges.

Brug den indstilling, der hører til dit backend

strongSwan har to konfigurationsbackends, og nøglen er forskellig mellem dem. En swanctl.conf forbindelse tager encap, mens en ældre ipsec.conf forbindelse tager forceencaps. At putte den ene backends nøgleord i den anden giver en konfiguration, der indlæses uden klager og ikke ændrer noget, hvilket er værre end en fejl.

Kontroller, hvilken daemon der faktisk kører, før du redigerer noget. På mange distributioner findes begge filer, fordi den ene er en rest fra en tidligere migrering, og den aktive er den, serviceenheden starter. Læs den enhed i stedet for at gætte ud fra filens tidsstempler. En fem sekunders kontrol her forhindrer timer med test af en indstilling, som intet har indlæst.

Anvend ændringen via forbindelsens ejer, og genopret associationen i et kontrolleret vindue. Et allerede installeret child beholder sin nuværende indkapsling, indtil det erstattes, så en filredigering alene beviser ikke, at den nye ordning er i brug.

Verificér de indpakkede data, ikke kun porten

Fang på gatewayen, mens beskyttet trafik flyder, og sammenlign det derefter med strongSwans eget billede:

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

Native ESP vises som IP-protokol 50 og ligner slet ikke UDP. Indpakket ESP vises som UDP-datagrammer på 4500, hvis nyttelast ikke er IKE. IKE-trafik på samme port er ikke bevis på indkapsling, fordi MOBIKE kan flytte IKE derhen, mens datastien forbliver native, så læs nyttelasten i stedet for portnummeret.

Husk også stiens MTU. Indpakningen tilføjer overhead, og en sti, der bar native ESP, kan kræve justeringer, når pakkerne vokser. Nødvendig ICMP-håndtering bør allerede være en del af designet; indkapsling fjerner ikke den afhængighed.

Accepter ændringen, når ny applikationstrafik inde i tunnelen ses i optagelsen som indpakket ESP i begge ender, og når den indre tjeneste og dens returrute stadig virker. Alt mindre er en konfiguration, der ser rigtig ud i en fil.