Hvorfor indbygget Windows IKEv2 slet ikke har noget PSK-felt

Gatewayens dokumentation siger, at den foruddelte nøgle skal indtastes i klienten, mens Windows-profilen ikke har noget felt til den. Det hul er ikke en fejl, man omgår ved at skrive nøglen i adgangskodefeltet. Det er forskellen på, hvad en protokol kan, og hvad en bestemt implementering tilbyder.

Protokolevne er ikke klientsupport

IKEv2-specifikationen omfatter godkendelse med delt nøgle, så en gateway kan med rette konfigureres til det. Den indbyggede Windows-profil for fjernadgang dokumenterer i stedet certifikat- og EAP-ordninger, og protokolevne skaber ikke et felt, en parameter eller en registreringsværdi, som klienten aldrig har haft.

Folk ender normalt på PowerShell-reference til at tilføje en VPN-forbindelse, og den viser L2tpPsk til L2TP-ordningen. Den parameter hører til L2TP og er ikke en generel IKEv2-hemmelighed. Indstillinger for algoritmevalg vælger beskyttelsesparametre, hvilket er en tredje, ubeslægtet ting. Windows Server-routingrollen er heller ikke det samme objekt. En servergrænseflade kan have konfigurationskontroller, som en skrivebordsklientprofil ikke har, og at kopiere en serverindstilling til en arbejdsstationsprofil genskaber ikke evnen.

Vælg mellem certifikat, EAP eller L2TP

Hvis gatewayoperatøren accepterer certifikatgodkendelse, er det normalt det reneste mål: klienten fremviser et certifikat, gatewayen validerer det mod en betroet udsteder, og ingen delt hemmelighed ligger i en profil, som nogen kan kopiere. Det kræver tilmelding, en betroet kæde og en gatewaykonfiguration, der knytter certifikatet til en autorisationsbeslutning.

EAP med en brugerlegitimation er den anden understøttede vej på denne klient, og den flytter beslutningen til en identitetsudbyder. Den indfører også sine egne afhængigheder, fordi EAP-metoden, servercertifikatet og klientens tillid til det certifikat alle skal passe sammen. At skifte til L2TP/IPsec alene for at få et velkendt felt ændrer protokolstakken. Det er acceptabelt, når det er et understøttet valg med en dokumenteret grund, og det er et dårligt resultat, når det sker, fordi nogen ledte efter en boks at skrive en nøgle i.

Undersøg, hvad gatewayen accepterer

Spørg operatøren, hvilke godkendelsesmetoder fjernadgangstjenesten tilbyder i dag, ikke hvilke produktet understøtter generelt. En tjeneste, der er konfigureret til IKEv2 med kun PSK, accepterer ikke et certifikat, fordi klienten foretrækker et.

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

Læs profilets godkendelsesmetode og certifikatlageret sammen. En profil, der er sat til EAP uden et brugbart certifikat bag sig, fejler på en måde, der ligner et serverproblem.

Hvis svaret er, at kun PSK er tilgængeligt, er de ærlige muligheder en godkendt klient, der understøtter det, eller en ændring af gatewayens godkendelsesdesign. Ingen af dem er en lokal omvej, og at foregive andet giver en forbindelse, som kun den person, der konfigurerede den, kan genskabe.

Skriv beslutningen og hemmelighederne ned

Skriv den valgte metode, tillidsankeret, den identitet, der knytter sig til den, og den person, der godkendte ændringen, ned. Den registrering er, hvad en hændelsesgennemgang har brug for, og den er også det, der forhindrer den næste ingeniør i at genopdage den samme blindgyde.

Hold hemmelighederne adskilt i dine noter: en kontoadgangskode, en adgangssætning til en privat nøgle og en foruddelt gatewaynøgle er tre forskellige ting, selv når en indstillingsskærm kalder dem alle adgangskode. At forveksle dem er måden, en nøgle ender i en sag. Test den resulterende profil med en ny forbindelse og en programanmodning til en privat ressource. En vellykket tunnel uden en tilgængelig tjeneste er et delvist resultat, og profilen bør ikke beskrives som færdig, før ressourcen også virker.