strongSwan EAP: az IKE-identitás kontra a várt AAA-név

A strongSwan EAP-ügyfél két kiszolgálónevet tud ellenőrizni. A remote.id az IKE-átjárót fedi, a local.aaa_id pedig az EAP-kiszolgálót; ezek nem ugyanaz a mező.

Az IKEv2 feletti EAP-hitelesítés megkérheti az ügyfelet, hogy egyetlen kapcsolatban két különböző kiszolgálónevet ellenőrizzen. Az IKE-t lezáró átjáró egy identitást mutat, és a belső TLS-cserét lezáró EAP-háttér egy másikat mutathat. A strongSwanban ezek külön konfigurációs blokkokban élnek, és a név rossz blokkba tétele olyan hibát ad, amely tanúsítványproblémának látszik. Éppen annak olvasása, hogy melyik ellenőrzés hibázott, mondja meg, melyik blokkot kell szerkeszteni.

Egy kapcsolat, két kiszolgálóidentitás

Az első identitás az IKE-csere része. Az ügyfél tárcsáz egy címet, és elvárja, hogy a partner egy adott identitást bizonyítson, rendszerint az átjáró tanúsítványában szereplő nevet.

A második az EAP-hoz tartozik. PEAP vagy TTLS esetén az ügyfél TLS-alagutat épít a hitelesítési kiszolgálóhoz az IKE SA-n belül, és ez a belső kiszolgáló a saját tanúsítványát mutatja. Ha a háttér külön gazdagép, a neve eltér az átjáróétól. Az az ügyfél, amely csak az első nevet ellenőrzi, elfogadja, amit a második állít. Az pedig, amely mindkét helyen egy nevet kapott, abban a pillanatban elbukik, amikor a kettő valóban eltér.

Mindkét név az üzemeltető konfigurációjából származik, nem abból a tanúsítványból, amely megszünteti a hibát. Az üzemeltetőtől a telepítés részleteit kérdezni gyorsabb, mint két gazdagépnevet kitalálni.

Melyik mező melyik réteghez tartozik

A swanctlben a cím és az IKE-identitás külön beállítás, és az EAP-identitás a harmadik.

A távoli cím kiválasztja, hová mennek a csomagok, a távoli identitás pedig megmondja, mit kell a partnernek bizonyítania. Az EAP-elvárás a local blokk alá kerül, mert ennek az ügyfélnek az EAP-cseréjét írja le, nem a partner IKE-viselkedését. Éppen ezt az elhelyezést olvassák félre. A név az ügyfél konfigurációjában áll, miközben kiszolgálót ír le, és ezért tűnik rossz helyen lévőnek.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

Ez a részlet nem teljes kapcsolat; a bizalmi anyagnak, a hitelesítő adatoknak és a gyermekkapcsolatok házirendjeinek még jelen kell lenniük. Szó szerinti bemásolása egy működő fájlba lecserélné azokat a beállításokat, amelyekre még szüksége van.

Miért él az aaa_id a local alatt

A local blokk leírja, mit tesz ez az oldal a hitelesítés során, beleértve az általa használt módszert és azt az identitást, amelyet a másik oldaltól ehhez a módszerhez elvár. Semmi nem állítja benne, hogy az AAA-kiszolgáló ugyanazon a gépen fut.

Az alapértelmezés élesebbé teszi a csapdát. Ha nincs kifejezett érték beállítva, a várt AAA-identitás a távoli identitást követi, így az egyneves telepítés működik, és elrejti a különbséget. A kifejezett érték csak akkor számít, ha az EAP-telepítés valóban máshol végződik. Ennek az oknak a hiányában más névre állítani olyan hibát okoz, amelyet az üzemeltető nem tud reprodukálni. Olvassa el a telepítést, mielőtt második nevet kitalál.

Tartsa az értéket azzal azonosan, amit a háttér tanúsítványa valóban állít, a név formáját is beleértve. Egy záró pont vagy a gazdagépet nem lefedő helyettesítő karakter elég az ellenőrzés bukásához.

Olyan felületek, amelyek nem tudják kifejezni a szétválasztást

A NetworkManager-profil nem ugyanaz a konfigurációs felület, mint a swanctl. A mögötte lévő bővítmény szűkebb identitásvezérlő-készletet tesz elérhetővé, és hogy melyek léteznek, a telepített verziótól függ.

Ez akkor számít, amikor a telepítésnek valóban két névre van szüksége. A kiszolgálóidentitásnak címkézett mező az egyik réteget beállíthatja, a másikat nem, így a profil helyesnek tűnhet, és mégis elbukik a belső ellenőrzésen. Ellenőrizze, mit támogat a telepített bővítmény, mielőtt feltételezné, hogy a profil ki tudja fejezni ezt az elrendezést. Ha nem tudja, a választás az üzemeltetőé: másik kiépítési útvonal vagy javított kiszolgálóidentitás-terv. A PEAP gyengítése vagy bármilyen név elfogadása megváltoztatja a hitelesítési házirendet ahelyett, hogy kijavítaná.

Az alternatíva nem az ügyfélen kitalálandó dolog. Kérje írásban a támogatott elrendezést, majd őrizze meg a választ a profil mellett.

Különböztesse meg az identitás-eltérést a lejárt tanúsítványtól

A név eltérése és a lejárt tanúsítvány különböző hibák, és a napló megkülönbözteti őket. Olvassa el az üzenetet, mielőtt eldönti, melyik mezőt módosítja.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

A szándékolt AAA-identitás beállítása nem újít meg tanúsítványt és nem alapozza meg a bizalmat a kibocsátója iránt, a tanúsítvány megújítása pedig nem javítja a hibás várt nevet. Olvassa el, melyik ellenőrzés hibázott, mielőtt újabb identitásmezőt szerkeszt. Ezután töltse újra a konfigurációt, és erősítse meg, hogy a betöltött kapcsolat a beállított értéket mutatja, mert egy soha be nem töltött szerkesztett fájl semmit nem változtat. Írja le mindkét nevet és a rétegeiket a telepítési jegyzetekbe.

Kapcsolódó cikkek