Hva som må forhåndskonfigureres før en brukers første VPN-tilkobling

En første VPN-tilkobling feiler sjelden i tunnelen. Den feiler når en vanlig bruker, på et ikke-administrert nettverk, følger instruksjoner skrevet av noen som allerede hadde installert sertifikatet. Profilen, tillitskjeden og legitimasjonen er konfigurasjon, og alle tre kan leveres før brukeren er involvert. Det som gjenstår for den brukeren, bør være fire handlinger uten beslutninger inni seg. Hvert ekstra trinn du lar ligge i overleveringen, blir en støttesamtale som begynner med at noen leser en dialogboks høyt.

Hva en tilkoblingsprofil faktisk inneholder

En VPN-profil er ikke en snarvei eller et bokmerke. Det er et navngitt objekt i operativsystemets tilkoblingslager, som holder serveradressen, tunneltypen, autentiseringsmetoden og ofte rutene, DNS-suffiksene og utløserreglene som avgjør når den kobler til. På Windows svarer disse feltene til nodene i konfigurasjonstjenesteleverandøren VPNv2, og derfor kan én profil komme inn via Intune, Configuration Manager, en klargjøringspakke eller en manuelt importert XML-fil.

Klienten bruker dette objektet i fast rekkefølge: den validerer serverens sertifikat mot klarerte røtter, forhandler tunnelen og bruker først deretter ruting og navneoppslag før en applikasjon ser et nettverk. Den rekkefølgen forklarer de fleste rapportene om en tilkobling som sier den er oppe mens ingenting lastes: autentiseringen lyktes, og DNS eller ruttelisten er det som faktisk feilet. Les profilen som ett objekt med en sekvens, ikke som et sett uavhengige brytere. En manglende tillitsrot feiler i første trinn, før noen legitimasjon tilbys, og derfor gir den en generisk feil i stedet for en påloggingsforespørsel.

Tillitsmateriale er feltet som oftest smugles inn for hånd. CA-sertifikatet som signerer gatewayen, må være til stede før det første forsøket, og validering av servernavn må forbli på med et navn som passer; å slå av validering for å få en test til å bestå gjør et autentiseringsproblem om til avlytting i det skjulte som ingen bruker kan oppdage.

De fire valgene brukere aldri bør ta

Protokoll og tunneltype kommer først: velg én støttet kombinasjon per plattform og dokumenter gateway-siden, fordi et kjent merkenavn ikke er en kompatibilitetserklæring. Deretter endepunktet: ett vertsnavn som løses offentlig og passer til sertifikatet gatewayen presenterer. Autentisering hører til identitetssystemet, enten det betyr et sertifikat, et brukernavn med en annen faktor eller begge. Ingen av disse er en brukerpreferanse, og ingen bør dukke opp som et spørsmål i instruksjonene.

Det fjerde valget er omfang: full tunnel eller delt tunnel, og hvilke prefikser og DNS-suffikser som reiser inni. En delt tunnel uten interne suffikser lekker navneoppslag til den resolveren det lokale nettverket tilbyr, og en full tunnel uten plan for lokale ressurser ødelegger skrivere og captive-portaler. Begge er administratorbeslutninger med synlige effekter for brukeren, og nettopp derfor bør brukeren få dem allerede avgjort.

Hold navnet på tilkoblingen kjedelig og stabilt. Brukere leser det høyt for støtte, leter etter det i en klientliste og husker det mellom tilbakestillinger av passord; å gi det nytt navn midt i en migrering skaper en støttevekst som ikke har noe med om VPN-en virker å gjøre.

Lever identitet per person eller per enhet

Profilen er offentlig og den private nøkkelen er det ikke. En vanlig utrullingsfeil er å eksportere én fungerende profil sammen med sertifikatet og sende filen rundt, noe som gjør hver bærbar PC til en klone av én identitet og gjør tilbakekalling til en alt-eller-ingenting-beslutning. Registrer legitimasjonen gjennom den støttede prosessen i stedet: et sertifikat per enhet fra administrasjonskanalen, eller en legitimasjon per bruker fra identitetsleverandøren.

Enhetstunneler og brukertunneler autentiserer på forskjellige tidspunkter, og den forskjellen avgjør hvilken legitimasjon du trenger. En enhetstunnel som kobler til før pålogging, trenger et maskinsertifikat og en profil som er tilgjengelig for systemet. En brukertunnel som starter etter pålogging, kan bruke brukerens egen legitimasjon og bør ikke kreve administratorrettigheter. Å legge til nettverkstilgang på maskinnivå bare for å fjerne ett klikk fra noens morgen er en dårlig handel, fordi det utvider hva en enhet uten tilsyn kan nå.

Registreringen er også der gjenopprettingsveien avgjøres. En sertifikatfornyelse eller en passordendring må nå enheten mens tunnelen ligger nede, så klargjøring, identitetsleverandør og gateway må bli enige om hvordan det skjer; hvis den eneste måten å reparere en profil på er gjennom tunnelen profilen selv leverer, er nøkkelen låst inne i boksen.

Tilpass leveringskanalen til klienten

Innebygde klienter og tredjepartsklienter leveres forskjellig. Windows-profiler kan leveres som VPNv2 ProfileXML via Intune eller Configuration Manager, men ikke hver node er eksponert i hver administrasjonsflate, og ruting, DNS og utløserinnstillinger varierer etter verktøy og Windows-versjon. Bekreft hvilket felt som kan rulles ut før du lover en utrulling uten berøring, fordi referansen for profilvalg dokumenterer innstillinger som noen leveringsveier fortsatt ikke kan sette.

Leverandørklienter legger til et andre lag, siden binæren, profilen og headend-policyen er separate artefakter. Cisco Secure Client støtter for eksempel forhåndsutrulling av både pakken og profilen, og klientversjonen må koordineres med gateway-konfigurasjonen; å installere bare pakken lar brukeren stå igjen i en veiviser.

Uansett hvilken kanal du velger, hold én sannhetskilde for profilen. En reparert profil som en eldre pakke overskriver ved neste sjekk, er en tilbakevendende hendelse, og den varige løsningen er versjonert konfigurasjon i stedet for manuell redigering på hver maskin.

Test overleveringen som en ny bruker, og test deretter gjenoppretting

Kjør pilot med en vanlig konto på en enhet som aldri har koblet til, uten administratorens lagrede økt eller forhåndsregistrert sertifikat. Bekreft at profilen vises i listen, at påloggingsforespørselen passer til instruksjonene og at en navngitt intern ressurs åpnes, og kontroller deretter navneoppslag og rutingomfang i stedet for å stoppe ved et ikon som viser tilkobling.

Spør enhetens profillager slik at testen gir bevis i stedet for et inntrykk.

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å deretter gjennom hendelsene brukerne faktisk møter: en tvungen tilbakestilling av passord, et fornyet sertifikat, en presset klientoppdatering og et nettverk ingen i piloten har brukt før. Hver av dem bør enten virke eller feile slik instruksjonene beskriver. Prøv også et nettverk som blokkerer VPN-porten, fordi det første forsøket på hotell-Wi-Fi er der en suksess hjemme slutter å hjelpe. Noter klientversjonen og OS-bygget ved siden av hvert resultat, siden neste rapport vil komme uten dem.

Hold overleveringen til brukeren i fire linjer: navnet på tilkoblingen, den forventede påloggingen, ressursen som beviser suksess og hvor feilteksten skal sendes. Ingen bør bli spurt om et passord eller en eksportert nøkkel for å demonstrere en feil. Arkitekturen, profilens indre og gjenopprettingsprosedyren hører hjemme i administratorens runbook, arkivert ved siden av klientversjonen de ble testet med.