Kva som må førehandskonfigurerast før den første VPN-tilkoplinga til ein brukar

Ei første VPN-tilkopling feilar sjeldan i tunnelen. Ho feilar når ein vanleg brukar, på eit ikkje-administrert nettverk, følgjer instruksjonar skrivne av nokon som allereie hadde installert sertifikatet. Profilen, tillitskjeda og legitimasjonen er konfigurasjon, og alle tre kan leverast før brukaren er involvert. Det som står att for den brukaren, bør vere fire handlingar utan avgjerder inni seg. Kvart ekstra steg du lèt liggje i overleveringa, blir ein støttesamtale som byrjar med at nokon les ein dialogboks høgt.

Kva ein tilkoplingsprofil faktisk inneheld

Ein VPN-profil er ikkje ein snarveg eller eit bokmerke. Det er eit namngjeve objekt i tilkoplingslageret til operativsystemet, som held serveradressa, tunneltypen, autentiseringsmetoden og ofte rutene, DNS-suffiksa og utløysarreglane som avgjer når han koplar til. På Windows svarar desse felta til nodane i konfigurasjonstenesteleverandøren VPNv2, og difor kan éin profil kome inn via Intune, Configuration Manager, ein klargjeringspakke eller ei manuelt importert XML-fil.

Klienten brukar dette objektet i fast rekkjefølgje: han validerer sertifikatet til serveren mot klarerte røter, forhandlar tunnelen og brukar først deretter ruting og namneoppslag før ein applikasjon ser eit nettverk. Den rekkjefølgja forklarer dei fleste rapportane om ei tilkopling som seier ho er oppe medan ingenting lastar: autentiseringa lukkast, og DNS eller ruttelista er det som faktisk feila. Les profilen som eitt objekt med ein sekvens, ikkje som eit sett uavhengige brytarar. Ei manglande tillitsrot feilar i første steg, før nokon legitimasjon blir tilboden, og difor gir ho ein generisk feil i staden for ein påloggingsforespurnad.

Tillitsmateriale er feltet som oftast blir smugla inn for hand. CA-sertifikatet som signerer gatewayen, må vere til stades før det første forsøket, og validering av servernamn må halde fram med å vere på med eit namn som passar; å slå av validering for å få ein test til å gå gjennom gjer eit autentiseringsproblem om til avlytting i det skjulte som ingen brukar kan oppdage.

Dei fire vala brukarar aldri bør ta

Protokoll og tunneltype kjem først: vel éin støtta kombinasjon per plattform og dokumenter gateway-sida, fordi eit kjent merkenamn ikkje er ei kompatibilitetsfråsegn. Deretter endepunktet: eitt vertsnamn som løyser seg offentleg og passar til sertifikatet gatewayen presenterer. Autentisering høyrer til identitetssystemet, anten det tyder eit sertifikat, eit brukarnamn med ein annan faktor eller begge. Ingen av desse er ein brukarpreferanse, og ingen bør dukke opp som eit spørsmål i instruksjonane.

Det fjerde valet er omfang: full tunnel eller delt tunnel, og kva prefiks og DNS-suffiks som reiser inni. Ein delt tunnel utan interne suffiks lekk namneoppslag til den resolvaren det lokale nettverket tilbyr, og ein full tunnel utan plan for lokale ressursar øydelegg skrivarar og captive-portalar. Begge er administratoravgjerder med synlege effektar for brukaren, og nettopp difor bør brukaren få dei allereie avgjorde.

Hald namnet på tilkoplinga keisamt og stabilt. Brukarar les det høgt for støtte, leitar etter det i ei klientliste og hugsar det mellom tilbakestillingar av passord; å gje det nytt namn midt i ein migrasjon skaper ein støttevekst som ikkje har noko med om VPN-en verkar å gjere.

Lever identitet per person eller per eining

Profilen er offentleg og den private nøkkelen er det ikkje. Ein vanleg utrullingsfeil er å eksportere éin fungerande profil saman med sertifikatet og sende fila rundt, noko som gjer kvar berbar PC til ein klone av éin identitet og gjer tilbakekalling til ei alt-eller-ingen-avgjerd. Registrer legitimasjonen gjennom den støtta prosessen i staden: eit sertifikat per eining frå administrasjonskanalen, eller ein legitimasjon per brukar frå identitetsleverandøren.

Einingstunnelar og brukartunnelar autentiserer på ulike tidspunkt, og den skilnaden avgjer kva legitimasjon du treng. Ein einingstunnel som koplar til før pålogging, treng eit maskinsettifikat og ein profil som er tilgjengeleg for systemet. Ein brukartunnel som startar etter pålogging, kan bruke brukaren sin eigen legitimasjon og bør ikkje krevje administratorrettar. Å leggje til nettverkstilgang på maskinnivå berre for å fjerne eitt klikk frå morgonen til nokon er ein dårleg handel, fordi det utvidar kva ei eining utan tilsyn kan nå.

Registreringa er også der gjenopprettingsvegen blir avgjord. Ei sertifikatfornying eller ei passordendring må nå eininga medan tunnelen ligg nede, så klargjering, identitetsleverandør og gateway må bli samde om korleis det skjer; viss den einaste måten å reparere ein profil på er gjennom tunnelen profilen sjølv leverer, er nøkkelen låst inne i boksen.

Tilpass leveringskanalen til klienten

Innebygde klientar og tredjepartsklientar blir leverte ulikt. Windows-profilar kan leverast som VPNv2 ProfileXML via Intune eller Configuration Manager, men ikkje kvar node er eksponert i kvar administrasjonsflate, og ruting, DNS og utløysarinnstillingar varierer etter verktøy og Windows-versjon. Stadfest kva felt som kan rullast ut før du lovar ein utrulling utan berøring, fordi referansen for profilval dokumenterer innstillingar som nokre leveringsvegar framleis ikkje kan setje.

Leverandørklientar legg til eit andre lag, sidan binæren, profilen og headend-policyen er separate artefakt. Cisco Secure Client støttar til dømes førehandsutrulling av både pakken og profilen, og klientversjonen må koordinerast med gateway-konfigurasjonen; å installere berre pakken lèt brukaren stå att i ein vegvisar.

Kva kanal du enn vel, hald éi sanningkjelde for profilen. Ein reparert profil som ein eldre pakke overskriv ved neste sjekk, er ei tilbakevendande hending, og den varige løysinga er versjonert konfigurasjon i staden for manuell redigering på kvar maskin.

Test overleveringa som ny brukar, og test deretter gjenoppretting

Køyr pilot med ein vanleg konto på ei eining som aldri har kopla til, utan den lagra økta til administratoren eller eit førehandsregistrert sertifikat. Stadfest at profilen visest i lista, at påloggingsforespurnaden passar til instruksjonane og at ein namngjeven intern ressurs opnar seg, og kontroller deretter namneoppslag og rutingomfang i staden for å stoppe ved eit ikon som viser tilkopling.

Spør profillageret til eininga slik at testen gir prov i staden for eit 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 hendingane brukarane faktisk møter: ei tvinga tilbakestilling av passord, eit fornya sertifikat, ein pressa klientoppdatering og eit nettverk ingen i piloten har brukt før. Kvar av dei bør anten verke eller feile slik instruksjonane skildrar. Prøv også eit nettverk som blokkerer VPN-porten, fordi det første forsøket på hotell-Wi-Fi er der ein suksess heime sluttar å hjelpe. Noter klientversjonen og OS-bygget ved sida av kvart resultat, sidan neste rapport vil kome utan dei.

Hald overleveringa til brukaren i fire linjer: namnet på tilkoplinga, den forventa pålogginga, ressursen som provar suksess og kvar feilteksten skal sendast. Ingen bør bli spurd om eit passord eller ein eksportert nøkkel for å demonstrere ein feil. Arkitekturen, det indre av profilen og gjenopprettingsprosedyren høyrer heime i runboka til administratoren, arkivert ved sida av klientversjonen dei blei testa med.