strongSwan ESP-in-UDP: kai nėra ko aptikti NAT

NAT aptikimas randa adresų vertimą, o ne ugniasienės politiką. Svetainės ryšys be NAT vis tiek gali reikalauti aiškaus ESP-in-UDP pasirinkimo.

NAT aptikimas atsako į vieną klausimą: ar adresai arba prievadai pasikeitė kelyje? Jis neatsako, ar ugniasienė leidžia IP 50 protokolą. Svetainės tinklų vartai visiškai be vertimo vis tiek gali stovėti už politikos, kuri meta native ESP, ir tas reikalavimas turi būti sukonfigūruotas, o ne atrastas. Mechanizmas yra ESP-in-UDP, ir tai sprendimas, o ne savaime atsirandantis atsarginis variantas.

Aptikimas yra aritmetika adresuose, o ne ugniasienės zondas

IKEv2 neša NAT aptikimo naudingąsias apkrovas su šaltinio ir paskirties adresų bei prievadų maišomis. Kiekviena pusė lygina gautą su tuo, ką mato vietoje, ir neatitikimas jai pasako, kad kažkas paketą išvertė. Niekas tame apsikeitime netikrina, ar maršrutizatorius viduryje persiunčia 50 protokolą.

Praktinę pasekmę verta pasakyti tiesiai. Tunelis, kuris veikė su native ESP, pats neaptiks naujos ribojančios ugniasienės, ir jo kitas bandymas žlugs duomenų etape, kol IKE toliau sėkmingai veiks. Pamatysite sukurtas IKE saugos asociacijas ir jokio apsaugoto srauto, o tai atrodo kaip maršrutizavimo gedimas, kol nesugausite laidu.

Taigi inkapsuliavimas yra jūsų konfigūruojamo ryšio savybė, o ne rezultatas, dėl kurio pusės derasi remdamosi tinklo elgsena.

Kaip encap keičia apsikeitimą

Šiuolaikiniame strongSwan diegime, valdomame per swanctl.conf, ryšio nuostata encap = yes veikia NAT aptikimo apsikeitimą taip, kad abi pusės naudotų UDP inkapsuliavimą ESP. Apsaugoti paketai tada keliauja UDP viduje, paprastai 4500 prievadu, ir abu galai turi sutarti dėl šios tvarkos.

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

Ta ištrauka priklauso tikros ryšio apibrėžties vidui ir nėra visas svetainės profilis. Išsaugokite jau naudojamus partnerio adresus, autentifikavimą ir child srauto parinkiklius; vienintelis pridėtas raktas keičia, kaip apsaugoti duomenys įvyniojami, o ne ką jie saugo.

strongSwan NAT-traversal vadovas aprašo šią elgseną, įskaitant sąveiką su prievado plūduriavimu, kai naudojamas MOBIKE.

Naudokite nuostatą, kuri priklauso jūsų backendui

strongSwan turi du konfigūravimo backendus, ir raktas tarp jų skiriasi. swanctl.conf ryšys priima encap, o senesnis ipsec.conf ryšys priima forceencaps. Vieno backendo raktinį žodį įdėjus į kitą sukuriama konfigūracija, kuri įkeliama be priekaištų ir nieko nekeičia, o tai blogiau nei klaida.

Prieš ką nors redaguodami patikrinkite, kuris tarnybos procesas iš tikrųjų veikia. Daugelyje distribucijų yra abu failai, nes vienas yra ankstesnės migracijos likutis, o aktyvusis yra tas, kurį paleidžia paslaugos padalinys. Skaitykite tą padalinį, o ne spėkite iš failų laiko žymų. Penkių sekundžių patikra čia sutaupo valandas, praleistas bandant nuostatą, kurios niekas neįkėlė.

Taikykite pakeitimą per ryšio savininką ir atkurkite asociaciją kontroliuojamame lange. Jau įdiegtas child išlaiko dabartinį inkapsuliavimą, kol bus pakeistas, todėl vien failo redagavimas neįrodo, kad nauja tvarka naudojama.

Patikrinkite įvyniotus duomenis, ne tik prievadą

Fiksuokite tinklelio vartuose, kol teka apsaugotas srautas, tada palyginkite tai su pačiu strongSwan vaizdu:

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

Native ESP rodomas kaip IP 50 protokolas ir visiškai neprimena UDP. Įvyniotas ESP rodomas kaip UDP datagramos 4500 prievade, kurių naudingoji apkrova nėra IKE. IKE srautas tame pačiame prievade nėra inkapsuliavimo įrodymas, nes MOBIKE gali perkelti IKE ten, kol duomenų kelias lieka native, todėl skaitykite naudingąją apkrovą, o ne prievado numerį.

Turėkite omenyje ir kelio MTU. Apvalkalas prideda papildomų sąnaudų, o kelias, kuriuo buvo nešamas native ESP, gali reikalauti koregavimų, kai paketai didėja. Reikalingas ICMP apdorojimas jau turėtų būti dizaino dalis; inkapsuliavimas nepašalina šios priklausomybės.

Priimkite pakeitimą, kai naujas programų srautas tunelio viduje fiksavime matomas kaip įvyniotas ESP abiejuose galuose ir kai vidinė paslauga bei jos grįžimo kelias vis dar veikia. Bet kas mažiau yra konfigūracija, kuri faile atrodo teisingai.

Susiję straipsniai