strongSwan ESP-in-UDP: keď niet čo detegovať pomocou NAT

Detekcia NAT odpovedá na jednu otázku: zmenili sa adresy alebo porty cestou? Neodpovedá na to, či firewall povoľuje IP protokol 50. Brány lokalít bez akéhokoľvek prekladu môžu stále stáť za politikou, ktorá zahadzuje native ESP, a túto požiadavku treba nakonfigurovať, nie objaviť. Mechanizmom je ESP-in-UDP a je to rozhodnutie, nie záložná možnosť, ktorá sa objaví sama.

Detekcia je aritmetika na adresách, nie sonda firewallu

IKEv2 nesie užitočné zaťaženia detekcie NAT s hašmi adries a portov zdroja a cieľa. Každá strana porovnáva to, čo prijala, s tým, čo vidí lokálne, a nezhoda jej hovorí, že niečo paket preložilo. Nič v tejto výmene netestuje, či router uprostred preposiela protokol 50.

Praktický dôsledok stojí za to povedať priamo. Tunel, ktorý fungoval s native ESP, sám neobjaví nový obmedzujúci firewall a jeho ďalší pokus zlyhá v dátovej fáze, zatiaľ čo IKE ďalej uspeje. Uvidíte zavedené IKE bezpečnostné asociácie a žiadnu chránenú premávku, čo vyzerá ako chyba smerovania, kým nezachytíte premávku na drôte.

Zapuzdrenie je teda vlastnosťou pripojenia, ktoré konfigurujete, nie výsledkom, o ktorom sa strany dohodnú z správania siete.

Ako encap mení výmenu

V modernom nasadení strongSwan spravovanom cez swanctl.conf, nastavenie encap = yes na pripojení ovplyvňuje výmenu detekcie NAT tak, že obe strany používajú UDP zapuzdrenie pre ESP. Chránené pakety potom cestujú vnútri UDP, zvyčajne na porte 4500, a oba konce sa musia na tomto usporiadaní zhodnúť.

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

Tento fragment patrí dovnútra skutočnej definície pripojenia a nie je úplným profilom lokality. Ponechajte adresy partnera, autentifikáciu a selektory premávky child, ktoré už používate; jediný pridaný kľúč mení, ako sa chránené údaje zabalujú, nie čo chránia.

Príručka strongSwan pre NAT-traversal opisuje toto správanie vrátane interakcie s plávajúcim portom pri použití MOBIKE.

Použite nastavenie, ktoré patrí vášmu backendu

strongSwan má dva konfiguračné backendy a kľúč sa medzi nimi líši. swanctl.conf pripojenie preberá encap, zatiaľ čo staršie ipsec.conf pripojenie preberá forceencaps. Vloženie kľúčového slova jedného backendu do druhého vytvorí konfiguráciu, ktorá sa načíta bez sťažnosti a nič nezmení, čo je horšie ako chyba.

Pred akoukoľvek úpravou skontrolujte, ktorý démon skutočne beží. V mnohých distribúciách existujú oba súbory, pretože jeden je pozostatok skoršej migrácie, a aktívny je ten, ktorý spúšťa servisná jednotka. Čítajte tú jednotku, namiesto hádania z časových značiek súborov. Päťsekundová kontrola tu zabráni hodinám testovania nastavenia, ktoré nič nenačítalo.

Zmenu aplikujte prostredníctvom vlastníka pripojenia a asociáciu obnovte v riadenom okne. Už nainštalovaný child si zachováva súčasné zapuzdrenie, kým nie je nahradený, takže samotná úprava súboru nedokazuje, že nové usporiadanie je v používaní.

Overte zabalené údaje, nielen port

Zachyťte premávku na bráne, kým tečie chránená premávka, potom to porovnajte s vlastným pohľadom strongSwan:

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

Native ESP sa objavuje ako IP protokol 50 a vôbec nepodobá sa na UDP. Zabalené ESP sa objavuje ako UDP datagramy na 4500, ktorých užitočné zaťaženie nie je IKE. IKE premávka na tom istom porte nie je dôkazom zapuzdrenia, pretože MOBIKE tam môže presunúť IKE, zatiaľ čo dátová cesta zostáva native, takže čítajte užitočné zaťaženie, nie číslo portu.

Majte na pamäti aj MTU cesty. Obal pridáva réžiu a cesta, ktorá niesla native ESP, môže vyžadovať úpravy, keď pakety rastú. Potrebné spracovanie ICMP by už malo byť súčasťou návrhu; zapuzdrenie túto závislosť neodstraňuje.

Zmenu prijmite, keď je čerstvá aplikačná premávka vnútri tunela viditeľná v zachytení ako zabalené ESP na oboch koncoch a keď vnútorná služba a jej spätná trasa stále fungujú. Čokoľvek menej je konfigurácia, ktorá v súbore vyzerá správne.