Какво да настроим предварително преди първата VPN връзка на потребител

Първата VPN връзка рядко се проваля в тунела. Тя се проваля, когато обикновен потребител в неконтролирана мрежа следва инструкции, написани от някого, който вече е инсталирал сертификата. Профилът, веригата на доверие и идентификационните данни са конфигурация и трите могат да бъдат доставени, преди потребителят да се включи. За него трябва да останат четири действия без решения вътре в тях. Всяка допълнителна стъпка, оставена в предаването, се превръща в обаждане до поддръжката, което започва с четене на диалогов прозорец на глас.

Какво всъщност носи профилът за връзка

VPN профилът не е пряк път или отметка. Той е именуван обект в хранилището за връзки на операционната система, който съдържа адреса на сървъра, типа тунел, метода за удостоверяване и често маршрутите, DNS суфиксите и правилата за задействане, които решават кога да се свърже. В Windows тези полета съответстват на възлите на доставчика на конфигурационна услуга VPNv2, затова един профил може да пристигне през Intune, Configuration Manager, пакет за подготвяне или ръчно импортиран XML файл.

Клиентът прилага този обект в фиксиран ред: проверява сървърния сертификат срещу доверени корени, договаря тунела и едва след това прилага маршрутизация и разрешаване на имена, преди приложение да види мрежа. Този ред обяснява повечето съобщения за връзка, която се представя за вдигната, докато нищо не се зарежда: удостоверяването е минало, а DNS или списъкът с маршрути са се провалили. Четете профила като един обект с последователност, а не като набор от независими превключватели. Липсващ доверен корен се проваля на първата стъпка, преди да бъдат предложени каквито и да е данни, затова дава обща грешка вместо покана за вход.

Доверителният материал е полето, което най-често се внася на ръка. CA сертификатът, който подписва шлюза, трябва да присъства преди първия опит, а проверката на името на сървъра трябва да остане включена със съответстващо име; изключването на проверката, за да мине тест, превръща проблем с удостоверяването в тихо прихващане, което никой потребител не може да забележи.

Четирите избора, които потребителите никога не трябва да правят

Протоколът и типът тунел са първи: изберете една поддържана комбинация за платформа и документирайте страната на шлюза, защото познато търговско име не е изявление за съвместимост. Следва крайната точка: едно име на хост, което се разрешава публично и съответства на сертификата, който шлюзът представя. Удостоверяването принадлежи на системата за самоличност, било то сертификат, потребителско име с втори фактор или и двете. Никое от тях не е предпочитание на потребителя и никое не бива да се появява като въпрос в инструкциите.

Четвъртият избор е обхватът: пълен тунел или разделен тунел и кои префикси и DNS суфикси пътуват вътре. Разделеният тунел без вътрешни суфикси изтича разрешаването на имена към всеки резолвер, който локалната мрежа предложи, а пълният тунел без план за локални ресурси чупи принтери и портали за гост достъп. И двете са решения на администратора с видими за потребителя последици и точно затова потребителят трябва да ги получи вече решени.

Пазете името на връзката скучно и стабилно. Потребителите го четат на глас на поддръжката, търсят го в списъка на клиента и го помнят между смените на парола; преименуването по средата на миграция създава скок в обажданията, който няма нищо общо с това дали VPN работи.

Доставяйте самоличност на човек или на устройство

Профилът е публичен, а частният ключ не е. Честа грешка при внедряване е да се експортира един работещ профил заедно със сертификата му и файлът да се предава от ръка на ръка; така всеки лаптоп става клонинг на една самоличност, а отмяната се превръща в решение всичко-или-нищо. Вместо това регистрирайте данните чрез поддържания процес: сертификат за устройство от канала за управление или данни за потребител от доставчика на самоличност.

Тунелите на устройства и тунелите на потребители се удостоверяват в различни моменти и тази разлика решава кои данни ви трябват. Тунел на устройство, който се свързва преди вход, изисква машинен сертификат и профил, достъпен за системата. Тунел на потребител, който стартира след вход, може да използва собствените данни на потребителя и не бива да изисква администраторски права. Добавянето на мрежов достъп на ниво машина само за да се махне едно кликване от нечия сутрин е лоша сделка, защото разширява какво може да достигне устройство без надзор.

Регистрацията е и мястото, където се решава пътят за възстановяване. Подновяване на сертификат или смяна на парола трябва да достигне до устройството, докато тунелът е свален, затова подготвянето, доставчикът на самоличност и шлюзът трябва да се съгласят как става това; ако единственият начин да поправите профил е през тунела, който профилът дава, ключът е заключен в кутията.

Съобразете канала за доставяне с клиента

Вградените и клиентите на трети страни се доставят различно. Windows профилите могат да се доставят като VPNv2 ProfileXML през Intune или Configuration Manager, но не всеки възел е изложен във всяка повърхност за управление, а маршрутизацията, DNS и настройките за задействане варират според инструмента и версията на Windows. Потвърдете кое поле е разгръщаемо, преди да обещаете внедряване без намеса, защото справката за опциите на профила документира настройки, които някои пътища за доставяне все още не могат да зададат.

Клиентите на доставчици добавят втори слой, тъй като изпълнимият файл, профилът и политиката на главата са отделни артефакти. Cisco Secure Client например поддържа предварително разгръщане както на пакета, така и на профила му, а версията на клиента трябва да се съгласува с конфигурацията на шлюза; инсталирането само на пакета оставя потребителя в съветник.

Който и канал да изберете, пазете един източник на истина за профила. Поправен профил, който по-стара версия презапише при следващата проверка, е повтарящ се инцидент, а трайното решение е конфигурация с версии, а не ръчна редакция на всяка машина.

Тествайте предаването като нов потребител, после тествайте възстановяването

Пилотирайте с обикновен профил на устройство, което никога не се е свързвало, без запазената сесия на администратора и без предварително регистриран сертификат. Потвърдете, че профилът се появява в списъка, че поканата за вход съответства на инструкциите и че именуван вътрешен ресурс се отваря, после проверете разрешаването на имена и обхвата на маршрутите, вместо да спрете на икона за свързаност.

Заявете хранилището с профили на устройството, за да даде тестът доказателство, а не впечатление.

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

После преминете през събитията, които потребителите наистина срещат: принудителна смяна на парола, подновен сертификат, принудително обновяване на клиента и мрежа, която никой в пилота не е използвал. Всяко трябва или да работи, или да се провали по описания в инструкциите начин. Опитайте и мрежа, която блокира VPN порта, защото първият опит в хотелски Wi-Fi е мястото, където домашният успех спира да помага. Записвайте версията на клиента и билда на ОС до всеки резултат, защото следващият доклад ще пристигне без тях.

Дръжте предаването към потребителя в четири реда: името на връзката, очаквания вход, ресурса, който доказва успех, и къде да се изпрати текстът на грешката. Никой не бива да бъде питан за парола или експортиран ключ, за да се демонстрира провал. Архитектурата, вътрешностите на профила и процедурата за възстановяване принадлежат в ръководството на администратора, до версията на клиента, с която са тествани.