Proč nativní Windows IKEv2 vůbec nemá pole pro PSK

Dokumentace brány uvádí, že předem sdílený klíč se zadává do klienta, ale profil ve Windows pro něj nemá pole. Tato mezera není chyba, kterou by šlo obejít napsáním klíče do pole pro heslo. Je to rozdíl mezi tím, co protokol umí, a tím, co nabízí konkrétní implementace.

Schopnost protokolu není podpora klienta

Specifikace IKEv2 zahrnuje autentizaci sdíleným klíčem, takže bránu lze pro ni legitimně nakonfigurovat. Nativní profil vzdáleného přístupu ve Windows místo toho dokumentuje uspořádání s certifikáty a EAP a schopnost protokolu nevytváří pole, parametr ani hodnotu registru, kterou klient nikdy neměl.

Lidé obvykle skončí u reference PowerShellu pro přidání připojení VPN, kde je pro uspořádání L2TP uveden L2tpPsk. Tento parametr patří k L2TP a není obecným tajemstvím IKEv2. Nastavení výběru algoritmů volí parametry ochrany, což je třetí, nesouvisející věc. Role směrování ve Windows Serveru také není stejný objekt. Serverové rozhraní může mít ovládací prvky, které profil desktopového klienta nemá, a zkopírování serverového nastavení do profilu pracovní stanice tuto schopnost nereprodukuje.

Vyberte mezi certifikátem, EAP nebo L2TP

Pokud operátor brány přijme autentizaci certifikátem, bývá to obvykle nejčistší cíl: klient předloží certifikát, brána jej ověří u důvěryhodného vydavatele a v profilu nezůstane sdílené tajemství, které by někdo mohl zkopírovat. Vyžaduje to registraci, důvěryhodný řetězec a konfiguraci brány, která certifikát spojí s rozhodnutím o autorizaci.

EAP s uživatelským pověřením je druhá podporovaná cesta v tomto klientovi a přesouvá rozhodnutí na poskytovatele identity. Přináší také vlastní závislosti, protože metoda EAP, certifikát serveru a důvěra klienta v tento certifikát se musejí sladit. Přechod na L2TP/IPsec jen kvůli známému poli mění sadu protokolů. To je přijatelné, když jde o podporovanou volbu s zdokumentovaným důvodem, a je to špatný výsledek, když se to stane proto, že někdo hledal políčko, do kterého by napsal klíč.

Ověřte, co brána přijme

Zeptejte se operátora, které metody autentizace služba vzdáleného přístupu dnes nabízí, ne které produkt podporuje obecně. Služba nakonfigurovaná pro IKEv2 pouze s PSK nepřijme certifikát jen proto, že mu klient dává přednost.

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

Čtěte metodu autentizace profilu a úložiště certifikátů společně. Profil nastavený na EAP bez použitelného certifikátu za ním selhává způsobem, který vypadá jako problém serveru.

Pokud je odpověď, že je dostupný jen PSK, poctivé možnosti jsou schválený klient, který jej podporuje, nebo změna návrhu autentizace brány. Ani jedno není místní obejití a předstírání opaku vytváří připojení, které dokáže zopakovat jen ten, kdo je nastavil.

Zaznamenejte rozhodnutí a tajemství

Zapište zvolenou metodu, kotvu důvěry, identitu, která k ní patří, a osobu, která změnu schválila. Tento záznam je to, co potřebuje přezkum incidentu, a také to brání dalšímu inženýrovi znovu objevit stejnou slepou uličku.

Udržujte tajemství v poznámkách oddělená: heslo účtu, přístupová fráze soukromého klíče a předem sdílený klíč brány jsou tři různé věci, i když obrazovka nastavení všechny označuje jako heslo. Jejich záměna je způsob, jak se klíč dostane do tiketu. Otestujte výsledný profil novým připojením a jedním požadavkem aplikace na soukromý zdroj. Úspěšný tunel bez dostupné služby je částečný výsledek a profil by se neměl označit za hotový, dokud nefunguje i zdroj.