Naplánujte nastavení IKEv2 pro více než jednoho klienta
Funkční profil na jednom počítači je úspěšným testem jednoho klienta. Dohodněte smlouvu o identitě, vyberte podporovaný průnik a poté otestujte obnovu a spánek pro každou platformu.
Funkční profil na jedné ploše je úspěšným testem jednoho klienta. Není to multiplatformní nasazení, a když se tak bere, vzniká známý vzorec podpory: Windows se připojí, telefon selže při kontrole identity a spravovaný notebook se znovu připojuje při každém probuzení. Rozdíly jsou skutečné a z velké části předvídatelné, proto má být plán maticí, ne snímkem obrazovky.
Nejprve určete smlouvu o identitě
Zdokumentujte identitu serveru, důvěru v certifikát a metodu autentizace klienta dříve, než začnete mluvit o algoritmech. Tyto tři věci rozhodují, zda se klient vůbec může autentizovat, a právě je platformy vyjadřují různě.
Zkontrolujte, jak každá platforma pojmenovává očekávaný identifikátor a jak zachází s alternativními jmény subjektu. Profil, který na jednom klientovi přijme jméno serveru, může na jiném odmítnout stejný certifikát, protože pole identifikátoru se plní jinou hodnotou.
| Contract element | What to decide | Where platforms diverge |
|---|---|---|
| Server identity | Name or address the client must see | Identifier field and SAN matching |
| Client authentication | Certificate, EAP method or both | Which EAP variants exist and how prompts appear |
| Trust anchor | Which CA and how it is delivered | Store location and provisioning path |
Potom zvolte kryptografický průnik
Porovnejte nabídky, které může nabídnout každý podporovaný klient, a vyberte moderní průnik, který brána také povoluje. Nezapínejte přehnaně velký seznam starších voleb jen proto, aby se připojilo jedno staré zařízení, protože tento seznam se stane výchozím nastavením brány pro všechny následující. Zapište, proč každá starší volba stále existuje. Pokud nikdo nedokáže pojmenovat zařízení, které ji potřebuje, není to požadavek.
V plánu držte nastavení IKE a CHILD oddělená. Nabídka přijatelná pro výměnu IKE není automaticky přijatelná pro chráněný provoz a obě se vyjednávají zvlášť. Brána, která nabídku přijme v jedné vrstvě, ji může v jiné stále odmítnout a protokol ukáže selhání, které vypadá, jako by první vrstva uspěla.
Zajistěte přihlašovací údaje ověřeným postupem a držte uživatelské heslo, sdílené tajemství a soukromý klíč klienta ve vlastních polích. Pokusy a omyly na podobně pojmenovaných boxech jsou způsob, jak se z funkčního testu stane test neopakovatelný.
Testujte životní cyklus, ne stabilní stav
U každého klienta otestujte počáteční autentizaci, zamýšlenou aplikaci, překlad DNS a pokrytí rodin adres. Potom procvičte části, které se objeví až později: obnovu, spánek a běžnou změnu sítě.
Podpora MOBIKE a chování při opětovné autentizaci se mohou lišit od stabilního výsledku, který jste právě změřili. Zaznamenejte událost a stav asociace v daném okamžiku, ne jen to, zda rozhraní nakonec vypadá připojené.
Definujte, co smí přímý provoz dělat, dokud je VPN nedostupná. Je to politické rozhodnutí oddělené od toho, zda se klient znovu připojí, a většina nasazení odpovídá na druhou otázku, zatímco první ignoruje. Napište odpověď do poznámek k nasazení vedle názvů profilů. Někdo ji bude při výpadku potřebovat a nebude mít čas ji rekonstruovat.
Použijte kontroly identity serveru, když jedna platforma nesouhlasí
Když profil funguje na jedné platformě a jiná odmítne jeho jméno, porovnejte identifikátor, který klient skutečně odeslal, s identifikátory, které nese certifikát. Toto srovnání vyřeší většinu těchto případů rychleji než změna seznamů šifer.
Uchovávejte otestovanou matici spolu se zdrojem konfigurace a postupem aktualizace. Když podpora starého klienta skončí, jeho výjimku záměrně odstraňte, místo abyste slabší nastavení kompatibility nechali skryté v bráně pro příští audit. Dokumentace strongSwan k IKEv2 je užitečný odkaz pro to, jak se výměny konfigurují.