strongSwan ESP-in-UDP: når det ikke er noen NAT å oppdage

NAT-deteksjon finner adresseoversettelse, ikke brannmurpolicy. En nettstedstilkobling uten NAT kan fortsatt trenge et eksplisitt ESP-in-UDP-valg.

NAT-deteksjon svarer på ett spørsmål: har adressene eller portene endret seg underveis? Den svarer ikke på om en brannmur tillater IP-protokoll 50. Nettstedsgatewayer helt uten oversettelse kan fortsatt ligge bak en policy som dropper native ESP, og det kravet må konfigureres i stedet for å oppdages. Mekanismen er ESP-in-UDP, og det er en beslutning, ikke en reserve som dukker opp av seg selv.

Deteksjon er aritmetikk på adresser, ikke en brannmursondering

IKEv2 bærer NAT-deteksjonsnyttelaster med hasher av kilde- og måladressene og -portene. Hver side sammenligner det den mottok med det den ser lokalt, og et avvik forteller den at noe har oversatt pakken. Ingenting i den utvekslingen tester om en ruter i midten videresender protokoll 50.

Den praktiske konsekvensen er verdt å si rett ut. En tunnel som virket med native ESP, oppdager ikke selv en ny restriktiv brannmur, og neste forsøk feiler i datatrinnet mens IKE fortsetter å lykkes. Du vil se etablerte IKE-sikkerhetsassosiasjoner og ingen beskyttet trafikk, noe som ser ut som en rutingsfeil til du fanger på kabelen.

Innkapsling er derfor en egenskap ved tilkoblingen du konfigurerer, ikke et resultat partene forhandler fram fra nettets oppførsel.

Hvordan encap endrer utvekslingen

I en moderne strongSwan-installasjon som administreres via swanctl.conf, påvirker innstillingen encap = yes på tilkoblingen NAT-deteksjonsutvekslingen slik at begge parter bruker UDP-innkapsling for ESP. De beskyttede pakkene reiser deretter inne i UDP, vanligvis på port 4500, og begge endene må bli enige om den ordningen.

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

Det fragmentet hører hjemme i en ekte tilkoblingsdefinisjon og er ikke en fullstendig nettstedprofil. Behold peer-adressene, autentiseringen og child-trafikkvelgerne du allerede kjører; den eneste tilføyde nøkkelen endrer hvordan de beskyttede dataene pakkes inn, ikke hva de beskytter.

Veiledningen strongSwan om NAT-traversal beskriver denne oppførselen, inkludert samspillet med port floating når MOBIKE brukes.

Bruk innstillingen som hører til backend-en din

strongSwan har to konfigurasjonsbackender, og nøkkelen er forskjellig mellom dem. En swanctl.conf tilkobling tar encap, mens en eldre ipsec.conf tilkobling tar forceencaps. Å putte nøkkelordet fra én backend i den andre gir en konfigurasjon som lastes uten klager og ikke endrer noe, noe som er verre enn en feil.

Sjekk hvilken daemon som faktisk kjører før du redigerer noe. På mange distribusjoner finnes begge filene fordi den ene er en rest fra en tidligere migrering, og den aktive er den tjenesteenheten starter. Les den enheten i stedet for å gjette ut fra filenes tidsstempler. En kontroll på fem sekunder her sparer timer med testing av en innstilling som ingenting har lastet.

Bruk endringen via tilkoblingens eier og gjenopprett assosiasjonen i et kontrollert vindu. Et allerede installert child beholder sin nåværende innkapsling til det erstattes, så en filendring alene beviser ikke at den nye ordningen er i bruk.

Verifiser de innpakkede dataene, ikke bare porten

Fang på gatewayen mens beskyttet trafikk flyter, og sammenlign det deretter med strongSwans eget bilde:

$ 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-protokoll 50 og ligner slett ikke på UDP. Innpakket ESP vises som UDP-datagrammer på 4500 der nyttelasten ikke er IKE. IKE-trafikk på samme port er ikke bevis på innkapsling, fordi MOBIKE kan flytte IKE dit mens datastien forblir native, så les nyttelasten i stedet for portnummeret.

Husk også banens MTU. Innpakningen legger til overhead, og en bane som bar native ESP kan trenge justeringer når pakkene vokser. Nødvendig ICMP-håndtering bør allerede være en del av designet; innkapsling fjerner ikke den avhengigheten.

Godta endringen når ny applikasjonstrafikk inne i tunnelen er synlig i opptaket som innpakket ESP i begge ender, og når den indre tjenesten og returveien fortsatt fungerer. Alt mindre er en konfigurasjon som ser riktig ut i en fil.

Relaterte artikler