Адзін карыстальнік не можа ўвайсці ў VPN: паслядоўная дыягностыка

Калі адзін чалавек не можа падключыцца, а астатняя каманда працягвае працаваць, карыснае пытанне не ў тым, што зламалася, а ў тым, які ўзровень не пагадзіўся. Уваход — гэта ланцуг: кліент запускаецца, шлюз адказвае, ідэнтычнасць сцвярджаецца, другі фактар задавальняецца, палітыка ацэньваецца, і толькі тады ідзе трафік. Любы разрыў у гэтым ланцугу даходзіць да вас ад карыстальніка адным і тым жа сказам, таму першая задача — знайсці звяно, якое сапраўды адмовіла.

Стаўцеся да паведамлення як да адпраўной кропкі, а не як да дыягназу. Праверкі ніжэй ідуць ад самай таннай, і кожная напісана так, каб спыніць расследаванне, калі яна не праходзіць.

Зафіксуйце этап і адзнаку часу

Запішыце чатыры рэчы, перш чым кранаць любую канфігурацыю: кліент і яго версія, дакладная фармулёўка на экране, хвіліна спробы і сетка, у якой быў чалавек. Фармулёўка нясе рэальную інфармацыю, бо адхіленыя ўліковыя даныя, шлюз, які не адказвае, і завершаны ўваход, які ўсё яшчэ не можа адкрыць унутраную старонку — гэта тры розныя праблемы з трыма рознымі ўладальнікамі. Звярніце ўвагу, ці стварыў кліент лакальны радок журнала, бо кліент, які ніколі не адправіў пакет, нічога не дадасць да пошуку на баку сервера. Калі адзнака часу запісана, кожны наступны запыт становіцца пошукам, а не паляваннем.

Спыніце падбор пароляў на гэтым этапе. Там, дзе ва ўліковага запісу ёсць ліміт паўтораў, паток хуткіх спроб можа заблакаваць яго і дадаць другую, штучную няспраўнасць паверх сапраўднай. Запішыце, колькі спроб ужо было зроблена, каб блакаванне пазней не прынялі за новы сімптом. Заблакаваны ўліковы запіс таксама пазбаўляе вас магчымасці адрозніць няправільны пароль ад адхіленай палітыкі, бо абодва прыходзяць як адмова.

Прачытайце падзею ідэнтычнасці для гэтай адзінай спробы

Папрасіце адміністратара выняць запіс аўтэнтыфікацыі, які адпавядае запісанай вамі хвіліне. У разгортванні Windows NPS кіраўніцтва Microsoft па ліквідацыі непаладак NPS дакументуе падзею адмовы 6273 разам з кодам прычыны, які з ёй ідзе, і гэта звычайна аддзяляе невядомага карыстальніка, дрэнныя ўліковыя даныя, неадпаведнасць палітыкі і выклік, скінуты па несур'ёзнай прычыне.

Пусты вынік — таксама інфармацыя. Калі нічога не дайшло да службы ідэнтычнасці, спроба памерла раней: састарэлы адрас шлюза ў профілі, слухач, да якога кліент не можа дабрацца, або хост, які быў выведзены з эксплуатацыі, пакуль профіль жыў. Калі запіс існуе і паведамляе пра поспех, уліковыя даныя не вінаватыя, і спрэчка пераходзіць да аўтарызацыі або да маршрутызацыі за шлюзам. Гэтыя два вынікі паказваюць у процілеглыя бакі, таму пошук у журналах павінен адбыцца раней, чым хто-небудзь пераўсталюе кліент.

Трымайце код прычыны ў заяўцы. Гэта адно поле ператварае наступны выпадак у пяціхвілінны пошук, а не ў паўторнае расследаванне. Далучыце да яго версію кліента, бо код, які з'яўляецца на адной зборцы, — гэта іншая размова, чым код, які з'яўляецца на кожнай зборцы.

Змяняйце адну ўмову за раз, у межах палітыкі

Спакуса — пераўсталяваць кліент, скінуць пароль і перанесці ноўтбук у іншую сетку за адзін праход. Гэта часам выпраўляе сімптом і заўсёды знішчае доказы. Выберыце замест гэтага адну дазволеную замену: той жа чалавек на другой зарэгістраванай прыладзе або ўхваленая тэставая ідэнтычнасць на той жа прыладзе. Кожная замена адказвае роўна на адно пытанне, таму поспех звужвае няспраўнасць да таго боку, які вы змянілі, а не абвінавачвае VPN цалкам.

Не пазычайце ўліковыя даныя калегі для гэтага параўнання. Выкарыстоўвайце тэставую ідэнтычнасць праз падтрыманы працэс і ніколі не капіюйце ключ прылады і не прапускайце рэгістрацыю, таму што так было б хутчэй. Там, дзе палітыка цалкам забараняе замену, гэтае абмежаванне з'яўляецца часткай сістэмы, якая тэстуецца, і належыць да запісу, а не да абыходнага рашэння.

Пацвердзіце рамонт на зыходным шляху

Калі зламанае звяно выяўлена, рамантуйце толькі яго і паўтарыце зыходную спробу: той жа чалавек, тая ж прылада, тая ж сетка, тое ж праграмнае забеспячэнне. Тэставы ўліковы запіс, які падключаецца з адміністратарскага VLAN, даказвае, што шлюз жывы, і нічога не даказвае пра раніцу аўторка ў карыстальніка. Папрасіце карыстальніка выканаць дзеянне, якое не атрымалася, а не больш простае, бо паспяховы ping мала кажа пра адхілены агульны доступ да файлаў.

Закрыйце заяўку тым, што было выключана і што змянілася. Гэтая нататка — розніца паміж разавым выратаваннем і тым, што наступны дзяжурны інжынер зможа выкарыстаць паўторна.