Mit kell előre beállítani egy felhasználó első VPN-kapcsolata előtt

Egy első VPN-kapcsolat ritkán a tunelen bukik el. Akkor bukik el, amikor egy hétköznapi felhasználó egy nem felügyelt hálózaton olyan utasításokat követ, amelyeket valaki írt, akinek a tanúsítvány már telepítve volt. A profil, a bizalmi lánc és a hitelesítő adat konfiguráció, és mindhárom leszállítható, mielőtt a felhasználó érintetté válik. Annak a felhasználónak négy műveletnek kell maradnia, döntések nélkül bennük. Minden extra lépés, amelyet az átadásban hagy, egy támogatási hívássá válik, amely azzal kezdődik, hogy valaki hangosan felolvas egy párbeszédablakot.

Mit hordoz valójában egy kapcsolatprofil

A VPN-profil nem parancsikon és nem könyvjelző. Ez egy nevesített objektum az operációs rendszer kapcsolattárában, amely tartalmazza a kiszolgáló címét, az alagút típusát, a hitelesítési módszert és gyakran az útvonalakat, a DNS-utótagokat és azokat az indítási szabályokat, amelyek eldöntik, mikor kapcsolódik. Windows alatt ezek a mezők a VPNv2 konfigurációs szolgáltató csomópontjainak felelnek meg, ezért egy profil érkezhet Intune-on, Configuration Manageren, kiépítési csomagon vagy kézzel importált XML-fájlon keresztül.

A kliens ezt az objektumot rögzített sorrendben alkalmazza: érvényesíti a kiszolgáló tanúsítványát a megbízható gyökerekkel szemben, megtárgyalja az alagutat, és csak ezután alkalmazza az útválasztást és a névfeloldást, mielőtt egy alkalmazás hálózatot lát. Ez a sorrend magyarázza a legtöbb jelentést olyan kapcsolatról, amely azt mondja, hogy áll, miközben semmi nem töltődik be: a hitelesítés sikerült, és a DNS vagy az útvonallista az, ami valójában elbukott. A profilt egyetlen, sorrenddel rendelkező objektumként olvassa, ne független kapcsolók halmazaként. Egy hiányzó bizalmi gyökér az első lépésben bukik el, mielőtt bármilyen hitelesítő adatot felajánlanának, ezért általános hibát ad bejelentkezési kérés helyett.

A bizalmi anyag az a mező, amelyet a leggyakrabban kézzel csempésznek be. Az átjárót aláíró CA-tanúsítványnak az első kísérlet előtt jelen kell lennie, és a kiszolgálónév-ellenőrzésnek egyező névvel bekapcsolva kell maradnia; az ellenőrzés kikapcsolása egy teszt kedvéért a hitelesítési problémát csendes lehallgatássá változtatja, amelyet egyetlen felhasználó sem képes észlelni.

A négy döntés, amelyet a felhasználóknak soha nem kellene meghozniuk

A protokoll és az alagút típusa jön először: válasszon platformonként egy támogatott kombinációt, és dokumentálja az átjáró oldalát, mert egy ismerős márkanév nem kompatibilitási nyilatkozat. Ezután a végpont: egyetlen gazdanév, amely nyilvánosan feloldható és illeszkedik az átjáró által bemutatott tanúsítványhoz. A hitelesítés az identitásrendszerhez tartozik, akár tanúsítvány, akár második tényezős felhasználónév, akár mindkettő. Ezek egyike sem felhasználói preferencia, és egyik sem jelenhet meg kérdésként az utasításokban.

A negyedik döntés a hatókör: teljes alagút vagy osztott alagút, és mely előtagok és DNS-utótagok utaznak benne. A belső utótagok nélküli osztott alagút kiszivárogtatja a névfeloldást bármely feloldóhoz, amelyet a helyi hálózat kínál, a helyi erőforrás-terv nélküli teljes alagút pedig elrontja a nyomtatókat és a foglyul ejtő portálokat. Mindkettő a rendszergazda döntése, a felhasználó számára látható hatásokkal, és épp ezért kell a felhasználónak már eldöntve megkapnia őket.

Tartsa a kapcsolat nevét unalmasnak és stabilnak. A felhasználók hangosan felolvassák a támogatásnak, keresik az ügyféllistában, és megjegyzik a jelszó-visszaállítások között; az átnevezés a migráció közepén olyan támogatási csúcsot okoz, amelynek semmi köze ahhoz, hogy működik-e a VPN.

Személyenként vagy eszközönként szállítsa az identitást

A profil nyilvános, a titkos kulcs nem. Gyakori bevezetési hiba egy működő profilt a tanúsítványával együtt exportálni és a fájlt kézről kézre adni, ami minden laptopot egyetlen identitás klónjává tesz, és a visszavonást mindent-vagy-semmit döntéssé változtatja. Ehelyett a támogatott folyamaton keresztül regisztrálja a hitelesítő adatokat: eszközönkénti tanúsítványt a felügyeleti csatornából, vagy felhasználónkénti hitelesítő adatot az identitásszolgáltatótól.

Az eszközalagutak és a felhasználói alagutak különböző pillanatokban hitelesítenek, és ez a különbség dönti el, melyik hitelesítő adatra van szüksége. A bejelentkezés előtt kapcsolódó eszközalagút gépi tanúsítványt és a rendszer számára elérhető profilt igényel. A bejelentkezés után induló felhasználói alagút használhatja a felhasználó saját hitelesítő adatát, és nem kellene rendszergazdai jogokat követelnie. Gép szintű hálózati hozzáférést csak azért hozzáadni, hogy egy kattintás eltűnjön valaki reggeléből, rossz üzlet, mert kitágítja, mit érhet el egy felügyelet nélküli eszköz.

A regisztráció az a hely is, ahol a helyreállítási útvonal eldől. A tanúsítvány megújításának vagy a jelszóváltozásnak el kell érnie az eszközt, miközben az alagút le van állva, ezért a kiépítésnek, az identitásszolgáltatónak és az átjárónak meg kell egyeznie abban, hogyan történik ez; ha a profil javításának egyetlen módja az az alagút, amelyet a profil biztosít, akkor a kulcs a dobozba zárva van.

Igazítsa a szállítási csatornát a klienshez

A natív és a harmadik féltől származó kliensek eltérően szállíthatók. A Windows-profilok VPNv2 ProfileXML-ként szállíthatók Intune-on vagy Configuration Manageren keresztül, de nem minden csomópont érhető el minden felügyeleti felületen, és az útválasztási, DNS- és indítási beállítások eszközönként és Windows-verziónként változnak. Erősítse meg, melyik mező telepíthető, mielőtt érintés nélküli bevezetést ígér, mert a profilbeállítások referenciája olyan beállításokat dokumentál, amelyeket egyes szállítási utak még mindig nem tudnak megadni.

A szállítói kliensek második réteget adnak, mivel a bináris, a profil és a headend házirend különálló összetevők. A Cisco Secure Client például támogatja mind a csomag, mind a profilja előzetes telepítését, és a kliens verzióját össze kell hangolni az átjáró konfigurációjával; csak a csomag telepítése varázslóban hagyja a felhasználót.

Bármelyik csatornát választja, tartson egyetlen igazságforrást a profilhoz. Egy javított profil, amelyet egy régebbi csomag a következő ellenőrzéskor felülír, visszatérő incidens, és a tartós megoldás a verziózott konfiguráció, nem pedig a kézi szerkesztés minden gépen.

Tesztelje az átadást új felhasználóként, majd tesztelje a helyreállítást

Vezessen próbát egy hétköznapi fiókkal olyan eszközön, amely soha nem kapcsolódott, a rendszergazda mentett munkamenete és előre regisztrált tanúsítványa nélkül. Erősítse meg, hogy a profil megjelenik a listában, a bejelentkezési kérés megfelel az utasításoknak, és egy nevesített belső erőforrás megnyílik, majd ellenőrizze a névfeloldást és az útválasztási hatókört ahelyett, hogy egy csatlakozott ikonnál megállna.

Kérdezze le az eszköz profiltárát, hogy a teszt bizonyítékot adjon benyomás helyett.

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

Ezután járja végig azokat az eseményeket, amelyekkel a felhasználók valóban találkoznak: kényszerített jelszó-visszaállítás, megújított tanúsítvány, kiküldött kliensfrissítés és olyan hálózat, amelyet a próbában senki nem használt. Mindegyiknek vagy működnie kell, vagy úgy kell elbuknia, ahogy az utasítások leírják. Próbáljon ki olyan hálózatot is, amely blokkolja a VPN-portot, mert a szállodai Wi-Fi-n tett első kísérlet az a pont, ahol az otthoni siker már nem segít. Minden eredmény mellé jegyezze fel a kliens verzióját és az operációs rendszer buildjét, mert a következő jelentés ezek nélkül érkezik.

Tartsa a felhasználó felé irányuló átadást négy sorban: a kapcsolat neve, az elvárt bejelentkezés, az erőforrás, amely bizonyítja a sikert, és hogy hová küldjék a hiba szövegét. Senkitől nem szabad jelszót vagy exportált kulcsot kérni egy hiba bemutatásához. Az architektúra, a profil belső részei és a helyreállítási eljárás a rendszergazda runbookjába tartozik, abban a kliensverzió mellett tárolva, amellyel tesztelték őket.