strongSwan EAP: IKE იდენტობა და მოსალოდნელი AAA სახელი
strongSwan EAP კლიენტს შეუძლია ორი სერვერის სახელის შემოწმება. remote.id მოიცავს IKE კარიბჭეს, ხოლო local.aaa_id — EAP სერვერს; ეს ერთი ველი არ არის.
EAP ავთენტიფიკაციამ IKEv2-ზე შეიძლება კლიენტს მოსთხოვოს ერთ კავშირში ორი სხვადასხვა სერვერის სახელის შემოწმება. კარიბჭე, რომელიც IKE-ს ამთავრებს, ერთ იდენტობას წარმოადგენს, ხოლო EAP-ის უკანა ნაწილი, რომელიც შიდა TLS გაცვლას ამთავრებს, შეიძლება სხვა წარმოადგინოს. strongSwan-ში ისინი სხვადასხვა კონფიგურაციის ბლოკში ცხოვრობენ, და სახელის არასწორ ბლოკში ჩასმა იწვევს ჩავარდნას, რომელიც სერტიფიკატის პრობლემას ჰგავს. სწორედ იმის წაკითხვა, რომელი შემოწმება ჩავარდა, გეუბნებათ, რომელი ბლოკი უნდა შეასწოროთ.
ერთი კავშირი, ორი სერვერის იდენტობა
პირველი იდენტობა IKE გაცვლას ეკუთვნის. კლიენტი მისამართს აკავშირებს და ელოდება, რომ მოწინააღმდეგე კონკრეტულ იდენტობას დაამტკიცებს, ჩვეულებრივ კარიბჭის სერტიფიკატში მოცემულ სახელს.
მეორე EAP-ს ეკუთვნის. PEAP-ის ან TTLS-ის შემთხვევაში კლიენტი TLS გვირაბს აშენებს ავთენტიფიკაციის სერვერამდე IKE SA-ის შიგნით, და ეს შიდა სერვერი საკუთარ სერტიფიკატს წარმოადგენს. როცა უკანა ნაწილი ცალკე ჰოსტია, მისი სახელი კარიბჭის სახელისგან განსხვავდება. კლიენტი, რომელიც მხოლოდ პირველ სახელს ამოწმებს, იღებს ყველაფერს, რასაც მეორე ამტკიცებს. ხოლო კლიენტი, რომელიც ორივე ადგილას ერთი სახელით არის კონფიგურირებული, ჩავარდება მაშინ, როცა ეს ორი ნამდვილად განსხვავდება.
ორივე სახელი ოპერატორის კონფიგურაციიდან მოდის, და არა იმ სერტიფიკატიდან, რომელიც შეცდომას აქრობს. ოპერატორს განლაგების დეტალების კითხვა ორი ჰოსტის სახელის გამოცნობაზე სწრაფია.
რომელი ველი რომელ შრეს ეკუთვნის
swanctl-ში მისამართი და IKE იდენტობა ცალკე პარამეტრებია, ხოლო EAP იდენტობა მესამეა.
დისტანციური მისამართი ირჩევს, სად მიდიან პაკეტები, ხოლო დისტანციური იდენტობა ამბობს, რა უნდა დაამტკიცოს მოწინააღმდეგემ. EAP მოლოდინი local ბლოკის ქვეშ იწერება, რადგან ის ამ კლიენტის EAP გაცვლას აღწერს და არა მოწინააღმდეგის IKE ქცევას. სწორედ ამ განლაგებას კითხულობენ არასწორად. სახელი კლიენტის კონფიგურაციაში დგას, სერვერს კი აღწერს, და ზუსტად ამიტომ გამოიყურება არასწორ ადგილას.
connections {
office {
remote_addrs = vpn.example.com
local {
auth = eap-peap
aaa_id = auth.example.com
}
remote {
auth = pubkey
id = vpn.example.com
}
}
}
ეს ფრაგმენტი სრული კავშირი არ არის; ნდობის მასალა, რწმუნებულები და შვილობილი კავშირების პოლიტიკა ჯერ კიდევ უნდა არსებობდეს. მისი სიტყვასიტყვით სამუშაო ფაილში კოპირება შეცვლიდა პარამეტრებს, რომლებიც ჯერ კიდევ გჭირდებათ.
რატომ ცხოვრობს aaa_id local-ის ქვეშ
local ბლოკი აღწერს, რას აკეთებს ეს მხარე ავთენტიფიკაციის დროს, მათ შორის მეთოდს, რომელსაც გამოიყენებს და იდენტობას, რომელსაც ამ მეთოდისთვის მეორე მხარისგან ელოდება. მასში არაფერი ამბობს, რომ AAA სერვერი იმავე მანქანაზე მუშაობს.
ნაგულისხმევი მნიშვნელობა ხაფანგს უფრო მკვეთრს ხდის. როცა ცხადი მნიშვნელობა დაყენებული არ არის, მოსალოდნელი AAA იდენტობა დისტანციურ იდენტობას მიჰყვება, ამიტომ ერთი სახელის განლაგება მუშაობს და განსხვავებას მალავს. ცხადი მნიშვნელობა მნიშვნელოვანია მხოლოდ მაშინ, როცა EAP განლაგება ნამდვილად სხვაგან მთავრდება. მისი სხვა სახელზე დაყენება ამ მიზეზის გარეშე ქმნის ჩავარდნას, რომლის გამეორებაც ოპერატორს არ შეუძლია. წაიკითხეთ განლაგება, სანამ მეორე სახელს გამოიგონებთ.
შეინარჩუნეთ მნიშვნელობა იდენტური იმისა, რასაც უკანა ნაწილის სერტიფიკატი ნამდვილად ამბობს, სახელის ფორმის ჩათვლით. ბოლოში წერტილი ან ველური სიმბოლო, რომელიც ჰოსტს არ ფარავს, საკმარისია შემოწმების ჩასავარდნად.
ინტერფეისები, რომლებსაც გაყოფის გამოხატვა არ შეუძლიათ
NetworkManager-ის პროფილი არ არის იგივე კონფიგურაციის ინტერფეისი, რაც swanctl. მის უკან არსებული დანამატი იდენტობის მართვის ვიწრო კრებულს გვაძლევს, და რომელი არსებობს, დამოკიდებულია დაყენებულ ვერსიაზე.
ეს მნიშვნელოვანია, როცა განლაგებას ნამდვილად ორი სახელი სჭირდება. სერვერის იდენტობად წარწერილი ველი შეიძლება ერთ შრეს აკონფიგურირებდეს და მეორეს არა, ამიტომ პროფილი შეიძლება სწორად გამოიყურებოდეს და მაინც ჩავარდეს შიდა შემოწმებაში. შეამოწმეთ, რას უჭერს მხარს დაყენებული დანამატი, სანამ ჩათვლით, რომ პროფილი ამ განლაგებას გამოხატავს. თუ არ შეუძლია, არჩევანი ოპერატორს ეკუთვნის: სხვა მომარაგების გზა ან შესწორებული სერვერის იდენტობის დიზაინი. PEAP-ის შესუსტება ან ნებისმიერი სახელის მიღება ცვლის ავთენტიფიკაციის პოლიტიკას და არ ასწორებს მას.
ალტერნატივა კლიენტზე გამოსაგონი არ არის. მოითხოვეთ მხარდაჭერილი განლაგება წერილობით, შემდეგ შეინახეთ ეს პასუხი პროფილთან ერთად.
განასხვავეთ იდენტობის შეუსაბამობა ვადაგასული სერტიფიკატისგან
სახელის შეუსაბამობა და ვადაგასული სერტიფიკატი სხვადასხვა ჩავარდნაა, და ჟურნალი მათ ასხვავებს. წაიკითხეთ შეტყობინება, სანამ გადაწყვეტთ, რომელი ველი შეცვალოთ.
swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager
განზრახული AAA იდენტობის დაყენება არ აახლებს სერტიფიკატს და არ ამყარებს ნდობას მის გამომცემელზე, ხოლო სერტიფიკატის განახლება არ ასწორებს არასწორ მოსალოდნელ სახელს. წაიკითხეთ, რომელი შემოწმება ჩავარდა, სანამ კიდევ ერთ იდენტობის ველს შეასწორებთ. შემდეგ თავიდან ჩატვირთეთ კონფიგურაცია და დაადასტურეთ, რომ ჩატვირთული კავშირი აჩვენებს თქვენ მიერ დაყენებულ მნიშვნელობას, რადგან არასდროს ჩატვირთული შესწორებული ფაილი არაფერს ცვლის. ჩაწერეთ ორივე სახელი და მათი შრეები განლაგების ჩანაწერებში.