strongSwan ESP-in-UDP: ko ni nobenega NAT za zaznavanje

Zaznavanje NAT odkrije prevajanje naslovov, ne politike požarnega zidu. Povezava lokacije brez NAT lahko še vedno zahteva izrecno izbiro ESP-in-UDP.

Zaznavanje NAT odgovarja na eno vprašanje: so se naslovi ali vrata na poti spremenili? Ne odgovarja, ali požarni zid dovoljuje IP protokol 50. Prehodi lokacij brez kakršnega koli prevajanja so lahko še vedno za politiko, ki zavrže native ESP, in to zahtevo je treba konfigurirati, ne odkriti. Mehanizem je ESP-in-UDP in to je odločitev, ne rezervna možnost, ki se pojavi sama.

Zaznavanje je aritmetika na naslovih, ne sondiranje požarnega zidu

IKEv2 nosi koristne obremenitve zaznavanja NAT s zgoščenkami naslovov in vrat vira ter cilja. Vsaka stran primerja prejeto s tem, kar vidi lokalno, in neskladje ji pove, da je nekaj prevedlo paket. Nič v tej izmenjavi ne preizkusi, ali usmerjevalnik v sredini posreduje protokol 50.

Praktično posledico velja povedati naravnost. Predor, ki je deloval z native ESP, sam ne bo odkril novega omejitvenega požarnega zidu, in njegov naslednji poskus spodleti v podatkovni fazi, medtem ko IKE še naprej uspeva. Videli boste vzpostavljene varnostne povezave IKE in nobenega zaščitenega prometa, kar je videti kot napaka pri usmerjanju, dokler ne zajamete na žici.

Inkapsulacija je torej lastnost povezave, ki jo konfigurirate, ne rezultat, o katerem se strani dogovorita iz vedenja omrežja.

Kako encap spremeni izmenjavo

V sodobni namestitvi strongSwan, ki se upravlja prek swanctl.conf, nastavitev encap = yes na povezavi vpliva na izmenjavo zaznavanja NAT, tako da obe strani uporabljata UDP inkapsulacijo za ESP. Zaščiteni paketi nato potujejo znotraj UDP, običajno na vratih 4500, in oba konca se morata dogovoriti o tej ureditvi.

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

Ta odlomek spada v pravo definicijo povezave in ni popoln profil lokacije. Ohranite naslove partnerja, preverjanje pristnosti in izbiralnike prometa child, ki jih že izvajate; edini dodani ključ spremeni, kako so zaščiteni podatki oviti, ne tega, kaj ščitijo.

Vodnik strongSwan za NAT-traversal opisuje to vedenje, vključno z interakcijo s plavajočimi vrati, ko se uporablja MOBIKE.

Uporabite nastavitev, ki pripada vašemu backendu

strongSwan ima dva konfiguracijska backenda in ključ se med njima razlikuje. swanctl.conf povezava sprejme encap, medtem ko starejša ipsec.conf povezava sprejme forceencaps. Če ključno besedo enega backenda vstavite v drugega, dobite konfiguracijo, ki se naloži brez pritožbe in ničesar ne spremeni, kar je slabše od napake.

Preden karkoli uredite, preverite, kateri demon v resnici teče. V mnogih distribucijah obstajata obe datoteki, ker je ena ostanek prejšnje selitve, in dejavna je tista, ki jo zažene storitvena enota. Berite to enoto, namesto da bi ugibali iz časovnih žigov datotek. Petsekundno preverjanje tukaj prihrani ure preizkušanja nastavitve, ki je ni naložilo nič.

Spremembo uporabite prek lastnika povezave in povezavo ponovno vzpostavite v nadzorovanem oknu. Že nameščeni child obdrži trenutno inkapsulacijo, dokler ni zamenjan, zato sama sprememba datoteke ne dokazuje, da je nova ureditev v uporabi.

Preverite ovite podatke, ne samo vrat

Zajemite na prehodu, medtem ko teče zaščiten promet, nato to primerjajte z lastnim pogledom strongSwan:

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

Native ESP se pojavi kot IP protokol 50 in nič ne spominja na UDP. Oviti ESP se pojavi kot UDP datagrami na 4500, katerih koristna obremenitev ni IKE. Promet IKE na istih vratih ni dokaz inkapsulacije, ker lahko MOBIKE premakne IKE tja, medtem ko podatkovna pot ostane native, zato berite obremenitev, ne številke vrat.

Upoštevajte tudi MTU poti. Ovoj doda dodatne stroške in pot, ki je nosila native ESP, bo morda potrebovala prilagoditve, ko paketi rastejo. Potrebno obravnavanje ICMP bi moralo biti že del zasnove; inkapsulacija te odvisnosti ne odpravi.

Spremembo sprejmite, ko je svež aplikacijski promet v predoru viden v zajemu kot ovit ESP na obeh koncih in ko notranja storitev in njena povratna pot še delujeta. Karkoli manj je konfiguracija, ki je v datoteki videti pravilna.

Sorodni članki