OpenConnect-ის TOTP მოთხოვნა NetworkManager-ში არ ჩანს: ოთხი შემოწმება
შესასვლელი ერთჯერად კოდს ითხოვს და 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-ს, გენერირებული მნიშვნელობები shell-ის ისტორიის გარეთ შეინახოს და სკრიპტს სერტიფიკატების მასალად მოექცეს. გარსი, რომელიც კოდს ტერმინალში ასახავს, მეორე ფაქტორს აგდებს. ჯერ გამოსცადეთ გარსი ერთჯერადი ანგარიშით.
სკრიპტმა ასევე უნდა დაიცვას შესასვლელის მოთხოვნების რიგი. თუ სერვერი კოდს პაროლამდე ითხოვს, ფიქსირებული შეყვანის თანმიმდევრობა არასწორ მნიშვნელობას არასწორ მოთხოვნას უგზავნის და იმავე არასრულ ავთენტიფიკაციას ქმნის. ივარჯიშეთ სატესტო ანგარიშზე, სანამ შესვლის სამუშაოს დაუკავშირებთ.
დაადასტურეთ იგივე შესასვლელი და ანგარიში
გამოსცადეთ ყოველი შემოვლითი გზა იმავე შესასვლელზე, იმავე ანგარიშზე და იმავე გვირაბის ჯგუფზე. შესასვლელი, რომელიც ასევე მოწყობილობის სერტიფიკატს ითხოვს შეიძლება ბრძანების სტრიქონის კლიენტი უარყოს TOTP-თან დაუკავშირებელი მიზეზით, და მოთხოვნების რიგი შეიძლება განსხვავდებოდეს ნავარჯიშებისგან.
ჩაწერეთ კლიენტი, მისი ვერსია, მომხმარებლის აგენტი და მოთხოვნების რიგი, რომელიც იმუშავა. ეს ჩანაწერი შემდეგ ადამიანს ეუბნება, პრობლემა დამატების აწყობაში, შესასვლელის ნაკადში თუ ანგარიშის პოლიტიკაშია, პაროლების განულების კიდევ ერთი რაუნდის გარეშე.
დაასრულეთ სრული გასვლის შემდეგ ერთხელ ხელახლა დაკავშირებით. ქეშირებულმა საიდუმლომ შეიძლება გატეხილი ნაკადი შესწორებულად აჩვენოს შემდეგ სესიამდე, და სწორედ მეორე კავშირზე ბრუნდება ჩვეულებრივ დაკარგული მოთხოვნა.