Kodėl natūraliame Windows IKEv2 visiškai nėra PSK lauko

Šliuzo dokumentacija teigia, kad iš anksto bendrinamas raktas įvedamas kliente, tačiau Windows profilyje tam nėra lauko. Ši spraga nėra klaida, kurią galima apeiti įrašius raktą į slaptažodžio laukelį. Tai skirtumas tarp to, ką protokolas gali, ir to, ką siūlo konkreti realizacija.

Protokolo galimybė nėra kliento palaikymas

IKEv2 specifikacija apima autentifikavimą bendrinamuoju raktu, todėl šliuzas gali būti teisėtai tam sukonfigūruotas. Natūralus Windows nuotolinės prieigos profilis vietoj to dokumentuoja sertifikatų ir EAP sprendimus, o protokolo galimybė nesukuria lauko, parametro ar registro reikšmės, kurios klientas niekada neturėjo.

Žmonės paprastai patenka į PowerShell nuoroda VPN ryšiui pridėti, kur L2TP sprendimui rodomas L2tpPsk. Šis parametras priklauso L2TP ir nėra bendra IKEv2 paslaptis. Algoritmų pasirinkimo nuostatos renkasi apsaugos parametrus, o tai jau trečias, nesusijęs dalykas. Windows Server maršrutizavimo vaidmuo taip pat nėra tas pats objektas. Serverio sąsaja gali turėti konfigūravimo valdiklių, kurių darbalaukio kliento profilis neturi, o serverio nuostatos kopijavimas į darbo stoties profilį tos galimybės neatkuria.

Rinkitės sertifikatą, EAP arba L2TP

Jei šliuzo operatorius priims sertifikato autentifikavimą, tai paprastai yra švariausias tikslas: klientas pateikia sertifikatą, šliuzas jį patikrina pas patikimą išdavėją, o profilyje nelieka bendrinamos paslapties, kurią kas nors galėtų nusikopijuoti. Tam reikia registracijos, patikimos grandinės ir šliuzo konfigūracijos, kuri sertifikatą susieja su autorizavimo sprendimu.

EAP su naudotojo kredencialais yra kitas palaikomas kelias šiame kliente, ir jis perkelia sprendimą pas tapatybės teikėją. Jis taip pat atneša savo priklausomybes, nes EAP metodas, serverio sertifikatas ir kliento pasitikėjimas tuo sertifikatu turi visi sutapti. Perėjimas prie L2TP/IPsec vien dėl pažįstamo lauko keičia protokolų rinkinį. Tai priimtina, kai tai palaikomas pasirinkimas su dokumentuota priežastimi, ir yra blogas rezultatas, kai taip nutinka todėl, kad kažkas ieškojo laukelio raktui įrašyti.

Patikrinkite, ką priims šliuzas

Paklauskite operatoriaus, kokius autentifikavimo metodus nuotolinės prieigos tarnyba siūlo šiandien, o ne kokius produktas palaiko apskritai. Tarnyba, sukonfigūruota IKEv2 tik su PSK, nepriims sertifikato vien todėl, kad klientas jo nori.

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

Skaitykite profilio autentifikavimo metodą ir sertifikatų saugyklą kartu. Profilis, nustatytas EAP be tinkamo sertifikato už jo, nepavyksta taip, kad atrodo kaip serverio problema.

Jei atsakymas yra, kad prieinamas tik PSK, sąžiningi variantai yra patvirtintas klientas, kuris jį palaiko, arba šliuzo autentifikavimo dizaino pakeitimas. Nė vienas nėra vietinis apeinamasis sprendimas, o teigiant priešingai sukuriamas ryšys, kurį gali atkurti tik jį sukonfigūravęs žmogus.

Užrašykite sprendimą ir paslaptis

Užrašykite pasirinktą metodą, pasitikėjimo atramą, jį atitinkančią tapatybę ir žmogų, patvirtinusį pakeitimą. Tas įrašas yra tai, ko reikia incidento apžvalgai, ir jis taip pat neleidžia kitam inžinieriui vėl atrasti tos pačios aklavietės.

Laikykite paslaptis atskirai savo užrašuose: paskyros slaptažodis, privataus rakto slaptafrazė ir iš anksto bendrinamas šliuzo raktas yra trys skirtingi dalykai, net kai nustatymų ekranas visus juos vadina slaptažodžiu. Jų supainiojimas yra būdas, kuriuo raktas patenka į bilietą. Išbandykite gautą profilį nauju ryšiu ir viena programos užklausa į privatų išteklių. Sėkmingas tunelis be pasiekiamos tarnybos yra dalinis rezultatas, ir profilis neturėtų būti apibūdinamas kaip baigtas, kol išteklius irgi neveikia.