ერთი შეცდომა, სამი საიდუმლო: რომელი VPN-ის მონაცემები ჩავარდა?
კლიენტი ყოველი ეტაპისთვის ერთ შეცდომას აჩვენებს. წაიკითხეთ ასოციაცია, მომხმარებლის გაცვლა და მეთოდი, სანამ გააუქმებთ პაროლს, რომელიც არავის შეუმოწმებია.
«ავთენტიფიკაცია ჩავარდა» შეიძლება მიუთითებდეს სერვერის სერთიფიკატზე, მანქანის წინასწარ გაზიარებულ გასაღებზე ან მომხმარებლის პაროლზე. რომელ მათგანზე, დამოკიდებულია პროტოკოლზე, რადგან ყოველი პროტოკოლი საიდუმლოების სხვა კრებულს განსაზღვრავს. არასწორის გაუქმება და შეცდომა უცვლელი დარჩება. გამოსავალია დაადგინოთ, რამდენ მტკიცებულებას მოითხოვს პროტოკოლი, სანამ რაიმეს შეასწორებთ.
ორი მტკიცებულება საწინააღმდეგო მიმართულებით
გვირაბმა უნდა უპასუხოს, მიაღწია თუ არა სწორ კარიბჭეს და ცალკე, ვინ არის მომხმარებელი. კარიბჭის მტკიცებულება მანქანის დონეზეა: სერვერის სერთიფიკატი, წინასწარ გაზიარებული გასაღები ან სტატიკური საჯარო გასაღები. მომხმარებლის მტკიცებულება პიროვნების დონეზეა: პაროლი, ტოკენი, კლიენტის სერთიფიკატი ან საერთოდ არაფერი. ეს ნდობის საწინააღმდეგო მიმართულებებია და სხვადასხვა მასალას ხარჯავს.
IKEv2 კარიბჭის მტკიცებულებას IKE_AUTH-ის შიგნით ასრულებს, ხოლო როცა EAP გამოიყენება, შემდეგ მომხმარებლის მტკიცებულებას ცალკე გაცვლაში ატარებს. IKEv2-ის სპეციფიკაცია მათ ცალკე თავებად ინახავს, რაც ძლიერი მინიშნებაა იმაზე, სად უნდა ვეძებოთ, როცა ერთი შეტყობინება ორივე რაუნდს ფარავს.
წაიკითხეთ ეტაპი და არა შეტყობინება
კლიენტი ერთ შეცდომის სტრიქონს აჩვენებს, რომელი ეტაპიც არ უნდა ჩავარდეს, ამიტომ თავად სტრიქონი თითქმის არანაირ ინფორმაციას არ ატარებს. ინფორმაციას ატარებს ის მდგომარეობა, რომლის შემოწმებაც ყოველ ეტაპზე შეგიძლიათ: არსებობს თუ არა ასოციაცია, დაიწყო თუ არა მომხმარებლის გაცვლა და შესთავაზა თუ არა კლიენტმა ის მეთოდი, რომელიც კარიბჭეს სურდა. ცხრილი ეტაპებს სწორედ ასე ალაგებს და არა პროტოკოლის სახელის მიხედვით.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
მხოლოდ მეორე სტრიქონი ეხება იმ მონაცემებს, რომელთა ხელახლა აკრეფაც მომხმარებელს შეუძლია. დანარჩენი სამი კონფიგურაციის ფაქტია, და სწორედ ეს შეუსაბამობაა მიზეზი იმისა, რომ ასეთი ანგარიშების დიდი ნაწილი ისეთი პაროლის გაუქმებით მთავრდება, რაც არაფერს ცვლის. ნებისმიერ ველზე შეხებამდე წაიკითხეთ ის სტრიქონი, რომელიც თქვენს მტკიცებულებას ემთხვევა.
ორი საიდუმლოს მქონე პროტოკოლი ბარათებს ავლენს
L2TP IPsec-ზე რაოდენობას თვალსაჩინოს ხდის, რადგან ორი შემოწმება სხვადასხვა პროცესში ხდება. IPsec შრე ჯერ უნდა ასდეს წინასწარ გაზიარებული გასაღებით ან სერთიფიკატით, და მხოლოდ ამის შემდეგ ცდილობს მის შიგნით PPP მომხმარებლის შესვლას.
როცა მანქანის საიდუმლო არასწორია, ასოციაცია არ იქმნება და მომხმარებლის მონაცემები არასოდეს არ მოისინჯება. როცა მანქანის საიდუმლო სწორია და მომხმარებლისა არასწორი, ასოციაცია არსებობს და PPP შესვლას უარყოფს მას შემდეგ, რაც გვირაბი უკვე აწეულია. ორივე ეკრანზე ერთსა და იმავე შეტყობინებას იძლევა ორი სხვადასხვა მოვლენიდან.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerასოციაციების ცარიელი სია მომხმარებლის შრეს მაშინვე გამორიცხავს, ამიტომ შეამოწმეთ ის პაროლამდე. დამყარებული ასოციაცია განმეორებადი PPP წარუმატებლობებით საპირისპირო მიმართულებაზე მიუთითებს, მომხმარებლის შრეზე ან მის შიგნით არსებულ ავთენტიფიკაციის პროტოკოლზე. ამ ორი დასკვნიდან არც ერთი არ არის ხელმისაწვდომი კლიენტის შეცდომის ტექსტიდან.
რაზეა რეალურად დამოკიდებული მხოლოდ პაროლით შესვლა
მხოლოდ პაროლით წვდომა ჩვეულია L2TP-ისთვის, PPTP-ისთვის, SSTP-ისთვის და EAP-იანი IKEv2-ისთვის. WireGuard-ს ასეთი არჩევანი საერთოდ არ აქვს, რადგან მისი პარტნიორები გასაღებები არიან და არა მომხმარებლები. OpenVPN-ისთვის პასუხი სერვერის კლიენტის სერთიფიკატის მოთხოვნიდან მოდის: კარიბჭე, რომელიც სერთიფიკატსაც და პაროლსაც ითხოვს, მხოლოდ პაროლიან კლიენტს კვლავ უარყოფს, რაც უნდა აკრიფოს ველში.
რომელი კომპონენტი გჭირდებათ, იმავე პასუხიდან გამომდინარეობს. IKEv2-ის ქვეშ პაროლით შესვლა მოითხოვს კლიენტს, რომელიც EAP-ს ლაპარაკობს, ხოლო სერთიფიკატით შესვლას სჭირდება კლიენტის კერძო გასაღები და სერვერის ჯაჭვი. დააყენეთ არასწორი და წარუმატებლობა მონაცემების შეცდომად იკითხება, თუმცა სწორედ ავთენტიფიკაციის მეთოდი აკლია.
შეცვალეთ ერთი რამ და შემდეგ ხელახლა შეამოწმეთ
ჯერ სამი ფაქტი დაადგინეთ: რომელი პროტოკოლი მუშაობს, რამდენ საიდუმლოს განსაზღვრავს და რომელი მათგანი მანქანას ეკუთვნის და არა მომხმარებელს. მანქანები პირველ ეტაპზე ცდებიან, ხალხი კი მეორეზე, და ამ ორის არევა სწორედ ეს მთელი პრობლემაა.
შემდეგ შეცვალეთ ზუსტად ერთი რამ და ხელახლა შეამოწმეთ იმავე კლიენტიდან. ეს დისციპლინა დამაბნეველ წარუმატებლობას აქცევს შესწორებად, რომელსაც შემდეგ ადამიანს აუხსნით, და ეს უფრო სასარგებლოა, ვიდრე მომუშავე კავშირი, რომელსაც ვერავინ ხსნის.