Tervezzen IKEv2-beállításokat több ügyfélhez

Egy működő profil egy asztali gépen egyetlen ügyfél sikeres tesztje. Ez nem többplatformos telepítés, és ha annak tekintjük, kialakul a jól ismert támogatási minta: a Windows csatlakozik, a telefon elbukik az identitásellenőrzésnél, és a felügyelt laptop minden ébredéskor újracsatlakozik. A különbségek valósak és nagyrészt előre jelezhetők, ezért a tervnek mátrixnak kell lennie, nem képernyőképnek.

Először döntse el az identitásszerződést

Dokumentálja a kiszolgáló identitását, a tanúsítványba vetett bizalmat és az ügyfél-hitelesítési módszert, mielőtt az algoritmusokról beszélne. Ez a három dönti el, hogy az ügyfél egyáltalán tud-e hitelesíteni, és ezeket fejezik ki a platformok eltérően.

Ellenőrizze, hogyan nevezi meg minden platform az elvárt azonosítót, és hogyan kezeli a tárgy alternatív neveit. Egy profil, amely egy ügyfélen elfogad egy kiszolgálónevet, egy másikon elutasíthatja ugyanazt a tanúsítványt, mert az azonosító mező más értékből töltődik ki.

Ezután válassza ki a kriptográfiai metszetet

Hasonlítsa össze a támogatott ügyfelek által kínált javaslatokat, és válasszon olyan modern metszetet, amelyet az átjáró is engedélyez. Ne engedélyezzen túlméretezett régi listát egyetlen régi eszköz csatlakozása érdekében, mert az a lista lesz az átjáró alapértelmezése minden későbbi esethez. Írja le, miért van még mindig ott minden régi lehetőség. Ha senki nem tudja megnevezni az eszközt, amelynek szüksége van rá, akkor az nem követelmény.

Tartsa külön a tervben az IKE és a CHILD beállításait. Az IKE-cseréhez elfogadható javaslat nem automatikusan elfogadható a védett forgalomhoz, és a kettőt külön tárgyalják. Egy átjáró, amely az egyik rétegen elfogad egy javaslatot, a másikon még elutasíthatja, és a napló olyan hibát mutat, mintha az első réteg sikerült volna.

Biztosítsa a hitelesítő adatokat ellenőrzött folyamattal, és tartsa a felhasználói jelszót, a megosztott titkot és az ügyfél privát kulcsát saját mezőikben. A hasonló nevű dobozokon végzett próbálkozás az az út, amelyen a működő teszt megismételhetetlenné válik.

Az életciklust tesztelje, ne az állandó állapotot

Minden ügyfélnél tesztelje a kezdeti hitelesítést, a tervezett alkalmazást, a DNS-feloldást és a címcsaládok lefedettségét. Ezután gyakorolja azokat a részeket, amelyek csak később jelennek meg: megújítás, alvás és normál hálózati változás.

A MOBIKE támogatása és az újrahitelesítés viselkedése eltérhet az imént mért állandó eredménytől. Rögzítse az eseményt és az asszociáció állapotát abban a pillanatban, ne csak azt, hogy az interfész a végén csatlakozottnak látszik-e.

Határozza meg, mit tehet a közvetlen forgalom, amíg a VPN nem érhető el. Ez az ügyfél újracsatlakozásától független szakpolitikai döntés, és a legtöbb telepítés a második kérdésre válaszol, miközben figyelmen kívül hagyja az elsőt. Írja le a választ a telepítési jegyzetekbe a profilnevek mellé. Valakinek szüksége lesz rá egy kimaradás alatt, és nem lesz ideje újra felépíteni.

Használjon kiszolgálóidentitás-ellenőrzést, amikor az egyik platform nem ért egyet

Amikor egy profil működik az egyik platformon, a másik pedig elutasítja a nevét, hasonlítsa össze az ügyfél által ténylegesen küldött azonosítót a tanúsítványban szereplő azonosítókkal. Ez az összehasonlítás a legtöbb ilyen esetet gyorsabban oldja meg, mint a rejtjel-listák módosítása.

Őrizze meg a tesztelt mátrixot a konfigurációs forrással és a frissítési eljárással együtt. Amikor egy régi ügyfél támogatása véget ér, szándékosan távolítsa el a kivételét, ahelyett hogy gyengébb kompatibilitási beállításokat hagyna rejtve az átjáróban a következő audit számára. A strongSwan IKEv2-dokumentációja hasznos hivatkozás arra, hogyan konfigurálják a cseréket.