Ce trebuie preconfigurat înainte de prima conexiune VPN a unui utilizator

O primă conexiune VPN eșuează rareori la tunel. Ea eșuează când un utilizator obișnuit, într-o rețea neadministrată, urmează instrucțiuni scrise de cineva care avea deja certificatul instalat. Profilul, lanțul de încredere și acreditarea sunt configurație, iar toate trei pot fi livrate înainte ca utilizatorul să fie implicat. Ce rămâne pentru acel utilizator ar trebui să fie patru acțiuni fără decizii în interior. Fiecare pas suplimentar lăsat în predare devine un apel la suport care începe cu cineva citind cu voce tare o casetă de dialog.

Ce poartă de fapt un profil de conexiune

Un profil VPN nu este o scurtătură sau un semn de carte. Este un obiect cu nume din depozitul de conexiuni al sistemului de operare, care conține adresa serverului, tipul de tunel, metoda de autentificare și adesea rutele, sufixele DNS și regulile de declanșare care decid când se conectează. În Windows aceste câmpuri corespund nodurilor furnizorului de serviciu de configurare VPNv2, motiv pentru care un profil poate ajunge prin Intune, Configuration Manager, un pachet de provizionare sau un fișier XML importat manual.

Clientul aplică acel obiect într-o ordine fixă: validează certificatul serverului față de rădăcini de încredere, negociază tunelul și abia apoi aplică rutarea și rezolvarea numelor înainte ca o aplicație să vadă o rețea. Această ordine explică majoritatea rapoartelor despre o conexiune care spune că este activă în timp ce nimic nu se încarcă: autentificarea a reușit, iar DNS sau lista de rute este ceea ce a eșuat de fapt. Citiți profilul ca un singur obiect cu o secvență, nu ca un set de comutatoare independente. O rădăcină de încredere lipsă eșuează la primul pas, înainte de a fi oferită vreo acreditare, și de aceea produce o eroare generică în loc de o cerere de autentificare.

Materialul de încredere este câmpul cel mai des strecurat manual. Certificatul CA care semnează gateway-ul trebuie să fie prezent înainte de prima încercare, iar validarea numelui serverului trebuie să rămână activă cu un nume care se potrivește; dezactivarea validării pentru ca un test să treacă transformă o problemă de autentificare într-o interceptare silențioasă pe care niciun utilizator nu o poate detecta.

Cele patru alegeri pe care utilizatorii nu ar trebui să le facă niciodată

Protocolul și tipul de tunel vin primele: alegeți o singură combinație acceptată pe platformă și documentați partea de gateway, pentru că un nume de marcă cunoscut nu este o declarație de compatibilitate. Urmează punctul final: un singur nume de gazdă care se rezolvă public și corespunde certificatului prezentat de gateway. Autentificarea aparține sistemului de identitate, fie că este un certificat, un nume de utilizator cu un al doilea factor sau ambele. Niciuna dintre acestea nu este o preferință a utilizatorului și niciuna nu ar trebui să apară ca întrebare în instrucțiuni.

A patra alegere este sfera: tunel complet sau tunel divizat, și ce prefixe și sufixe DNS călătoresc în interior. Un tunel divizat fără sufixe interne scurge rezolvarea numelor către orice rezolvator oferă rețeaua locală, iar un tunel complet fără un plan pentru resursele locale strică imprimantele și portalurile captive. Ambele sunt decizii ale administratorului cu efecte vizibile pentru utilizator, și tocmai de aceea utilizatorul ar trebui să le primească deja stabilite.

Păstrați numele conexiunii plictisitor și stabil. Utilizatorii îl citesc cu voce tare la suport, îl caută într-o listă a clientului și îl rețin între resetări de parolă; redenumirea lui în mijlocul unei migrări creează un vârf de suport care nu are nimic de-a face cu funcționarea VPN-ului.

Livrați identitatea pe persoană sau pe dispozitiv

Profilul este public, iar cheia privată nu. O greșeală frecventă de implementare este să exportați un profil funcțional împreună cu certificatul său și să plimbați fișierul din mână în mână, ceea ce face din fiecare laptop o clonă a unei singure identități și transformă revocarea într-o decizie totul-sau-nimic. Înregistrați în schimb acreditările prin procesul acceptat: un certificat pe dispozitiv din canalul de administrare sau o acreditare pe utilizator de la furnizorul de identitate.

Tunelurile de dispozitiv și tunelurile de utilizator se autentifică în momente diferite, iar această diferență decide de ce acreditare aveți nevoie. Un tunel de dispozitiv care se conectează înainte de autentificare are nevoie de un certificat de mașină și de un profil disponibil pentru sistem. Un tunel de utilizator care pornește după autentificare poate folosi acreditarea proprie a utilizatorului și nu ar trebui să ceară drepturi de administrator. Adăugarea accesului la rețea la nivel de mașină doar pentru a elimina un clic din dimineața cuiva este un schimb prost, pentru că lărgește la ce poate ajunge un dispozitiv nesupravegheat.

Înregistrarea este și locul unde se decide calea de recuperare. Reînnoirea unui certificat sau schimbarea parolei trebuie să ajungă la dispozitiv în timp ce tunelul este jos, așa că provizionarea, furnizorul de identitate și gateway-ul trebuie să cadă de acord asupra modului în care se întâmplă; dacă singurul mod de a repara un profil este prin tunelul pe care acel profil îl oferă, cheia este încuiată în cutie.

Potriviți canalul de livrare cu clientul

Clienții nativi și cei terți se livrează diferit. Profilele Windows pot fi livrate ca VPNv2 ProfileXML prin Intune sau Configuration Manager, dar nu fiecare nod este expus pe fiecare suprafață de administrare, iar setările de rutare, DNS și declanșare variază după instrument și după versiunea Windows. Confirmați ce câmp este implementabil înainte de a promite o implementare fără atingere, pentru că referința opțiunilor de profil documentează setări pe care unele căi de livrare încă nu le pot stabili.

Clienții furnizorilor adaugă un al doilea strat, deoarece binarul, profilul și politica de headend sunt artefacte separate. Cisco Secure Client, de exemplu, acceptă preimplementarea atât a pachetului, cât și a profilului său, iar versiunea clientului trebuie coordonată cu configurația gateway-ului; instalarea doar a pachetului lasă utilizatorul într-un asistent.

Indiferent de canalul ales, păstrați o singură sursă de adevăr pentru profil. Un profil reparat pe care un pachet mai vechi îl suprascrie la următoarea verificare este un incident recurent, iar soluția durabilă este configurația versionată, nu editarea manuală pe fiecare mașină.

Testați predarea ca utilizator nou, apoi testați recuperarea

Faceți un pilot cu un cont obișnuit pe un dispozitiv care nu s-a conectat niciodată, fără sesiunea salvată a administratorului sau certificatul preînregistrat. Confirmați că profilul apare în listă, că solicitarea de autentificare corespunde instrucțiunilor și că o resursă internă cu nume se deschide, apoi verificați rezolvarea numelor și sfera rutării în loc să vă opriți la o pictogramă conectată.

Interogați depozitul de profile al dispozitivului pentru ca testul să producă dovezi și nu o impresie.

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

Apoi parcurgeți evenimentele pe care utilizatorii le întâlnesc cu adevărat: o resetare forțată a parolei, un certificat reînnoit, o actualizare de client împinsă și o rețea pe care nimeni din pilot nu a folosit-o înainte. Fiecare ar trebui fie să funcționeze, fie să eșueze așa cum descriu instrucțiunile. Încercați și o rețea care blochează portul VPN, pentru că prima încercare pe Wi-Fi de hotel este locul unde succesul de acasă încetează să ajute. Notați versiunea clientului și build-ul sistemului lângă fiecare rezultat, fiindcă următorul raport va sosi fără ele.

Păstrați predarea către utilizator în patru rânduri: numele conexiunii, autentificarea așteptată, resursa care dovedește succesul și unde se trimite textul erorii. Nimeni nu ar trebui întrebat de o parolă sau de o cheie exportată pentru a demonstra o defecțiune. Arhitectura, interiorul profilului și procedura de recuperare aparțin manualului administratorului, arhivate lângă versiunea clientului cu care au fost testate.