Един потребител не може да влезе във VPN: подредена диагностика
Изпълнете проверките по ред: точен етап на отказ, събитие за идентичност, една разрешена размяна, после политика. Спрете на първата стъпка, която не издържа.
Когато един човек не може да се свърже, а останалата част от екипа продължава да работи, полезният въпрос не е какво е счупено, а кой слой не се е съгласил. Влизането е верига: клиентът стартира, шлюзът отговаря, идентичност се заявява, втори фактор се удовлетворява, политика се оценява и едва тогава трафикът тече. Прекъсване навсякъде във веригата стига до вас като едно и също изречение от потребителя, затова първата задача е да намерите връзката, която наистина се е провалила.
Отнасяйте се към доклада като към отправна точка, а не като към диагноза. Проверките по-долу вървят от най-евтината, и всяка е написана така, че да приключи разследването, когато се провали.
Определете етапа и времевата марка
Запишете четири неща, преди да пипате каквато и да е конфигурация: клиента и неговата версия, точната формулировка на екрана, минутата на опита и мрежата, в която е бил човекът. Формулировката носи реална информация, защото отхвърлени идентификационни данни, шлюз, който не отговаря, и завършен вход, който все още не може да отвори вътрешна страница са три различни проблема с три различни отговорника. Отбележете дали клиентът е създал локален ред в журнала, защото клиент, който никога не е изпратил пакет, няма какво да добави към търсене от страна на сървъра. Със записана времева марка всяка следваща заявка става справка, а не лов.
Спрете да гадаете пароли на този етап. Където акаунтът има ограничение за повторни опити, серия от бързи опити може да го заключи и да добави втора, изкуствена повреда върху истинската. Запишете колко опита вече са направени, за да не се сбърка заключването по-късно с нов симптом. Заключеният акаунт също ви отнема способността да различите грешна парола от отхвърлена политика, тъй като и двете пристигат като отказ.
Прочетете събитието за идентичност за този единствен опит
Помолете администратора да извади записа за удостоверяване, който съвпада със записаната от вас минута. При внедряване на Windows NPS ръководството на Microsoft за отстраняване на проблеми с NPS документира събитие за отхвърляне 6273 заедно с кода за причина, който го придружава, и това обикновено разделя непознат потребител, лоши идентификационни данни, несъответствие в политиката и повикване, прекъснато по несвързана причина.
Празният резултат също е информация. Ако нищо не е достигнало до услугата за идентичност, опитът е умрял по-рано: остарял адрес на шлюза в профила, слушател, до който клиентът не може да стигне, или хост, изведен от експлоатация, докато профилът е продължавал да живее. Ако записът съществува и съобщава за успех, идентификационните данни не са проблемът и спорът се мести към оторизация или към маршрутизиране зад шлюза. Тези два изхода сочат в противоположни посоки, затова търсенето в журнала трябва да се случи, преди някой да преинсталира клиент.
Пазете кода за причина в тикета. Това едно поле превръща следващото събитие в петминутна справка, а не в повторно разследване. Сдвоете го с версията на клиента, защото код, който се появява в една сборка, е различен разговор от код, който се появява във всяка сборка.
Променяйте едно условие наведнъж, в рамките на политиката
Изкушението е да преинсталирате клиента, да нулирате паролата и да преместите лаптопа в друга мрежа с едно минаване. Това понякога поправя симптома и винаги унищожава доказателствата. Изберете вместо това една разрешена размяна: същият човек на второ регистрирано устройство или одобрена тестова идентичност на същото устройство. Всяка размяна отговаря точно на един въпрос, така че успехът стеснява повредата до страната, която сте сменили, вместо да обвинява VPN като цяло.
Не вземайте назаем идентификационните данни на колега за това сравнение. Използвайте тестова идентичност чрез поддържания процес и никога не копирайте ключ на устройство или не пропускайте регистрацията, защото така ще е по-бързо. Където политиката забранява размяна напълно, това ограничение е част от тестваната система и принадлежи в записа, а не в заобиколно решение.
Потвърдете поправката по първоначалния път
Когато счупената връзка бъде установена, поправете само нея и повторете първоначалния опит: същият човек, същото устройство, същата мрежа, същото приложение. Тестов акаунт, който се свързва от администраторския VLAN, доказва, че шлюзът е жив, и не доказва нищо за вторник сутринта на потребителя. Помолете потребителя да извърши действието, което се е провалило, а не по-просто такова, защото успешният ping казва малко за отхвърлен файлов дял.
Затворете тикета с това какво е изключено и какво се е променило. Тази бележка е разликата между еднократно спасяване и нещо, което следващият дежурен инженер може да използва отново.