არის OpenConnect-ის --key-password თქვენი VPN ანგარიშის პაროლი?

წაიკითხეთ პარამეტრის სახელი სიტყვასიტყვით. ის ასახელებს გასაღებს და დაბნეულობა მაშინ იწყება, როცა გასახსნელი ფაილი ერევა იმ ანგარიშს, რომლის ავთენტიფიკაციაც ხდება. ჩასვით ანგარიშის პაროლი ამ პარამეტრში და კლიენტი შეეცდება მისით გასაღების ფაილის გახსნას, რაც იმარცხებს იმ მიზეზების გამო, რომლებსაც VPN-ში შესვლასთან კავშირი არ აქვს.

დამაბნეველი ის არის, რომ ერთ კავშირს ლეგიტიმურად შეიძლება ორივე საიდუმლო დასჭირდეს. კლიენტის სერტიფიკატით ავთენტიფიკაციას შეიძლება დაშიფრული გასაღები დასჭირდეს და იმავე გეითვეის შეუძლია სერტიფიკატის მიღების შემდეგ მაინც შეასრულოს მომხმარებლის ავთენტიფიკაციის გაცვლა. არც ერთი საიდუმლო არ აკმაყოფილებს მეორე ეტაპს და ერთში წარუმატებლობა გარედან მეორეში წარუმატებლობას ძალიან ჰგავს.

ორი საიდუმლო, ორი განსხვავებული საქმე

წაიკითხეთ როლები როგორც ფაილზე წვდომა ქსელში დაშვების წინააღმდეგ. გასაღების პაროლი გაშიფრავს --sslkey-ში მითითებულ PEM კერძო გასაღებს, რათა შესაძლებელი იყოს TLS კლიენტის სერტიფიკატის წარდგენა. ეს გაშიფვრა ლოკალურად, კლიენტის პროცესის შიგნით ხდება და თვით პაროლი არასდროს მიდის გეითვეიზე. გეითვეი ხედავს სერტიფიკატს და გასაღებით გაკეთებულ ხელმოწერას. OpenConnect-ის სახელმძღვანელო --key-password-ს --certificate-ისა და --sslkey-ის გვერდით ათავსებს, ხოლო იმ ბილდებში, რომლებსაც TPM-ში შენახული გასაღების გამოყენება შეუძლიათ, იგივე პარამეტრი სამაგიეროდ საცავის ფესვური გასაღების პაროლს ატარებს.

ანგარიშის პაროლი ტიპით განსხვავდება. ის ავთენტიფიკაციის გაცვლაში შედის: მომხმარებლის სახელისა და პაროლის ფორმა, ტოკენი, SAML რაუნდი ან რაღაც კომბინაცია, რომელსაც გეითვეი აცხადებს. ზოგი განლაგება საერთოდ არ ითხოვს მას, როცა სერტიფიკატი ერთადერთი ფაქტორია, ზოგი კი სერტიფიკატის შემდეგაც ითხოვს, რადგან სერტიფიკატი მოწყობილობას ამტკიცებს, ანგარიში კი ადამიანს.

ორივეს შერევა შეცდომაში შემყვან შეცდომებს იძლევა. შესვლაზე უარის მთქმელი გეითვეი ჩვეულებრივ ავთენტიფიკაციის მარცხს აცნობებს, ხოლო არასწორი გასაღების პაროლი ჩვეულებრივ უფრო ადრე იმარცხებს, როცა TLS ფენა გასაღების ფაილს ვერ კითხულობს. ეს სხვადასხვა ეტაპია სხვადასხვა გადაწყვეტით და სახელები საკმარისად მსგავსია, რომ ხალხი ერთმანეთში ცვლის და შემდეგ არასწორ ჟურნალს დაედევნება. დააკვირდით, რომელი მოთხოვნა გამოჩნდა ნებისმიერი პარამეტრის შეცვლამდე, რადგან მოთხოვნის ფორმულირება თქვენს ხელთ არსებული ყველაზე იაფი დიაგნოსტიკაა.

როდის არის გასაღების პაროლი ნამდვილად საჭირო

პარამეტრს აზრი მხოლოდ მაშინ აქვს, როცა გასახსნელი დაშიფრული გასაღები არსებობს. თუ მომხმარებლის სახელითა და პაროლით და კლიენტის სერტიფიკატის გარეშე უერთდებით, --key-password-ს არაფერი აქვს სამოქმედოდ და მისი დამატება არაფერს ცვლის. თუ --certificate-ითა და --sslkey-ით უერთდებით, თვით გასაღების ფაილის ფორმატი წყვეტს, იკითხება თუ არა პაროლი საერთოდ.

ორივე საიდუმლო ერთ ბრძანებაში ჩვეულებრივია მართულ გარემოებში: მოწყობილობის სერტიფიკატი დაშიფრულ გასაღებში, პლუს თითო მომხმარებლის შესვლა. სწორი თანმიმდევრობაა კლიენტს ლოკალურად ჰკითხოს გასაღების პაროლი, დასრულდეს სერტიფიკატის ხელის ჩამორთმევა და შემდეგ ცალკე გაუმკლავდეთ გეითვეის ანგარიშის მოთხოვნას. ორივეს წინასწარ შევსების მცდელობა ერთი ხელახლა გამოყენებული სკრიპტით ის ადგილია, სადაც დაბნეულობა ჩვეულებრივ იწყება.

სასარგებლო დიაგნოსტიკაა დააკვირდეთ, როდის ხდება მარცხი. თუ კლიენტი ჩერდება ნებისმიერი ქსელური ავთენტიფიკაციის დაწყებამდე, ეჭვი შეიტანეთ გასაღების ფაილში, მის ფორმატში ან პაროლში. თუ TLS სესია დამყარდა და შემდეგ გეითვეიმ მომხმარებელს უარი უთხრა, გასაღებმა თავისი საქმე გააკეთა და პრობლემა ანგარიშის გაცვლაშია.

ორივე საიდუმლო shell-ის ისტორიის მიღმა შეინახეთ

ბრძანების ხაზის არგუმენტები სხვა ლოკალურ მომხმარებლებს პროცესების ცხრილის მეშვეობით წაუკითხავი არ არის და ხშირად გროვდება shell-ის ისტორიაში, სკრიპტებსა და მხარდაჭერის ჩანაწერებში. OpenConnect-ს შეუძლია ანგარიშის პაროლი სტანდარტული შეყვანიდან წაიკითხოს --passwd-on-stdin-ით, ხოლო გასაღების პაროლი შეიძლება ინტერაქტიული მოთხოვნიდან ან აგენტიდან მოვიდეს არგუმენტის ნაცვლად. არც ერთი მექანიზმი თავისთავად არ ხდის საიდუმლოს უსაფრთხოს, მაგრამ ორივე მას ყველაზე ღია ადგილებისგან მოშორებით ინახავს.

ფაილებიც იმავე ზრუნვას იმსახურებენ. სკრიპტმა, რომელიც პაროლს დროებით ფაილში წერს, უნდა შექმნას ის შემზღუდავი უფლებებით, წაშალოს გასვლისას და მოერიდოს ყველასთვის წაკითხვად საქაღალდეებს. დროებით საქაღალდეში სესიის შემდეგ დარჩენილი პაროლი ის ასლია, რომლის შექმნაც დაგავიწყდათ. გარემოს ცვლადები შვილობილ პროცესებისთვის ხილულია და ხშირად გამართვის ხელსაწყოები მათ ასახავს, ამიტომ ისინი არგუმენტებთან შედარებით უფასო გაუმჯობესება არ არის.

დიაგნოსტიკური გამოსავალი ჩუმი გაჟონვაა. კლიენტის ჟურნალებს უფრო მაღალი დეტალობით შეუძლიათ მოთხოვნის სხეულები ან პარამეტრების მნიშვნელობები აჩვენონ და კოპირებული ტერმინალის ჩანაწერი ადვილად ჩასმადია ბილეთში, ამიტომ წაიკითხეთ გამოსავალი სანამ გააზიარებთ.

მკვდარი სამუშაო მაგიდის ღილაკი სხვა გაუმართაობაა

სამუშაო მაგიდის VPN ჩანაწერი, რომელიც ტრიალს აჩვენებს და შემდეგ არაფერს, ჩვეულებრივ სულაც არ არის ავთენტიფიკაციის პრობლემა. ღილაკი ეკუთვნის ქსელის მენეჯერს, მწარმოებლის აპლეტს ან დანამატს, რომელიც თქვენი სახელით უშვებს OpenConnect-ს და დაკარგული კომპონენტი ან წაუკითხავი პროფილი შეიძლება ზუსტად ეს სიმპტომი გამოიწვიოს. გაარკვიეთ, რომელ პროცესს უშვებს ღილაკი და წაიკითხეთ მისი შეცდომა სანამ რწმუნებულებს შეეხებით.

მაცდურია სერტიფიკატის შემოწმების შესუსტება ან შემოწმების გამორთვა, როცა GUI უარს ამბობს დაკავშირებაზე. ეს კლიენტის ინტეგრაციის ხარვეზს უსაფრთხოების დაწევად აქცევს და გაშვების პრობლემას იშვიათად აგვარებს. დატოვეთ სერვერის შემოწმება ხელუხლებელი, დაადასტურეთ, რომ პროფილი მიუთითებს განზრახულ გეითვეიზე და შეამოწმეთ, რომ GUI-ის მოსალოდნელი დამხმარე მართლაც დაყენებულია.

მოკლე საკონტროლო სია ჰყოფს შემთხვევებს. ლოკალური მარცხი ნებისმიერი პაკეტის გასვლამდე გასაღებზე ან კლიენტის ინსტალაციაზე მიუთითებს. გეითვეის უარი TLS სესიის შემდეგ ანგარიშის გაცვლაზე მიუთითებს. ღილაკი, რომელიც არასდროს უშვებს კლიენტს, სამუშაო მაგიდის ინტეგრაციაზე მიუთითებს. სამი განსხვავებული გაუმართაობა, რომელთაგან ერთი ის პაროლია, რომელსაც არასწორ უჯრაში აპირებდით ჩასმას.