Зашто поновно повезивање VPN-а поново тражи акредитиве

Тунел који је радио сатима тражи лозинку у тренутку када се преносни рачунар пробуди, а ништа у конфигурацији није промењено. Променило се стање акредитива које је поновно повезивање покушало поново да искористи. Тиме управљају три врсте материјала, и само једна од њих преживљава произвољну паузу.

Прочитајте коју је клијент затражио, јер све три истичу по различитим сатовима и одбијају се различитим порукама.

Три врсте материјала који се може поново искористити

Кеширана лозинка је тајна коју држи клијент и важи док је налог не промени. Сесијски токен издаје сервер после успешне пријаве, носи сопствени рок и може се опозвати у сваком тренутку. TLS сесијска карта или IKE безбедносна асоцијација је протоколно стање, јефтино за наставак и потпуно независно од ваше лозинке. Сваку издаје друга компонента и свака истиче под сопственим условима.

Прва преживљава рестарт, друга обично преживљава суспензију, а трећа можда уопште не преживи промену мреже. Њихово мешање даје погрешно решење, попут ресетовања лозинке која никада није одбијена.

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

Обнављање кључева није поновна аутентификација

Обнављање кључева замењује кључеве задржавајући аутентификовани идентитет, зато се на здравом тунелу с времена на време догађа тихо. Поновна аутентификација понавља саму проверу идентитета и то је догађај коме сте потребни. IKEv2 експлицитно раздваја то двоје, а партнер може захтевати потпуну поновну аутентификацију у задатом интервалу без обзира на то колико је обнављања кључева било између. Споља су та два догађаја идентична док не прочитате које од њих дневник именује.

OpenVPN се понаша исто у свом речнику: интервал поновног преговарања освежава податковни канал, а аутентификацијски токен може се вратити клијенту како би се избегла потпуна пријава при следећој вези. Тај токен има рок и сервер одлучује хоће ли га поново прихватити.

Тако поновно повезивање након осам сати може пасти тамо где је поновно повезивање након осам минута успело, без икакве промене конфигурације ни на једној страни. То је цело објашњење за упит који се појављује само после ручка.

Када клијент не може да доврши нови изазов

Политика која захтева корак у прегледачу пашће на клијенту који нема како то да прикаже. Сервери без интерфејса, скрипте за покретање и стари профили грађени за аутентификацију само лозинком сви ударају у тај зид, а грешка се често појављује као опште истекање времена, а не као грешка аутентификације.

Прелази уређаја и мреже такође могу пасти унутар прозора за процену политике, па се прелазак са Wi-Fi на приступну тачку поклапа са провером која би се ионако догодила. Та случајност чини мрежу кривом када је узрок тајмер.

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

Први ред приказује догађаје поновног преговарања и аутентификације у клијентовом сопственом дневнику, а други приказује безбедносне асоцијације које strongSwan партнер тренутно држи. Упоредите временске ознаке са тренутком појаве упита; поклапање потврђује тајмер, а не мрежу.

Шта пријавити и шта не искључивати

Ако ручна пријава успева, а аутоматска поновна употреба доследно пада, реците то тачно оператеру. То именује компоненту: пут поновне употребе, не акредитиве. Укључите време квара, коришћени налог и врсту упита коју сте видели.

Не искључујте други фактор, не прескачите проверу сертификата и не лепите акредитиве у скрипту да би повезивање било тихо. Свако од тога уклања проверу коју политика постоји да спроведе, и свако претвара упит за пријаву у инцидент.

Затражите уместо тога подржани ток: клијента који може да доврши изазов, рок токена који одговара радном дану или одобрени неинтерактивни профил за машину која не може да пита. Све су то конфигурационе одлуке које неко може да одобри, што заобилазно решење није.