Kërkesa TOTP e OpenConnect mungon në NetworkManager: katër kontrolle

Porta pranon fjalëkalimin, kërkon një kod, dhe dialogu nuk ofron asnjë fushë për të. Asgjë nuk u shtyp gabimisht: shtojca e NetworkManager përfundoi shkëmbimin e sekretit pa kërkuar vlerën gjashtëshifrore. Kryeni katër kontrollet më poshtë me radhë, sepse vetëm njëra prej tyre ndryshon klientin. Pjesa tjetër e listës përjashton portën, llogarinë dhe ndërtimin e shtojcës.

Kontrolli i parë: lexoni ku u ndal vërtetimi

Një fjalëkalim i gabuar dështon menjëherë. Një faktor i dytë që mungon dështon pas hapit të kredencialeve, zakonisht me një kërkesë të përsëritur ose një afat të skaduar në anën e portës. Koha dhe regjistri i portës tregojnë cili raund mbeti pa përgjigje.

Lexoni regjistrin e lidhjes përpara se të prekni profilin. Nëse porta raporton vërtetim jo të plotë ose një sfidë të skaduar, klienti nuk e dërgoi kurrë kodin. Nëse raporton kredenciale të pavlefshme, problemi është fjalëkalimi dhe asnjë rregullim TOTP nuk e rregullon atë.

Shënoni rendin e saktë të kërkesave që pret porta: emri i përdoruesit, fjalëkalimi, pastaj kodi, ose emri i përdoruesit, kodi, pastaj fjalëkalimi. Disa porta i rirendisin raundet, dhe një klient që njeh vetëm rendin e parë do të ngecë në të dytin.

Kontrolli i dytë: përdorni klientin që zotëron sfidën

Vetë OpenConnect zbaton të gjithë bisedën, përfshirë raundin e sfidës. Ekzekutimi i drejtpërdrejtë është mënyra më e parashikueshme për të konfirmuar se llogaria dhe porta funksionojnë:

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

Klienti pyet në rendin që pyet porta. Agjenti i përdoruesit ka rëndësi sepse disa porta e përshtatin rrjedhën e hyrjes për një klient të njohur, dhe një varg i përgjithshëm mund të prodhojë një rrjedhë më të shkurtër që nuk e kërkon kurrë kodin. Ekzekutojeni një herë në plan të parë përpara se të organizoni çdo shërbim në sfond.

Nëse rreshti i komandës pyet saktë, llogaria, porta dhe faktori i dytë janë në rregull. Problemi i mbetur është dialogu i shtojcës, jo shërbimi i vërtetimit. Kjo izolon komponentin e dështuar pa prekur serverin. Ruani daljen e komandës së bashku me regjistrin e incidentit.

Nëse edhe rreshti i komandës e kalon kërkesën, ndaloni dhe kontrolloni konfigurimin e portës me pronarin e saj. Asnjë klient desktop nuk mund t'i përgjigjet një sfide që serveri nuk e dërgon kurrë.

Kontrolli i tretë: shihni nëse shtojca juaj ofron modalitetin TOTP

Disa ndërtime të NetworkManager OpenConnect ofrojnë një modalitet tokeni dhe një fushë agjenti përdoruesi në skedën Identity të lidhjes. Vendosni agjentin e përdoruesit në vlerën që pret porta, zgjidhni futjen manuale të TOTP dhe ruani lidhjen.

Nëse ato fusha ekzistojnë varet nga versioni i shtojcës dhe nga redaktori i lidhjeve që përdor desktopi. Një redaktor i pavarur mund të shfaqë opsione që paneli GNOME i fsheh, ose anasjelltas. Kontrolloni versionin e paketës të instaluar përpara se të kërkoni një rregullim të fshehur.

Nëse modaliteti token ekziston dhe kërkesa prapë nuk shfaqet, ndërtimit i mungon dorëzimi i sfidës midis shtojcës dhe dialogut të përgjithshëm të sekreteve. Rishkrimi i fjalëkalimit, riinstalimi i të njëjtës paketë ose pastrimi i vargut të çelësave nuk do të krijojë një fushë që ndërtimi nuk e zbaton.

Kontrolli i katërt: trajtoni një kod të gjeneruar si kompromis

Një skript mund të thërrasë oathtool për kodin aktual dhe të kalojë emrin e përdoruesit, fjalëkalimin dhe kodin në nmcli connection up --ask. Sekuenca funksionon, por sekreti i përbashkët përfundon i ruajtur diku që lexohet nga kushdo që mund të hapë skriptin, dhe ai lexues mund të krijojë kode përgjithmonë. Ky është një zgjerim i përhershëm i sipërfaqes së kredencialeve, jo një rregullim i klientit.

Kushdo që e zgjedh këtë duhet ta bllokojë skedarin e sekretit në root, t'i mbajë vlerat e gjeneruara jashtë historisë së shell-it dhe ta trajtojë skriptin si material kredencialesh. Një mbështjellës që e jehon kodin në terminal e hedh poshtë faktorin e dytë. Testoni së pari mbështjellësin me një llogari njëpërdorimsh.

Skripti duhet gjithashtu të ndjekë rendin e kërkesave të portës. Nëse serveri e kërkon kodin përpara fjalëkalimit, një sekuencë fikse hyrjeje dërgon vlerën e gabuar në kërkesën e gabuar dhe prodhon të njëjtin vërtetim jo të plotë. Ushtrojeni me një llogari testuese përpara se ta lidhni me një detyrë hyrjeje.

Konfirmoni të njëjtën portë dhe të njëjtën llogari

Testoni çdo zgjidhje anashkaluese ndaj të njëjtës portë, të njëjtës llogari dhe të njëjtit grup tuneli. Një portë që kërkon edhe një certifikatë pajisjeje mund të refuzojë klientin e rreshtit të komandës për një arsye të palidhur me TOTP, dhe rendi i kërkesave mund të ndryshojë nga ai i ushtruari.

Shënoni klientin, versionin e tij, agjentin e përdoruesit dhe rendin e kërkesave që funksionoi. Ai regjistër i tregon personit tjetër nëse problemi është ndërtimi i shtojcës, rrjedha e portës apo politika e llogarisë, pa një raund tjetër rivendosjesh fjalëkalimi.

Përfundoni duke u rilidhur një herë pas një daljeje të plotë. Një sekret i ruajtur në cache mund ta bëjë një rrjedhë të prishur të duket e rregulluar deri në sesionin tjetër, dhe është në lidhjen e dytë që kërkesa që mungon zakonisht kthehet.