Зошто повторното поврзување на 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 моментално ги држи. Споредете ги временските ознаки со моментот кога се појави барањето; совпаѓањето го потврдува тајмерот, а не мрежата.

Што да се пријави и што да не се исклучи

Ако рачната најава успева, а автоматското повторно користење постојано не успева, кажете му го тоа точно на операторот. Тоа го именува компонентот: патеката на повторно користење, не акредитивите. Вклучете го времето на неуспехот, сметката што се користи и типот на барање што сте го виделе.

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

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