Липсва TOTP заявка в OpenConnect под NetworkManager: четири проверки

Шлюзът приема паролата, иска код, а диалогът не предлага поле за него. Нищо не е въведено погрешно: плъгинът на NetworkManager завърши обмена на тайната, без да поиска шестцифрената стойност. Преминете през четирите проверки по-долу по ред, защото само една от тях променя клиента. Останалата част от списъка изключва шлюза, акаунта и сглобката на плъгина.

Първа проверка: прочетете къде е спряла автентикацията

Грешната парола се проваля веднага. Липсващият втори фактор се проваля след стъпката с идентификационните данни, обикновено с повторна заявка или изтичане на времето от страна на шлюза. Времето и журналът на шлюза показват кой кръг е останал без отговор.

Прочетете журнала на връзката, преди да пипате профила. Ако шлюзът съобщава за незавършена автентикация или изтекло предизвикателство, клиентът никога не е изпратил кода. Ако съобщава за невалидни идентификационни данни, проблемът е в паролата и никаква настройка на TOTP няма да го поправи.

Отбележете точната последователност от заявки, която шлюзът очаква: потребителско име, парола, после код, или потребителско име, код, после парола. Някои шлюзове пренареждат кръговете, а клиент, който познава само първия ред, ще заседне на втория.

Втора проверка: използвайте клиента, който притежава предизвикателството

Самият OpenConnect реализира целия разговор, включително кръга с предизвикателството. Директното му стартиране е най-предсказуемият начин да потвърдите, че акаунтът и шлюзът работят:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

Клиентът пита в реда, в който пита шлюзът. Потребителският агент е важен, защото някои шлюзове нагаждат потока за вход към познат клиент, а общ низ може да даде по-кратък поток, който никога не иска кода. Стартирайте го веднъж на преден план, преди да настроите каквато и да е фонова услуга.

Ако командният ред пита правилно, акаунтът, шлюзът и вторият фактор са наред. Останалият проблем е диалогът на плъгина, а не услугата за автентикация. Това изолира неизправния компонент, без да пипа сървъра. Запазете изхода на командата с записа за инцидента.

Ако командният ред също пропуска заявката, спрете и проверете конфигурацията на шлюза с неговия собственик. Никой настолен клиент не може да отговори на предизвикателство, което сървърът никога не изпраща.

Трета проверка: вижте дали плъгинът ви предлага режим TOTP

Някои сглобки на NetworkManager OpenConnect предлагат режим на токен и поле за потребителски агент в раздела Identity на връзката. Задайте потребителския агент на стойността, която шлюзът очаква, изберете ръчно въвеждане на TOTP и запазете връзката.

Дали тези полета съществуват зависи от версията на плъгина и от това кой редактор на връзки използва работният плот. Самостоятелен редактор може да показва опции, които панелът на GNOME скрива, или обратното. Проверете версията на инсталирания пакет, преди да търсите скрита настройка.

Ако режимът на токен е наличен, а заявката все още не се появява, сглобката няма предаването на предизвикателството между плъгина и общия диалог за тайни. Повторното въвеждане на паролата, преинсталирането на същия пакет или изчистването на ключодържателя няма да създадат поле, което сглобката не реализира.

Четвърта проверка: третирайте генерирания код като компромис

Скрипт може да извика oathtool за текущия код и да подаде потребителско име, парола и код към nmcli connection up --ask. Последователността работи, но споделената тайна в крайна сметка се съхранява някъде, четено от всеки, който може да отвори скрипта, и този читател може да създава кодове завинаги. Това е постоянно разширяване на повърхността на идентификационните данни, а не поправка на клиента.

Всеки, който го избере, трябва да заключи файла с тайната до root, да държи генерираните стойности извън историята на обвивката и да третира скрипта като материал за идентификационни данни. Обвивка, която отпечатва кода в терминала, изхвърля втория фактор. Тествайте обвивката първо с временен акаунт.

Скриптът също трябва да следва реда на заявките на шлюза. Ако сървърът иска кода преди паролата, фиксирана последователност на въвеждане изпраща грешната стойност към грешната заявка и дава същата незавършена автентикация. Упражнете го с тестов акаунт, преди да го свържете със задача за вход.

Потвърдете същия шлюз и акаунт

Тествайте всяко заобикаляне срещу същия шлюз, същия акаунт и същата група за тунел. Шлюз, който също изисква сертификат за устройство, може да отхвърли клиента за командния ред по причина, несвързана с TOTP, и редът на заявките може да се различава от упражнения.

Запишете клиента, версията му, потребителския агент и последователността от заявки, която е проработила. Този запис казва на следващия човек дали проблемът е в сглобката на плъгина, в потока на шлюза или в политиката на акаунта, без още един кръг от нулиране на пароли.

Завършете, като се свържете отново веднъж след пълно излизане. Кеширана тайна може да създаде усещане, че счупен поток е поправен до следващата сесия, и именно при второто свързване липсващата заявка обикновено се връща.