Miért nincs a natív Windows IKEv2-ben egyáltalán PSK-mező

Az átjáró dokumentációja szerint az előre megosztott kulcsot a kliensbe kell beírni, a Windows-profilnak viszont nincs erre mezője. Ez a hiány nem hiba, amelyet a kulcs jelszómezőbe gépelésével meg lehet kerülni. Ez a különbség aközött, amire egy protokoll képes, és amit egy adott megvalósítás kínál.

A protokoll képessége nem kliens-támogatás

Az IKEv2 specifikációja tartalmazza a megosztott kulcsos hitelesítést, ezért egy átjáró jogszerűen konfigurálható rá. A natív Windows távoli hozzáférési profil ehelyett tanúsítványos és EAP-megoldásokat dokumentál, és a protokoll képessége nem hoz létre olyan mezőt, paramétert vagy beállításjegyzék-értéket, amely a kliensnek soha nem volt.

Az emberek általában a PowerShell-referencia VPN-kapcsolat hozzáadásához oldalon kötnek ki, ahol az L2TP-megoldáshoz L2tpPsk látható. Ez a paraméter a L2TP része, és nem általános IKEv2-titok. Az algoritmusválasztó beállítások védelmi paramétereket választanak, ami egy harmadik, nem kapcsolódó dolog. A Windows Server útválasztási szerepe sem ugyanaz az objektum. Egy kiszolgálói felületen lehetnek olyan konfigurációs vezérlők, amelyekkel egy asztali kliensprofil nem rendelkezik, és egy kiszolgálóbeállítás munkaállomás-profilba másolása nem állítja vissza a képességet.

Válasszon tanúsítvány, EAP vagy L2TP közül

Ha az átjáró üzemeltetője elfogadja a tanúsítványos hitelesítést, az általában a legtisztább cél: a kliens tanúsítványt mutat be, az átjáró azt egy megbízható kibocsátónál ellenőrzi, és nem marad megosztott titok a profilban, amelyet bárki lemásolhatna. Ehhez regisztráció, megbízható lánc és olyan átjárókonfiguráció kell, amely a tanúsítványt engedélyezési döntéshez köti.

Az EAP felhasználói hitelesítő adattal a másik támogatott út ezen a kliensen, és a döntést egy identitásszolgáltatóhoz helyezi át. Saját függőségeket is hoz, mert az EAP-módszernek, a kiszolgáló tanúsítványának és a kliens e tanúsítványba vetett bizalmának mind össze kell illeszkednie. Az L2TP/IPsec-re váltás pusztán egy ismerős mezőért megváltoztatja a protokollvermeket. Ez elfogadható, ha dokumentált okkal támogatott választás, és rossz eredmény, ha azért történik, mert valaki egy mezőt keresett a kulcs beírásához.

Ellenőrizze, mit fogad el az átjáró

Kérdezze meg az üzemeltetőt, milyen hitelesítési módszereket kínál ma a távoli hozzáférési szolgáltatás, és ne azt, hogy a termék általában melyeket támogatja. Egy csak PSK-ra konfigurált IKEv2-szolgáltatás nem fogad el tanúsítványt azért, mert a kliens azt részesíti előnyben.

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

Olvassa együtt a profil hitelesítési módszerét és a tanúsítványtárolót. Az EAP-re állított profil használható tanúsítvány nélkül olyan módon hibázik, amely kiszolgálóproblémának látszik.

Ha a válasz az, hogy csak PSK érhető el, az őszinte lehetőségek egy azt támogató jóváhagyott kliens vagy az átjáró hitelesítési tervezésének módosítása. Egyik sem helyi kerülőút, és ennek ellenkezőjét állítani olyan kapcsolatot eredményez, amelyet csak az tud újra létrehozni, aki beállította.

Rögzítse a döntést és a titkokat

Jegyezze fel a választott módszert, a bizalmi horgonyt, a hozzá tartozó identitást és a változást jóváhagyó személyt. Ez a feljegyzés az, amire egy incidensvizsgálatnak szüksége van, és ez az is, ami megakadályozza, hogy a következő mérnök újra felfedezze ugyanazt a zsákutcát.

Tartsa a titkokat külön a jegyzeteiben: a fiókjelszó, egy titkos kulcs jelmondata és az átjáró előre megosztott kulcsa három különböző dolog, akkor is, ha egy beállítási képernyő mindegyiket jelszónak nevezi. Ezek összekeverése az, ahogyan egy kulcs jegybe kerül. Tesztelje a létrejött profilt friss kapcsolattal és egy alkalmazáskéréssel egy privát erőforrás felé. A sikeres alagút elérhető szolgáltatás nélkül részeredmény, és a profilt nem szabad késznek nevezni, amíg az erőforrás is nem működik.