strongSwan ESP-in-UDP: když není co detekovat pomocí NAT
Detekce NAT odhaluje překlad adres, ne politiku firewallu. Připojení lokality bez NAT může přesto vyžadovat výslovnou volbu ESP-in-UDP.
Detekce NAT odpovídá na jednu otázku: změnily se adresy nebo porty cestou? Neodpovídá na to, zda firewall povoluje IP protokol 50. Brány lokalit bez jakéhokoli překladu mohou stále stát za politikou, která zahazuje native ESP, a tento požadavek je třeba nakonfigurovat, nikoli objevit. Mechanismem je ESP-in-UDP a je to rozhodnutí, nikoli záložní možnost, která se objeví sama.
Detekce je aritmetika na adresách, ne sonda firewallu
IKEv2 nese užitečná zatížení detekce NAT s hashi adres a portů zdroje a cíle. Každá strana porovnává, co přijala, s tím, co vidí lokálně, a neshoda jí říká, že něco paket přeložilo. Nic v této výměně netestuje, zda router uprostřed předává protokol 50.
Praktický důsledek stojí za to říct přímo. Tunel, který fungoval s native ESP, sám neobjeví nově omezující firewall a jeho další pokus selže ve fázi dat, zatímco IKE dál uspěje. Uvidíte zavedená IKE bezpečnostní přidružení a žádný chráněný provoz, což vypadá jako chyba směrování, dokud nezachytíte provoz na drátě.
Zapouzdření je tedy vlastností připojení, které konfigurujete, ne výsledkem, o němž se strany dohodnou z chování sítě.
Jak encap mění výměnu
V moderním nasazení strongSwan spravovaném přes swanctl.conf, nastavení encap = yes na připojení ovlivňuje výměnu detekce NAT tak, že obě strany používají UDP zapouzdření pro ESP. Chráněné pakety pak cestují uvnitř UDP, obvykle na portu 4500, a oba konce se musí na tomto uspořádání shodnout.
connections {
site {
encap = yes
# existing approved peer, authentication and child settings
}
}
Tento fragment patří dovnitř skutečné definice připojení a není úplným profilem lokality. Ponechte adresy protějšků, autentizaci a selektory provozu child, které už používáte; jediný přidaný klíč mění, jak se chráněná data zabalují, ne co chrání.
Průvodce strongSwan pro NAT-traversal popisuje toto chování včetně interakce s plovoucím portem, když se používá MOBIKE.
Použijte nastavení, které patří vašemu backendu
strongSwan má dva konfigurační backendy a klíč se mezi nimi liší. swanctl.conf připojení přijímá encap, zatímco starší ipsec.conf připojení přijímá forceencaps. Vložení klíčového slova jednoho backendu do druhého vytvoří konfiguraci, která se načte bez stížnosti a nic nezmění, což je horší než chyba.
Než cokoli upravíte, zjistěte, který démon skutečně běží. V mnoha distribucích existují oba soubory, protože jeden je pozůstatek dřívější migrace, a aktivní je ten, který spouští servisní jednotka. Čtěte tu jednotku, místo abyste hádali z časových značek souborů. Zdejší pětisekundová kontrola zabrání hodinám testování nastavení, které nic nenačetlo.
Změnu aplikujte prostřednictvím vlastníka připojení a přidružení obnovte v řízeném okně. Již nainstalovaný child si zachovává současné zapouzdření, dokud není nahrazen, takže samotná úprava souboru nedokazuje, že nové uspořádání je v použití.
Ověřte zabalená data, ne jen port
Zachyťte provoz na bráně, zatímco teče chráněný provoz, a poté to porovnejte s vlastním pohledem strongSwan:
$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list
Native ESP se objevuje jako IP protokol 50 a UDP nepřipomíná vůbec. Zabalené ESP se objevuje jako UDP datagramy na 4500, jejichž užitečné zatížení není IKE. IKE provoz na stejném portu není důkazem zapouzdření, protože MOBIKE tam může přesunout IKE, zatímco datová cesta zůstává native, takže čtěte užitečné zatížení, ne číslo portu.
Mějte na paměti také MTU cesty. Obal přidává režii a cesta, která nesla native ESP, může vyžadovat úpravy, jak pakety rostou. Potřebné zpracování ICMP by už mělo být součástí návrhu; zapouzdření tuto závislost neodstraňuje.
Změnu přijměte, když je čerstvý provoz aplikací uvnitř tunelu viditelný v zachycení jako zabalené ESP na obou koncích a když vnitřní služba a její zpětná trasa stále fungují. Cokoli méně je konfigurace, která vypadá v souboru správně.