Vad som måste förkonfigureras före en användares första VPN-anslutning

En första VPN-anslutning misslyckas sällan i tunneln. Den misslyckas när en vanlig användare, i ett icke hanterat nätverk, följer instruktioner skrivna av någon som redan hade certifikatet installerat. Profilen, förtroendekedjan och autentiseringsuppgiften är konfiguration, och alla tre kan levereras innan användaren är inblandad. Det som återstår för den användaren bör vara fyra åtgärder utan beslut inuti dem. Varje extra steg du lämnar i överlämningen blir ett supportärende som börjar med att någon läser en dialogruta högt.

Vad en anslutningsprofil faktiskt bär

En VPN-profil är ingen genväg och inget bokmärke. Det är ett namngivet objekt i operativsystemets anslutningslager, som innehåller serveradressen, tunneltypen, autentiseringsmetoden och ofta rutterna, DNS-suffixen och utlösarreglerna som avgör när den ansluter. I Windows motsvarar dessa fält noderna i konfigurationstjänsteleverantören VPNv2, vilket är skälet till att en profil kan anlända via Intune, Configuration Manager, ett etableringspaket eller en manuellt importerad XML-fil.

Klienten tillämpar objektet i fast ordning: den validerar serverns certifikat mot betrodda rötter, förhandlar tunneln och tillämpar först därefter routning och namnmatchning innan ett program ser ett nätverk. Den ordningen förklarar de flesta rapporter om en anslutning som säger sig vara uppe medan inget laddas: autentiseringen lyckades och det som faktiskt misslyckades var DNS eller ruttlistan. Läs profilen som ett objekt med en sekvens, inte som en uppsättning oberoende strömbrytare. En saknad betrodd rot misslyckas i första steget, innan några autentiseringsuppgifter erbjuds, och därför ger den ett generellt fel i stället för en inloggningsfråga.

Förtroendematerial är det fält som oftast smugglas in för hand. CA-certifikatet som signerar gatewayen måste finnas före första försöket, och valideringen av servernamnet måste förbli påslagen med ett namn som matchar; att stänga av valideringen för att få ett test att gå igenom förvandlar ett autentiseringsproblem till avlyssning i det tysta som ingen användare kan upptäcka.

De fyra val som användare aldrig borde göra

Protokoll och tunneltyp kommer först: välj en kombination som stöds per plattform och dokumentera gateway-sidan, eftersom ett känt varumärkesnamn inte är en kompatibilitetsdeklaration. Sedan slutpunkten: ett värdnamn som löses offentligt och matchar certifikatet som gatewayen presenterar. Autentisering hör till identitetssystemet, vare sig det handlar om ett certifikat, ett användarnamn med en andra faktor eller båda. Ingen av dessa är en användarpreferens, och ingen borde dyka upp som en fråga i instruktionerna.

Det fjärde valet är omfattning: full tunnel eller delad tunnel, och vilka prefix och DNS-suffix som reser inuti. En delad tunnel utan interna suffix läcker namnmatchning till vilken resolver det lokala nätverket än erbjuder, och en full tunnel utan plan för lokala resurser bryter skrivare och captive-portaler. Båda är administratörsbeslut med synliga effekter för användaren, och just därför borde användaren få dem redan avgjorda.

Håll anslutningens namn tråkigt och stabilt. Användare läser det högt för supporten, letar efter det i en klientlista och minns det mellan lösenordsåterställningar; att byta namn mitt i en migrering skapar en supporttopp som inte har något att göra med om VPN fungerar.

Leverera identitet per person eller per enhet

Profilen är offentlig och den privata nyckeln är det inte. Ett vanligt utrullningsfel är att exportera en fungerande profil tillsammans med sitt certifikat och skicka filen runt, vilket gör varje bärbar dator till en klon av en enda identitet och gör återkallande till ett allt-eller-inget-beslut. Registrera i stället autentiseringsuppgifterna genom den stödda processen: ett certifikat per enhet från hanteringskanalen, eller en autentiseringsuppgift per användare från identitetsleverantören.

Enhetstunnlar och användartunnlar autentiserar vid olika tillfällen, och den skillnaden avgör vilken autentiseringsuppgift du behöver. En enhetstunnel som ansluter före inloggning behöver ett maskincertifikat och en profil som är tillgänglig för systemet. En användartunnel som startar efter inloggning kan använda användarens egen autentiseringsuppgift och borde inte kräva administratörsrättigheter. Att lägga till nätverksåtkomst på maskinnivå bara för att ta bort ett klick från någons morgon är en dålig affär, eftersom det vidgar vad en enhet utan uppsikt kan nå.

Registreringen är också där återställningsvägen avgörs. En certifikatförnyelse eller en lösenordsändring måste nå enheten medan tunneln ligger nere, så etablering, identitetsleverantör och gateway måste komma överens om hur det sker; om det enda sättet att reparera en profil är genom tunneln som profilen själv tillhandahåller, är nyckeln inlåst i lådan.

Anpassa leveranskanalen till klienten

Inbyggda klienter och tredjepartsklienter levereras olika. Windows-profiler kan levereras som VPNv2 ProfileXML via Intune eller Configuration Manager, men inte varje nod är exponerad i varje hanteringsyta, och inställningar för routning, DNS och utlösare varierar efter verktyg och Windows-version. Bekräfta vilket fält som kan distribueras innan du lovar en distribution utan beröring, eftersom referensen för profilalternativ dokumenterar inställningar som vissa leveransvägar fortfarande inte kan sätta.

Leverantörsklienter lägger till ett andra lager, eftersom binären, profilen och headend-policyn är separata artefakter. Cisco Secure Client stöder till exempel fördistribution av både paketet och dess profil, och klientversionen måste samordnas med gateway-konfigurationen; att bara installera paketet lämnar användaren i en guide.

Vilken kanal du än väljer, håll en enda sanningskälla för profilen. En reparerad profil som ett äldre paket skriver över vid nästa kontroll är en återkommande incident, och den hållbara lösningen är versionerad konfiguration i stället för manuell redigering på varje maskin.

Testa överlämningen som ny användare och testa sedan återställning

Kör pilot med ett vanligt konto på en enhet som aldrig har anslutit, utan administratörens sparade session eller förregistrerat certifikat. Bekräfta att profilen visas i listan, att inloggningsfrågan stämmer med instruktionerna och att en namngiven intern resurs öppnas, och kontrollera sedan namnmatchning och routningsomfattning i stället för att stanna vid en ikon som visar anslutning.

Fråga enhetens profillager så att testet ger bevis i stället för ett intryck.

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å sedan igenom händelserna som användare faktiskt möter: en påtvingad lösenordsåterställning, ett förnyat certifikat, en påskjuten klientuppdatering och ett nätverk som ingen i piloten har använt tidigare. Var och en borde antingen fungera eller misslyckas som instruktionerna beskriver. Prova också ett nätverk som blockerar VPN-porten, eftersom det första försöket på hotell-Wi-Fi är där en framgång hemma slutar hjälpa. Anteckna klientversionen och OS-bygget bredvid varje resultat, eftersom nästa rapport kommer att anlända utan dem.

Håll överlämningen till användaren i fyra rader: anslutningens namn, den förväntade inloggningen, resursen som bevisar framgång och vart feltexten ska skickas. Ingen borde bli tillfrågad om ett lösenord eller en exporterad nyckel för att visa ett fel. Arkitekturen, profilens inre och återställningsproceduren hör hemma i administratörens runbook, arkiverad bredvid klientversionen som de testades med.