Hvad du skal forudkonfigurere før en brugers første VPN-forbindelse

En første VPN-forbindelse fejler sjældent i tunnelen. Den fejler, når en almindelig bruger på et ikke-styret netværk følger instruktioner skrevet af en, der allerede havde certifikatet installeret. Profilen, tillidskæden og legitimationsoplysningen er konfiguration, og alle tre kan leveres, før brugeren er involveret. Det, der er tilbage til den bruger, bør være fire handlinger uden beslutninger i sig. Hvert ekstra trin, du efterlader i overdragelsen, bliver et supportopkald, der begynder med, at nogen læser en dialogboks højt.

Hvad en forbindelsesprofil egentlig indeholder

En VPN-profil er ikke en genvej eller et bogmærke. Det er et navngivet objekt i operativsystemets forbindelseslager, som rummer serveradressen, tunneltypen, godkendelsesmetoden og ofte ruterne, DNS-suffikserne og udløserreglerne, der afgør, hvornår den forbinder. På Windows svarer disse felter til noderne i konfigurationsudbyderen VPNv2, og derfor kan én profil ankomme via Intune, Configuration Manager, en provisioneringspakke eller en manuelt importeret XML-fil.

Klienten anvender dette objekt i en fast rækkefølge: den validerer servercertifikatet mod betroede rødder, forhandler tunnelen og anvender først derefter routing og navneopløsning, før en applikation ser et netværk. Den rækkefølge forklarer de fleste rapporter om en forbindelse, der siger, at den er oppe, mens intet indlæses: godkendelsen lykkedes, og DNS eller ruttelisten er det, der faktisk fejlede. Læs profilen som ét objekt med en sekvens i stedet for et sæt uafhængige kontakter. En manglende tillidsrod fejler i første trin, før nogen legitimationsoplysning tilbydes, og derfor giver den en generisk fejl i stedet for en logonprompt.

Tillidsmateriale er det felt, der oftest smugles ind manuelt. Det CA-certifikat, der signerer gatewayen, skal være til stede før det første forsøg, og validering af servernavn skal forblive slået til med et navn, der matcher; at slå validering fra for at få en test til at bestå forvandler et godkendelsesproblem til aflytning i det skjulte, som ingen bruger kan opdage.

De fire valg, brugerne aldrig bør træffe

Protokol og tunneltype kommer først: vælg én understøttet kombination pr. platform, og dokumentér gateway-siden, fordi et velkendt mærkenavn ikke er en kompatibilitetserklæring. Dernæst endepunktet: ét værtsnavn, der slår op offentligt og matcher det certifikat, gatewayen præsenterer. Godkendelse hører til identitetssystemet, hvad enten det betyder et certifikat, et brugernavn med en anden faktor eller begge. Ingen af disse er en brugerpræference, og ingen bør fremstå som et spørgsmål i instruktionerne.

Det fjerde valg er omfang: fuld tunnel eller delt tunnel, og hvilke præfikser og DNS-suffikser der rejser indeni. En delt tunnel uden interne suffikser lækker navneopløsning til den resolver, det lokale netværk nu tilbyder, og en fuld tunnel uden en plan for lokale ressourcer ødelægger printere og captive-portaler. Begge er administratorens beslutninger med synlige effekter for brugeren, og netop derfor bør brugeren modtage dem allerede afklaret.

Hold forbindelsens navn kedeligt og stabilt. Brugerne læser det højt for support, leder efter det på en klientliste og husker det mellem nulstillinger af adgangskoden; at omdøbe det midt i en migrering skaber en stigning i supporten, som intet har at gøre med, om VPN'en virker.

Lever identitet per person eller per enhed

Profilen er offentlig, og den private nøgle er det ikke. En almindelig udrulningsfejl er at eksportere én fungerende profil sammen med dens certifikat og sende filen rundt, hvilket gør hver bærbar til en klon af én identitet og gør tilbagekaldelse til en alt-eller-intet-beslutning. Tilmeld i stedet legitimationsoplysninger gennem den understøttede proces: et certifikat pr. enhed fra styringskanalen eller en legitimationsoplysning pr. bruger fra identitetsudbyderen.

Enhedstunneler og brugertunneler godkender på forskellige tidspunkter, og den forskel afgør, hvilken legitimationsoplysning du har brug for. En enhedstunnel, der forbinder før logon, kræver et maskincertifikat og en profil, der er tilgængelig for systemet. En brugertunnel, der starter efter logon, kan bruge brugerens egen legitimationsoplysning og bør ikke kræve administratorrettigheder. At tilføje netværksadgang på maskinniveau bare for at fjerne et klik fra nogens morgen er en dårlig handel, fordi den udvider, hvad en enhed uden opsyn kan nå.

Tilmelding er også der, hvor gendannelsesvejen bliver besluttet. En certifikatfornyelse eller en adgangskodeændring skal nå enheden, mens tunnelen ligger ned, så provisioning, identitetsudbyderen og gatewayen skal blive enige om, hvordan det sker; hvis den eneste måde at reparere en profil er gennem den tunnel, profilen selv leverer, er nøglen låst inde i kassen.

Tilpas leveringskanalen til klienten

Indbyggede klienter og tredjepartsklienter leveres forskelligt. Windows-profiler kan leveres som VPNv2 ProfileXML via Intune eller Configuration Manager, men ikke hver node er eksponeret i hver styringsflade, og routing, DNS og udløserindstillinger varierer efter værktøj og efter Windows-version. Bekræft, hvilket felt der kan udrulles, før du lover en nulberøringsudrulning, fordi reference for profilindstillinger dokumenterer indstillinger, som nogle leveringsveje stadig ikke kan sætte.

Leverandørklienter tilføjer et andet lag, fordi binæren, profilen og headend-politikken er separate artefakter. Cisco Secure Client understøtter for eksempel forudlevering af både pakken og dens profil, og klientversionen skal koordineres med gateway-konfigurationen; installation af pakken alene efterlader brugeren i en guide.

Uanset hvilken kanal du vælger, så hold én sandhedskilde for profilen. En repareret profil, som en ældre pakke overskriver ved næste check-in, er en tilbagevendende hændelse, og den holdbare løsning er versioneret konfiguration i stedet for en manuel redigering på hver maskine.

Test overdragelsen som en ny bruger, og test derefter gendannelse

Kør pilot med en almindelig konto på en enhed, der aldrig har forbundet, uden administratorens gemte session eller forudtilmeldte certifikat. Bekræft, at profilen vises på listen, at logonprompten matcher instruktionerne, og at en navngivet intern ressource åbner, og kontroller derefter navneopløsning og routingomfang i stedet for at stoppe ved et ikon, der viser forbindelse.

Forespørg enhedens profillager, så testen giver beviser i stedet for et indtryk.

Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType, AuthenticationMethod, SplitTunneling
Get-VpnConnection -Name "Corp VPN" | Format-List
Test-NetConnection intranet.example.com -Port 443

Gå derefter gennem de hændelser, brugerne faktisk møder: en tvungen nulstilling af adgangskoden, et fornyet certifikat, en skubbet klientopdatering og et netværk, som ingen i piloten har brugt før. Hver af dem bør enten virke eller fejle på den måde, instruktionerne beskriver. Prøv også et netværk, der blokerer VPN-porten, fordi det første forsøg på hotel-Wi-Fi er der, hvor en succes derhjemme holder op med at hjælpe. Notér klientversionen og OS-buildet ved siden af hvert resultat, da den næste rapport vil ankomme uden dem.

Hold overdragelsen til brugeren i fire linjer: forbindelsens navn, det forventede logon, den ressource, der beviser succes, og hvor fejlteksten skal sendes hen. Ingen bør blive spurgt om en adgangskode eller en eksporteret nøgle for at demonstrere en fejl. Arkitekturen, profilens indre og gendannelsesproceduren hører til administratorens runbook, arkiveret ved siden af den klientversion, de blev testet med.