Varför inbyggda Windows IKEv2 inte har något PSK-fält alls

Gatewaydokumentationen säger att den fördelade nyckeln läggs in i klienten, men Windows-profilen har inget fält för den. Den luckan är inte en bugg som kringgås genom att skriva nyckeln i lösenordsrutan. Det är skillnaden mellan vad ett protokoll kan och vad en viss implementering erbjuder.

Protokollförmåga är inte klientstöd

IKEv2-specifikationen omfattar autentisering med delad nyckel, så en gateway kan legitimt konfigureras för det. Den inbyggda Windows-profilen för fjärråtkomst dokumenterar i stället certifikat- och EAP-upplägg, och protokollförmågan skapar inte ett fält, en parameter eller ett registervärde som klienten aldrig har haft.

Folk hamnar vanligtvis på PowerShell-referens för att lägga till en VPN-anslutning, och där visas L2tpPsk för L2TP-upplägget. Den parametern tillhör L2TP och är inte en allmän IKEv2-hemlighet. Inställningar för algoritmval väljer skyddsparametrar, vilket är en tredje, orelaterad sak. Windows Server-routningsrollen är inte heller samma objekt. Ett servergränssnitt kan ha konfigurationskontroller som en skrivbordsklientprofil inte har, och att kopiera en serverinställning till en arbetsstationsprofil återskapar inte förmågan.

Välj mellan certifikat, EAP eller L2TP

Om gatewayoperatören accepterar certifikatautentisering är det vanligtvis det renaste målet: klienten visar ett certifikat, gatewayen validerar det mot en betrodd utfärdare och ingen delad hemlighet ligger kvar i en profil som någon kan kopiera. Det kräver registrering, en betrodd kedja och en gatewaykonfiguration som kopplar certifikatet till ett auktoriseringsbeslut.

EAP med en användarlegitimation är den andra stödda vägen på den här klienten, och den flyttar beslutet till en identitetsleverantör. Den inför också egna beroenden, eftersom EAP-metoden, servercertifikatet och klientens förtroende för det certifikatet alla måste stämma. Att byta till L2TP/IPsec bara för att få ett bekant fält ändrar protokollstacken. Det är acceptabelt när det är ett stött val med en dokumenterad anledning, och det är ett dåligt resultat när det sker för att någon letade efter en ruta att skriva en nyckel i.

Kontrollera vad gatewayen accepterar

Fråga operatören vilka autentiseringsmetoder fjärråtkomsttjänsten erbjuder i dag, inte vilka produkten stöder generellt. En tjänst som är konfigurerad för IKEv2 med bara PSK accepterar inte ett certifikat för att klienten föredrar ett.

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

Läs profilens autentiseringsmetod och certifikatarkivet tillsammans. En profil inställd på EAP utan ett användbart certifikat bakom misslyckas på ett sätt som ser ut som ett serverproblem.

Om svaret är att bara PSK är tillgängligt är de ärliga alternativen en godkänd klient som stöder det, eller en ändring i gatewayens autentiseringsdesign. Ingen av dem är en lokal omväg, och att låtsas motsatsen ger en anslutning som bara personen som konfigurerade den kan återskapa.

Skriv ned beslutet och hemligheterna

Skriv ned den valda metoden, tillitsankaret, identiteten som hör till och personen som godkände ändringen. Den anteckningen är vad en incidentgenomgång behöver, och den hindrar också nästa ingenjör från att återupptäcka samma återvändsgränd.

Håll hemligheterna åtskilda i dina anteckningar: ett kontolösenord, en lösenfras för en privat nyckel och en fördelad gatewaynyckel är tre olika saker, även när en inställningsskärm kallar dem alla lösenord. Att blanda ihop dem är hur en nyckel hamnar i ett ärende. Testa den resulterande profilen med en ny anslutning och en applikationsbegäran till en privat resurs. En lyckad tunnel utan en nåbar tjänst är ett delresultat, och profilen bör inte beskrivas som klar förrän resursen också fungerar.