strongSwan ESP-in-UDP: när det inte finns någon NAT att upptäcka

NAT-detektering hittar adressöversättning, inte brandväggspolicy. En platsanslutning utan NAT kan ändå behöva ett uttryckligt ESP-in-UDP-val.

NAT-detektering svarar på en fråga: har adresserna eller portarna ändrats under vägen? Den svarar inte på om en brandvägg tillåter IP-protokoll 50. Platsgatewayer helt utan översättning kan fortfarande ligga bakom en policy som släpper native ESP, och det kravet måste konfigureras i stället för att upptäckas. Mekanismen är ESP-in-UDP, och det är ett beslut, inte en reserv som dyker upp av sig själv.

Detektering är aritmetik på adresser, inte en brandväggsundersökning

IKEv2 bär NAT-detekteringsnyttolaster med hashar av käll- och måladresserna och -portarna. Varje sida jämför det den tog emot med det den ser lokalt, och en avvikelse säger till den att något har översatt paketet. Inget i det utbytet testar om en router i mitten vidarebefordrar protokoll 50.

Den praktiska konsekvensen är värd att säga rakt ut. En tunnel som fungerade med native ESP upptäcker inte själv en ny restriktiv brandvägg, och nästa försök misslyckas i datafasen medan IKE fortsätter att lyckas. Du kommer att se etablerade IKE-säkerhetsassociationer och ingen skyddad trafik, vilket ser ut som ett routingfel tills du fångar på kabeln.

Inkapsling är därför en egenskap hos anslutningen du konfigurerar, inte ett resultat som parterna förhandlar fram ur nätets beteende.

Hur encap ändrar utbytet

I en modern strongSwan-installation som hanteras via swanctl.conf, påverkar inställningen encap = yes på anslutningen NAT-detekteringsutbytet så att båda parter använder UDP-inkapsling för ESP. De skyddade paketen färdas sedan inne i UDP, vanligtvis på port 4500, och båda ändarna måste enas om den ordningen.

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

Det fragmentet hör hemma i en riktig anslutningsdefinition och är inte en fullständig platsprofil. Behåll peer-adresserna, autentiseringen och child-trafikväljarna du redan kör; den enda tillagda nyckeln ändrar hur de skyddade uppgifterna packas in, inte vad de skyddar.

Guiden strongSwan om NAT-traversal beskriver detta beteende, inklusive samspelet med port floating när MOBIKE används.

Använd inställningen som hör till din backend

strongSwan har två konfigurationsbackends, och nyckeln skiljer sig mellan dem. En swanctl.conf anslutning tar encap, medan en äldre ipsec.conf anslutning tar forceencaps. Att sätta den ena backendens nyckelord i den andra ger en konfiguration som laddas utan klagomål och inte ändrar något, vilket är värre än ett fel.

Kontrollera vilken daemon som faktiskt körs innan du redigerar något. På många distributioner finns båda filerna eftersom den ena är en rest från en tidigare migrering, och den aktiva är den som tjänsteenheten startar. Läs den enheten i stället för att gissa utifrån filernas tidsstämplar. En kontroll på fem sekunder här sparar timmar av test av en inställning som ingenting har laddat.

Tillämpa ändringen via anslutningens ägare och återupprätta associationen under ett kontrollerat fönster. Ett redan installerat child behåller sin nuvarande inkapsling tills det ersätts, så en filändring ensam bevisar inte att den nya ordningen används.

Verifiera de inkapslade uppgifterna, inte bara porten

Fånga på gatewayen medan skyddad trafik flyter, och jämför det sedan med strongSwans egen bild:

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

Native ESP visas som IP-protokoll 50 och liknar inte alls UDP. Inkapslat ESP visas som UDP-datagram på 4500 vars nyttolast inte är IKE. IKE-trafik på samma port är inte bevis på inkapsling, eftersom MOBIKE kan flytta IKE dit medan datavägen förblir native, så läs nyttolasten, inte portnumret.

Tänk också på banans MTU. Inkapslingen lägger till overhead, och en bana som bar native ESP kan behöva justeringar när paketen växer. Nödvändig ICMP-hantering bör redan vara en del av designen; inkapsling tar inte bort det beroendet.

Acceptera ändringen när ny applikationstrafik inne i tunneln syns i fångsten som inkapslat ESP i båda ändar, och när den inre tjänsten och dess returväg fortfarande fungerar. Allt mindre är en konfiguration som ser rätt ut i en fil.

Relaterade artiklar