strongSwan trap mód: miért vár az IPsec-alagút forgalomra

Egy tétlen, igény szerinti IPsec-alagút nem mutat CHILD SA-t, amíg egy csomag nem illeszkedik a trap házirendjéhez. Olvassa el az állapotot, ellenőrizze a kiváltót, és tudja, mikor illik a start.

Nem jelenik meg CHILD SA a státuszkimenetben, az alagút halottnak látszik, majd egy ping a távoli alhálózat felé felhozza. Egy igény szerinti IPsec-beállításban ez a sorrend a tervezés, nem hiba. A trap házirend telepít egy szelektort és vár, és az első illeszkedő csomag indítja el az IKE-et és a CHILD SA egyeztetést.

A zavar egy része szótár: az „up” két különböző állapotra használatos. A konfiguráció betöltődött, és a kernel házirend létezik, az adategyesítés viszont nem. Egy monitor, amely csak az aktív SA-kat számolja, egészséges helyet jelent leálltnak, amíg senki nem küld oda forgalmat.

Egy tétlen, igény szerinti alagútnak nincs CHILD SA-ja, amit mutathatna

A trap bejegyzés önmagában semmit nem hitelesít. Arra kéri a kernelt, hogy tartson házirendet a kiválasztott forgalomhoz, és emeljen acquisitiont, amikor egy csomagnak erre a házirendre van szüksége. A daemon fogadja az acquisitiont, a child-definícióhoz illeszti, és onnan egyeztet. Addig nincs megjeleníthető IKE SA sem, ezért lehet mindkét lista egyszerre üres.

Ez a sorrend teszi olvashatóvá a naplókat. Először az acquisition jön, aztán az IKE_SA_INIT és az IKE_AUTH, majd a CHILD SA. Ha a napló közvetlenül az acquisition után véget ér, a kiváltó működött. Az egyeztetés meghiúsult, és a következő kérdés a hitelesítő adatokra, javaslatokra vagy elérhetőségre vonatkozik, nem a trapra.

A Linux kernel backenddel már bármely SA létezése előtt láthatja a házirendet. Futtassa: ip xfrm policy és keresse az out irányú, a kapcsolatra mutató sablonnal rendelkező szelektort. Az a bejegyzés az igény szerinti állapot, és a megléte az első, amit meg kell erősíteni.

A start_action dönti el, hogy egyáltalán vár-e valami

Minden child a swanctl.conf fájlban start_action. start a konfiguráció betöltésekor indul, trap telepíti a házirendet és vár, a none pedig másra hagyja az indítást. Csak a trap hozza létre a fent leírt „ping, és feljön” viselkedést.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

A két forgalomszelektor határozza meg, mi számít érdekesnek, és az ezeken az előtagokon kívüli gazdagépről jövő csomag nem váltja ki a trapot; a szokásos módon útválasztódik. A szelektorok szélesítése, hogy a kiváltó mohóbb legyen, szélesíti azt a hatókört is, amelyet az alagút védeni állít, ezért abból a forgalomból származtassa őket, amelyet valóban titkosítani akar.

A swanctl.conf-referencia felsorolja az elfogadott értékeket, valamint a külön close és DPD műveleteket, amelyek szabályozzák, mi történik, ha az SA már létezik.

Tudja meg, egyáltalán kiváltódott-e a kiváltó

Kezdje ezzel: swanctl --list-conns és erősítse meg, hogy a child a szándékolt művelettel töltődött be. Ezután küldjön egy csomagot egy local_ts belüli gazdagépről egy remote_ts belüli címre, és figyelje a swanctl --list-sas. Ha a kimenet nem változik, nem ért acquisition a daemonhoz.

Két szokásos ok a csendes trapra: a csomag source-NAT-olódott, mielőtt a házirendet elérte, és már nem illeszkedik ehhez: local_ts, vagy a kapcsolat soha nem töltődött be szintaxis- vagy hitelesítő adat hiba miatt. Futtassa újra ezt: swanctl --load-all és olvassa el a kimenetét, mielőtt a szelektorokhoz nyúl. Egy be nem töltődött kapcsolat nem telepít házirendet, így nincs mit kiváltania a forgalomnak.

Az irány is számít: a kimenő forgalomra telepített trap nem indul be egy bejövő csomagra. Ha a távoli félnek kell felhoznia az alagutat, saját trapra van szüksége, vagy ennek az oldalnak erre: start.

Az első csomagra várni nem mindig a helyes csere

Az interaktív munkamenetek érzik a beállítás költségét. Az első kérés fizet az IKE-cseréért és a CHILD-egyeztetésért, és egy rövid határidejű kliens feladhatja, mielőtt az SA létezne. A proaktív start megszünteti ezt az első csomagos késleltetést. De nyitva tart egy alagutat olyan forgalomnak, amely talán soha nem érkezik meg.

Három tény dönti el a választást: milyen gyakran használják az útvonalat, van-e szoros határideje az első kérésnek, és elérhető-e a peer indításkor. Az alkalmi kötegelt forgalom és az indításkor esetleg offline peer egyaránt ezt támogatja: trap. A késleltetésre érzékeny kliens és a mindig elérhető peer ezt támogatja: start. Ha mindkét fél kezdeményezhet, egyezzenek meg, kié a kiváltó, hogy ne legyen dupla egyeztetés.

A telepített házirend sem szivárgásbiztos garancia. Ha a követelmény fail-closed, a tűzfalnak el kell dobnia az SA nélküli forgalmat, és ez a szabály a child-definíción kívül él.

Jegyezze fel a három sort, amely lezárja a következő vitát

Írja fel a szelektorokat, az indítási műveletet és a parancs kimenetét, amely a házirendet SA nélkül mutatja. Ez a három sor választja el az „igény szerinti és tétlen” állapotot a „nem töltődik be” állapottól, amikor legközelebb valaki leálltnak jelenti az alagutat. Egy percbe telik rögzíteni őket. Nélkülük ugyanaz a vizsgálat nulláról indul.

Olyan gazdagépről teszteljen, amely valóban a szelektoron belül van. A routerről indított ping gyakran más útvonalat követ, és semmit nem bizonyít a mögötte lévő alhálózatot védő házirendről.

Kapcsolódó cikkek