ჩუმ კარიბჭესთან ხელის ჩამორთმევის დროის ამოწურვა ჩვეულებრივ ნიშნავს ორ პროტოკოლს, რომლებიც არასდროს ხვდებიან. WireGuard-ის პირი საუბრობს Noise-ზე, ხოლო IPsec კარიბჭე IKE-ს ელოდება. სწორი მისამართი და პორტი ამას არ ცვლის.

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

პირველი მოთხოვნა: პროტოკოლის ვერსია

IPsec ასახელებს ოჯახს და არა ერთ სამუშაო პროცესს. IKEv2 და IKEv1 განსხვავდებიან თავიანთი გაცვლებით, ავთენტიფიკაციის არჩევანებით და ქსელის შეცვლის დროს ქცევით. კარიბჭე, რომელიც მხოლოდ IKEv1-ს ამთავრებს, სრულიად სხვაგვარად მოიქცევა, ვიდრე ის, რომელიც IKEv2-ს გვთავაზობს. კლიენტის კონფიგურაცია ამასთან ერთად იცვლება.

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

მეორე მოთხოვნა: კლიენტის ავთენტიფიკაციის მეთოდი

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

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

RFC 7296-ში IKEv2-ის სპეციფიკაცია აღწერს, რა უნდა დაუჭიროს მხარი ამ ვერსიის იმპლემენტაციამ. ეს ოპერატორის ბუნდოვანი პასუხისთვის საცნობაროა და არა კლიენტის კონფიგურაციის გზამკვლევი.

მესამე მოთხოვნა: სანდო იდენტობა და დანიშნულებები

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

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

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

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

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

როცა ორივე პროტოკოლი უნდა თანაარსებობდეს

ორივე ქსელის ადმინისტრირება ორივე პროტოკოლის შენარჩუნების ლეგიტიმური მიზეზია. ჩვეულებრივი დიზაინი WireGuard-სა და IPsec-ს ცალკეულ ინტერფეისებზე ან ცალკეულ კარიბჭეებზე ამთავრებს. დამტკიცებული ტრაფიკი შემდეგ მათ შორის მარშრუტირდება.

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

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

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

დაკავშირებული სტატიები