Gatewaydokumentasjonen seier at den førehandsdelte nøkkelen blir lagd inn i klienten, men Windows-profilen har ikkje noko felt for han. Dette holet er ikkje ein feil ein omgår ved å skrive nøkkelen i passordfeltet. Det er skilnaden mellom kva ein protokoll kan, og kva ein bestemd implementasjon tilbyr.

Protokollevne er ikkje klientstøtte

IKEv2-spesifikasjonen omfattar autentisering med delt nøkkel, så ein gateway kan med rette konfigurerast for det. Den innebygde Windows-profilen for fjern tilgang dokumenterer i staden sertifikat- og EAP-ordningar, og protokollevna skaper ikkje eit felt, ein parameter eller ein registerverdi som klienten aldri har hatt.

Folk hamnar vanlegvis på PowerShell-referanse for å leggje til ei VPN-tilkopling, og der blir L2tpPsk vist for L2TP-ordninga. Den parameteren høyrer til L2TP og er ikkje ein generell IKEv2-hemmelegheit. Innstillingar for algoritmeval vel verneparametrar, som er ein tredje, urelatert ting. Windows Server-rutingsrolla er heller ikkje same objektet. Eit servergrensesnitt kan ha konfigurasjonskontrollar som ein skrivebordsklientprofil ikkje har, og å kopiere ei serverinnstilling til ein arbeidsstasjonsprofil attskapar ikkje evna.

Vel mellom sertifikat, EAP eller L2TP

Viss gatewayoperatøren godtek sertifikatautentisering, er det vanlegvis det reinaste målet: klienten legg fram eit sertifikat, gatewayen validerer det hos ein klarert utgivar, og inga delt hemmelegheit ligg i ein profil som nokon kan kopiere. Det krev registrering, ei klarert kjede og ein gatewaykonfigurasjon som knyter sertifikatet til ei autorisasjonsavgjerd.

EAP med ein brukarlegitimasjon er den andre støtta vegen på denne klienten, og han flyttar avgjerda til ein identitetsleverandør. Han innfører òg eigne avhengnader, fordi EAP-metoden, servercertifikatet og klienten si tillit til det sertifikatet alle må stemme. Å byte til L2TP/IPsec berre for å få eit kjent felt endrar protokollstakken. Det er akseptabelt når det er eit støtta val med ein dokumentert grunn, og det er eit dårleg resultat når det skjer fordi nokon leita etter ein boks å skrive ein nøkkel i.

Undersøk kva gatewayen godtek

Spør operatøren kva autentiseringsmetodar fjernaksesstenesta tilbyr i dag, ikkje kva produktet støttar generelt. Ei teneste som er konfigurert for IKEv2 med berre PSK, godtek ikkje eit sertifikat fordi klienten føretrekkjer eitt.

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

Les autentiseringsmetoden til profilen og sertifikatlageret saman. Ein profil sett til EAP utan eit brukbart sertifikat bak seg feilar på ein måte som ser ut som eit serverproblem.

Viss svaret er at berre PSK er tilgjengeleg, er dei ærlege vala ein godkjend klient som støttar det, eller ei endring i autentiseringsdesignet til gatewayen. Ingen av dei er ein lokal omveg, og å late som noko anna gir ei tilkopling som berre personen som konfigurerte ho, kan attskape.

Skriv ned avgjerda og hemmeleikane

Skriv ned den valde metoden, tillitsankeret, identiteten som høyrer til, og personen som godkjende endringa. Den registreringa er det ei hendingsgjennomgang treng, og ho hindrar òg neste ingeniør i å gjenoppdage den same blindvegen.

Hald hemmeleikane åtskilde i notata dine: eit kontopassord, ei passfrase for privatnøkkel og ein førehandsdel gatewaynøkkel er tre ulike ting, sjølv når ein innstillingsskjerm kallar dei alle passord. Å forveksle dei er måten ein nøkkel hamnar i ei sak. Test den resulterande profilen med ei ny tilkopling og éin applikasjonsførespurnad til ein privat ressurs. Ein vellukka tunnel utan ei tilgjengeleg teneste er eit delresultat, og profilen bør ikkje skildrast som ferdig før ressursen òg verkar.

Relaterte artiklar