Hvorfor innebygd Windows IKEv2 ikke har noe PSK-felt i det hele tatt

Gatewaydokumentasjonen sier at den forhåndsdelte nøkkelen legges inn i klienten, men Windows-profilen har ikke noe felt for den. Dette hullet er ikke en feil man omgår ved å skrive nøkkelen i passordfeltet. Det er forskjellen mellom hva en protokoll kan, og hva en bestemt implementasjon tilbyr.

Protokollens evne er ikke klientstøtte

IKEv2-spesifikasjonen omfatter autentisering med delt nøkkel, så en gateway kan med rette konfigureres for det. Den innebygde Windows-profilen for fjern tilgang dokumenterer i stedet sertifikat- og EAP-ordninger, og protokollens evne skaper ikke et felt, en parameter eller en registerverdi som klienten aldri har hatt.

Folk havner vanligvis på PowerShell-referanse for å legge til en VPN-tilkobling, og der vises L2tpPsk for L2TP-ordningen. Den parameteren tilhører L2TP og er ikke en generell IKEv2-hemmelighet. Innstillinger for algoritmevalg velger beskyttelsesparametere, som er en tredje, urelatert sak. Windows Server-rutingsrollen er heller ikke det samme objektet. Et servergrensesnitt kan ha konfigurasjonskontroller som en skrivebordsklientprofil ikke har, og å kopiere en serverinnstilling til en arbeidsstasjonsprofil gjenskaper ikke evnen.

Velg mellom sertifikat, EAP eller L2TP

Hvis gatewayoperatøren godtar sertifikatautentisering, er det vanligvis det reneste målet: klienten legger frem et sertifikat, gatewayen validerer det mot en klarert utsteder, og ingen delt hemmelighet ligger i en profil som noen kan kopiere. Det krever registrering, en klarert kjede og en gatewaykonfigurasjon som kobler sertifikatet til en autorisasjonsbeslutning.

EAP med en brukerlegitimasjon er den andre støttede veien på denne klienten, og den flytter beslutningen til en identitetsleverandør. Den innfører også egne avhengigheter, fordi EAP-metoden, servercertifikatet og klientens tillit til det sertifikatet alle må stemme. Å bytte til L2TP/IPsec bare for å få et kjent felt endrer protokollstakken. Det er akseptabelt når det er et støttet valg med en dokumentert grunn, og det er et dårlig resultat når det skjer fordi noen lette etter en boks å skrive en nøkkel i.

Undersøk hva gatewayen godtar

Spør operatøren hvilke autentiseringsmetoder fjernaksess-tjenesten tilbyr i dag, ikke hvilke produktet støtter generelt. En tjeneste som er konfigurert for IKEv2 med bare PSK, godtar ikke et sertifikat fordi klienten foretrekker ett.

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

Les profilens autentiseringsmetode og sertifikatlageret sammen. En profil satt til EAP uten et brukbart sertifikat bak seg feiler på en måte som ser ut som et serverproblem.

Hvis svaret er at bare PSK er tilgjengelig, er de ærlige valgene en godkjent klient som støtter det, eller en endring i gatewayens autentiseringsdesign. Ingen av dem er en lokal omvei, og å late som noe annet gir en tilkobling som bare personen som konfigurerte den, kan gjenskape.

Skriv ned beslutningen og hemmelighetene

Skriv ned den valgte metoden, tillitsankeret, identiteten som hører til, og personen som godkjente endringen. Den registreringen er det en hendelsesgjennomgang trenger, og den hindrer også neste ingeniør i å gjenoppdage den samme blindveien.

Hold hemmelighetene atskilt i notatene dine: et kontopassord, en passfrase for privatnøkkel og en forhåndsdelt gatewaynøkkel er tre forskjellige ting, selv når en innstillingsskjerm kaller dem alle passord. Å forveksle dem er måten en nøkkel havner i en sak. Test den resulterende profilen med en ny tilkobling og én applikasjonsforespørsel til en privat ressurs. En vellykket tunnel uten en tilgjengelig tjeneste er et delresultat, og profilen bør ikke beskrives som ferdig før ressursen også virker.