strongSwan ESP-in-UDP: detektatzeko NAT-rik ez dagoenean

NAT detekzioak helbideen itzulpena aurkitzen du, ez suebakiaren politika. NATik gabeko gune-konexio batek ESP-in-UDP aukera esplizitua behar izan dezake oraindik.

NAT detekzioak galdera bati erantzuten dio: aldatu dira helbideak edo portuak bidean? Ez dio erantzuten suebaki batek IP 50 protokoloa baimentzen duen. Itzulpenik gabeko gune-pasabideak politika baten atzean egon daitezke oraindik, native ESP botatzen duena, eta baldintza hori konfiguratu egin behar da, ez aurkitu. Mekanismoa ESP-in-UDP da, eta erabakia da, ez berez agertzen den ordezko aukera.

Detekzioa helbideen gaineko aritmetika da, ez suebaki-proba

IKEv2k NAT detekzio-karga erabilgarriak garraiatzen ditu, iturri eta helmugako helbideen eta portuen hash-ekin. Alde bakoitzak jasotakoa bertan ikusten duenarekin alderatzen du, eta desadostasunak paketea zerbait itzuli duela esaten dio. Truke horretan ezerk ez du probatzen erdiko bideratzaile batek 50 protokoloa birbidaltzen duen.

Merezi du ondorio praktikoa argi esateak. native ESPrekin funtzionatzen zuen tunel batek ez du bere kabuz suebaki murriztaile berri bat aurkituko, eta hurrengo saiakera datu-fasean huts egiten du, IKEk arrakasta izaten jarraitzen duen bitartean. IKE segurtasun-elkarte ezarriak ikusiko dituzu eta babestutako trafikoarik ez, eta hori bideratze-hutsegitea dirudi harian harrapatu arte.

Beraz, kapsulatzea konfiguratzen duzun konexioaren propietatea da, ez sarearen jokabidetik pareek negoziatzen duten emaitza.

Nola aldatzen duen encap-ek trukea

strongSwan hedapen moderno batean, swanctl.conf bidez kudeatua, konexioan encap = yes ezarpenak NAT detekzio-trukean eragiten du, bi pareek ESPrako UDP kapsulatzea erabil dezaten. Babestutako paketeek UDP barruan bidaiatzen dute gero, normalean 4500 portuan, eta bi muturrek akordio hori adostu behar dute.

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

Zati hori benetako konexio-definizio baten barruan doa eta ez da gune-profil osoa. Mantendu jada darabilzun pare-helbideak, autentifikazioa eta child trafiko-hautatzaileak; gehitutako gako bakarrak babestutako datuak nola biltzen diren aldatzen du, ez zer babesten duten.

strongSwanen NAT-traversal gida jokabide hau deskribatzen du, MOBIKE erabiltzean portuaren flotazioarekin duen elkarreragina barne.

Erabili zure backendari dagokion ezarpena

strongSwanek konfigurazio-backend bi ditu, eta gakoa desberdina da haien artean. swanctl.conf konexio batek encap hartzen du, eta zahar batek ipsec.conf konexioak forceencaps hartzen du. Backend baten gako-hitza bestean jartzeak kexarik gabe kargatzen den eta ezer aldatzen ez duen konfigurazioa sortzen du, eta hori errore bat baino okerragoa da.

Egiaztatu zein demono dabilen benetan, ezer editatu aurretik. Banaketa askotan bi fitxategiak existitzen dira, bat aurreko migrazio baten hondarra delako, eta aktiboa zerbitzu-unitateak abiarazten duena da. Irakurri unitate hori, fitxategien denbora-marken arabera asmatu beharrean. Hemen bost segundo egiaztatzeak orduak aurrezten ditu ezer kargatu ez duen ezarpen bat probatzen.

Aplikatu aldaketa konexioaren jabearen bidez eta berrezarri elkartea kontrolatutako leiho batean. Dagoeneko instalatutako child batek uneko kapsulatzea mantentzen du ordezkatu arte, beraz fitxategia editatzeak bakarrik ez du frogatzen antolamendu berria erabiltzen ari denik.

Egiaztatu bildutako datuak, ez soilik portua

Harrapatu pasabidean babestutako trafikoak isurtzen duen bitartean, eta gero alderatu strongSwanen beraren ikuspegiarekin:

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

native ESP IP 50 protokolo gisa agertzen da eta ez du UDPren antzik. Bildutako ESP 4500eko UDP datagrama gisa agertzen da, haien karga erabilgarria IKE ez delarik. Portu bereko IKE trafikoa ez da kapsulatzearen froga, MOBIKEk IKE hara eraman baitezake datu-bidea native izaten jarraitzen duen bitartean, beraz irakurri karga erabilgarria, ez portu-zenbakia.

Eduki kontuan bidearen MTUa ere. Bilgarriak gainkarga gehitzen du, eta native ESP zeraman bide batek doikuntzak behar izan ditzake paketeak handitzen direnean. Beharrezko ICMP kudeaketa diseinuaren parte izan beharko litzateke jada; kapsulatzeak ez du mendekotasun hori kentzen.

Onartu aldaketa tuneleko aplikazio-trafiko berria harrapaketan bi muturretan bildutako ESP gisa ikusten denean, eta barneko zerbitzua eta haren itzulera-bidea oraindik funtzionatzen dutenean. Hori baino gutxiago fitxategi batean zuzen dirudien konfigurazio bat da.

Erlazionatutako artikuluak