Az IKEv2-csere működik, aztán a hitelesítés elbukik: hol keressük

Az a kliens, amely IKEv2-választ kap, bizonyította, hogy az átjáró elérhető, hogy mindkét fél meg tud egyezni egy javaslatban, és hogy a kezdeti kulcscsere befejeződött. Azt nem bizonyította, hogy bárki hitelesítve van. A következő csere identitásokat, tanúsítványokat vagy EAP-t szállít, és itt szokott megállni a kapcsolat. Annak elolvasása, hogy melyik ellenőrzés bukott el, maga a teljes diagnózis, és a hibaüzenet önmagában ritkán mondja meg.

1. ellenőrzés: a szakaszt olvassa, ne az üzenetet

Az elutasítás három helyről jöhet: a kliens megtagadja a szerver identitását, az átjáró megtagadja a kliens bizonyítékát, és egy külső hitelesítési szolgáltatás megtagadja a fiókot.

Mindegyik más naplósort állít elő más gépen, és mindegyiknek más a javítása. A kliens oldali elutasítás a szervertanúsítvány esetében bizalmi vagy elnevezési probléma a kliensen; az átjáró oldali elutasítás a kliens tanúsítványa esetében bizalmi probléma az átjárón; az EAP-hiba fiók- vagy háttérprobléma. A látott üzenet általában a kliens összefoglalója valamelyikről, ezért az átjáró naplója ugyanolyan fontos, mint a kliensé.

2. ellenőrzés: melyik identitást ellenőrizték

A kliens még azelőtt elutasíthatja a szerver tanúsítványát vagy az elvárt identitását, hogy bármilyen felhasználói hitelesítő adatot felajánlanának, és egy működő szervercím nem helyettesíti ezt az ellenőrzést. A kliens által elvárt azonosítónak meg kell egyeznie azzal, amit az átjáró bemutat, ami konfigurációs tény, nem hálózati tény.

strongSwan-szóhasználattal ez a kliensen rightid, a másik oldalon pedig az átjáró saját identitása, és az eltérés még azelőtt meghiúsul, hogy az EAP szóba kerülne.

Az átjáró külön-külön elutasíthatja a kliens tanúsítványát, kulcsbizonyítékát vagy fiókhitelesítését, és ez a három nem felcserélhető. Egy felhasználói jelszó visszaállítása nem újít meg egy eszköztanúsítványt, és egy eszköztanúsítvány újratelepítése nem javítja a hibás szerveridentitást. Tanúsítványhibák esetén először az órát ellenőrizze, aztán a bizalmi láncot, majd az elvárt azonosítót; az a kliens, amelynek órája percekkel el van állítva, egy érvényességi ellenőrzésen bukik el, amely bizalmi hibának látszik. swanctl --list-certs mindkét végén megmutatja, mi van valójában az egyes oldalak birtokában.

3. ellenőrzés: ha EAP van játékban

A kliensnek és a szervernek meg kell egyeznie egy támogatott módszerben, és a háttérrendszernek el kell fogadnia a megadott identitást.

Egy felhasználónévhez tartományi utótagra vagy a telepítés által megkövetelt meghatározott fiókformátumra lehet szükség, és a formátum dokumentált, nem kitalálható. Az üzemeltető dokumentált mezőinek megadása gyorsabb, mint a változatok próbálgatása, és elkerül egy második problémát: az ismételt kísérletek fiókzárolást válthatnak ki, amely aztán az eredeti szakaszt egy új hiba mögé rejti. Ha a módszer EAP-MSCHAPv2 egy könyvtárral szemben, a hiba a könyvtáré lehet, nem a VPN-é.

Ne tesztelje az identitásproblémákat az identitásellenőrzések kikapcsolásával. Az egy diagnosztizálható hibát diagnosztizálhatatlanná tesz, és a kapcsolatot gyengébben hagyja, mint korábban.

4. ellenőrzés: mi történik sikeres bejelentkezés után

Amint az IKE_AUTH befejeződik, a CHILD_SA-tárgyalás dönti el, mely forgalomválasztók települnek, és itt fordulhat elő, hogy egy kapcsolat sikeres, mégsem visz át semmit.

Az újonnan működő bejelentkezés gyakran feltár egy választó- vagy útvonalproblémát, amely korábban a hitelesítési hiba mögött rejtve volt. Ha az alagút feljön, és egy alkalmazás mégsem éri el a célját, a megtárgyalt választókat és útvonalakat nézze, ne ismét az identitást. Az identitásbeállítások módosítása ekkor a rossz szakaszt célozza, és általában elront egy működő bejelentkezést. Erősítse meg a swanctl --list-sas paranccsal, amely a gyermekeket és választóikat az IKE SA-tól külön mutatja.

5. ellenőrzés: mit adjunk a támogatásnak

Egy megtisztított idővonal és a pontos elutasítás többet ér, mint egy teljes diagnosztikai export, és az export tartalmazhat olyan privát kulcsokat vagy hitelesítő adatokat, amelyeket nem lenne szabad megosztania.

Jegyezze fel az időt időzónával, a kliens és az átjáró verzióit, a módszert, a felajánlott identitásláncot a jelszó helyett, és azt a pontos szakaszt, amely elutasította. A strongSwan IKEv2-konfigurációs dokumentáció leírja azokat az identitás- és EAP-beállításokat, amelyek ezeket az eredményeket eldöntik, és ezt kell elolvasni egy mező módosítása előtt. Ezután egy dolgot változtasson meg, és teszteljen új kapcsolatot, mert a gyorsítótárazott munkamenet a régi konfigurációról fog beszélni.