Wat u vooraf moet configureren voordat een gebruiker voor het eerst VPN gebruikt

Een eerste VPN-verbinding mislukt zelden bij de tunnel. Ze mislukt wanneer een gewone gebruiker op een onbeheerd netwerk instructies volgt die zijn geschreven door iemand die het certificaat al had geïnstalleerd. Het profiel, de vertrouwensketen en de inloggegevens zijn configuratie, en alle drie kunnen worden geleverd voordat de gebruiker erbij betrokken is. Wat voor die gebruiker overblijft, moeten vier handelingen zijn zonder beslissingen erin. Elke extra stap die u in de overdracht laat, wordt een supportgesprek dat begint met iemand die hardop een dialoogvenster voorleest.

Wat een verbindingsprofiel werkelijk bevat

Een VPN-profiel is geen snelkoppeling of bladwijzer. Het is een benoemd object in het verbindingsoverzicht van het besturingssysteem, met het serveradres, het tunneltype, de authenticatiemethode en vaak de routes, DNS-suffixen en triggerregels die bepalen wanneer er verbinding wordt gemaakt. Op Windows komen die velden overeen met de knooppunten van de configuratieserviceprovider VPNv2, waardoor één profiel via Intune, Configuration Manager, een provisioningpakket of een handmatig geïmporteerd XML-bestand kan binnenkomen.

De client past dat object in een vaste volgorde toe: hij valideert het servercertificaat tegen vertrouwde roots, onderhandelt de tunnel en past pas daarna routing en naamresolutie toe voordat een toepassing een netwerk ziet. Die volgorde verklaart de meeste meldingen van een verbinding die zegt dat ze actief is terwijl er niets laadt: de authenticatie slaagde en DNS of de routelijst is wat werkelijk faalde. Lees het profiel als één object met een volgorde, niet als een reeks losse schakelaars. Een ontbrekende vertrouwensroot faalt bij de eerste stap, voordat er inloggegevens worden aangeboden, en daarom levert dat een algemene fout op in plaats van een inlogvraag.

Vertrouwensmateriaal is het veld dat het vaakst met de hand wordt binnengesmokkeld. Het CA-certificaat dat de gateway ondertekent, moet aanwezig zijn vóór de eerste poging, en naamvalidatie van de server moet aan blijven met een naam die overeenkomt; validatie uitzetten om een test te laten slagen verandert een authenticatieprobleem in stille onderschepping die geen gebruiker kan opmerken.

De vier keuzes die gebruikers nooit zouden moeten maken

Protocol en tunneltype komen eerst: kies één ondersteunde combinatie per platform en documenteer de gatewayzijde, want een bekende merknaam is geen compatibiliteitsverklaring. Dan het eindpunt: één hostnaam die publiek resolveert en past bij het certificaat dat de gateway presenteert. Authenticatie hoort bij het identiteitssysteem, of dat nu een certificaat, een gebruikersnaam met een tweede factor of beide is. Geen van deze is een voorkeur van de gebruiker, en geen ervan zou als vraag in de instructies mogen staan.

De vierde keuze is bereik: volledige tunnel of gesplitste tunnel, en welke prefixen en DNS-suffixen daarbinnen reizen. Een gesplitste tunnel zonder interne suffixen lekt naamresolutie naar welke resolver het lokale netwerk ook biedt, en een volledige tunnel zonder plan voor lokale bronnen breekt printers en captive portals. Beide zijn beslissingen van de beheerder met zichtbare effecten voor de gebruiker, en juist daarom zou de gebruiker ze al beslecht moeten krijgen.

Houd de naam van de verbinding saai en stabiel. Gebruikers lezen hem hardop voor aan support, zoeken hem in een clientlijst en onthouden hem tussen wachtwoordresets; hem tijdens een migratie hernoemen veroorzaakt een supportpiek die niets te maken heeft met of de VPN werkt.

Lever identiteit per persoon of per apparaat

Het profiel is openbaar en de privésleutel niet. Een veelgemaakte uitrolfout is één werkend profiel samen met het certificaat te exporteren en het bestand rond te laten gaan, waardoor elke laptop een kloon van één identiteit wordt en intrekking een alles-of-niets-beslissing wordt. Registreer in plaats daarvan inloggegevens via het ondersteunde proces: een certificaat per apparaat uit het beheerkanaal, of een inloggegeven per gebruiker van de identiteitsprovider.

Apparaattunnels en gebruikerstunnels authenticeren op verschillende momenten, en dat verschil bepaalt welke inloggegevens u nodig hebt. Een apparaattunnel die vóór het inloggen verbindt, heeft een machinecertificaat en een voor het systeem beschikbaar profiel nodig. Een gebruikerstunnel die na het inloggen start, kan de eigen inloggegevens van de gebruiker gebruiken en zou geen beheerdersrechten moeten vereisen. Alleen netwerktoegang op machineniveau toevoegen om één klik uit iemands ochtend te halen is een slechte ruil, want het verbreedt wat een onbeheerd apparaat kan bereiken.

Registratie is ook waar het herstelpad wordt besloten. Een certificaatvernieuwing of een wachtwoordwijziging moet het apparaat bereiken terwijl de tunnel platligt, dus provisioning, de identiteitsprovider en de gateway moeten het eens zijn over hoe dat gebeurt; als de enige manier om een profiel te repareren via de tunnel loopt die dat profiel biedt, zit de sleutel in de doos opgesloten.

Stem het leveringskanaal af op de client

Native en externe clients worden verschillend geleverd. Windows-profielen kunnen als VPNv2 ProfileXML via Intune of Configuration Manager worden geleverd, maar niet elk knooppunt is in elk beheeroppervlak beschikbaar, en routing-, DNS- en triggerinstellingen verschillen per hulpmiddel en per Windows-versie. Bevestig welk veld uitrolbaar is voordat u een uitrol zonder aanraking belooft, want de referentie voor profielopties documenteert instellingen die sommige leveringspaden nog steeds niet kunnen zetten.

Leveranciersclients voegen een tweede laag toe, omdat de binary, het profiel en het headend-beleid aparte artefacten zijn. Cisco Secure Client ondersteunt bijvoorbeeld het vooraf uitrollen van zowel het pakket als het profiel, en de clientversie moet met de gatewayconfiguratie worden afgestemd; alleen het pakket installeren laat de gebruiker in een wizard achter.

Welk kanaal u ook kiest, houd één bron van waarheid voor het profiel. Een gerepareerd profiel dat een ouder pakket bij de volgende controle overschrijft, is een terugkerend incident, en de duurzame oplossing is geversioneerde configuratie in plaats van handmatig bewerken op elke machine.

Test de overdracht als nieuwe gebruiker en test daarna herstel

Doe een pilot met een gewoon account op een apparaat dat nooit verbinding heeft gemaakt, zonder de opgeslagen sessie van de beheerder of een vooraf geregistreerd certificaat. Bevestig dat het profiel in de lijst verschijnt, dat de inlogvraag bij de instructies past en dat een benoemde interne bron opent, en controleer daarna naamresolutie en routingbereik in plaats van te stoppen bij een pictogram dat verbonden is.

Vraag de profielopslag van het apparaat op zodat de test bewijs oplevert in plaats van een indruk.

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

Loop daarna de gebeurtenissen door die gebruikers echt tegenkomen: een geforceerde wachtwoordreset, een vernieuwd certificaat, een uitgerolde clientupdate en een netwerk dat niemand in de pilot eerder heeft gebruikt. Elk daarvan zou moeten werken of falen zoals de instructies beschrijven. Probeer ook een netwerk dat de VPN-poort blokkeert, want de eerste poging op hotel-Wi-Fi is waar succes thuis ophoudt te helpen. Noteer de clientversie en de OS-build naast elk resultaat, omdat het volgende rapport zonder die gegevens arriveert.

Houd de overdracht naar de gebruiker in vier regels: de naam van de verbinding, het verwachte inloggen, de bron die succes bewijst en waar de fouttekst heen moet. Niemand zou om een wachtwoord of een geëxporteerde sleutel mogen worden gevraagd om een storing aan te tonen. De architectuur, de binnenkant van het profiel en de herstelprocedure horen in het runbook van de beheerder, opgeborgen naast de clientversie waarmee ze zijn getest.