Защо повторното свързване на VPN отново иска идентификационни данни
Запазена парола и многократно използваем токен изтичат по различен график. Прочетете какъв материал е поискало повторното свързване, преди да промените нещо в клиента.
Тунел, работил с часове, иска парола в мига, в който лаптопът се събуди, и нищо в конфигурацията не се е променило. Променило се е състоянието на идентификационните данни, които повторното свързване се е опитало да използва отново. Това се управлява от три вида материал и само един от тях оцелява след произволна пауза.
Прочетете кой от тях е поискал клиентът, защото трите изтичат по различен часовник и се провалят с различни съобщения.
Три вида многократно използваем материал
Кешираната парола е тайна, която клиентът пази, и остава валидна, докато акаунтът не я смени. Токенът за сесия се издава от сървъра след успешен вход, носи собствен срок на живот и може да бъде отменен във всеки момент. TLS билет за сесия или IKE асоциация за сигурност е състояние на протокола, евтино за подновяване и напълно независимо от вашата парола. Всяко се издава от различен компонент и всяко изтича при свои условия.
Първото оцелява след рестарт, второто обикновено оцелява след заспиване, а третото може изобщо да не оцелее при смяна на мрежата. Объркването им води до грешна поправка, например нулиране на парола, която никога не е била отхвърлена.
Самата подкана е диагностиката. Прозорец на браузър или код за втори фактор означава, че сървърът е изискал интерактивно удостоверяване, докато тих провал без подкана означава, че клиентът не е стигнал достатъчно далеч, за да бъде попитан.
| Material | Typical lifetime | What invalidates it |
|---|---|---|
| Cached password | Until changed | Account or password policy change |
| Session token | Minutes to hours | Expiry, revocation, reauthentication policy |
| Tunnel SA or TLS ticket | Configured rekey interval | Rekey, network change, peer restart |
Подмяната на ключове не е повторно удостоверяване
Подмяната на ключове заменя ключовете, като запазва удостоверената самоличност, поради което се случва тихо от време на време на здрав тунел. Повторното удостоверяване повтаря самата проверка на самоличността и това е събитието, което се нуждае от вас. 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 държи в момента. Сравнете времевите марки с момента, в който се появи подканата; съвпадението потвърждава таймера, а не мрежата.
Какво да се докладва и какво да не се изключва
Ако ръчният вход успява, а автоматичното повторно използване постоянно се проваля, кажете точно това на оператора. То назовава компонента: пътят на повторно използване, а не идентификационните данни. Включете часа на провала, използвания акаунт и типа подкана, която видяхте.
Не изключвайте втория фактор, не пропускайте проверката на сертификата и не поставяйте идентификационни данни в скрипт, за да направите повторното свързване тихо. Всяко от тях премахва проверката, за чието налагане съществува политиката, и всяко превръща подкана за вход в инцидент.
Поискайте вместо това поддържания поток: клиент, който може да завърши предизвикателството, срок на токена, който отговаря на работния ден, или одобрен неинтерактивен профил за машината, която не може да подкани. Всичко това са конфигурационни решения, които някой може да одобри, каквото заобиколното решение не е.