რატომ ვერ მუშაობს IKEv2 Android-ზე არასტანდარტულ UDP პორტზე

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

კარიბჭე IKEv2-ს პასუხობს UDP 4443-ზე რაღაც მიზეზით, პროფილს აქვს ველი სახელად Server, თქვენ შეიყვანთ ჰოსტის სახელსა და პორტს, და ტელეფონი იტყობინება, რომ ვერ აღწევს სერვერს ან ვერ ხსნის მისამართს. არაფერი იბლოკება. Android-ის მშობლიური ფორმა ჰოსტს ელოდება, და იგივეა Windows-ზეც. მორგებული პორტი კლიენტის შესაძლებლობაა სანამ სერვერის პარამეტრი გახდება, და მხოლოდ ზოგიერთი კლიენტი გაძლევთ მის გამოხატვას. გაიარეთ სამი ნაწილი თანმიმდევრობით: რა შეუძლია კლიენტს თქვას, რას უსმენს სერვერი, და ერთნაირად აჩარჩოებენ თუ არა ორივე მხარე პაკეტებს.

რა გაგზავნა ტელეფონმა სინამდვილეში

სახელისთვის განკუთვნილ ველში host:port სტრიქონი სახელად იხსნება. ამომხსნელი vpn.example.net:4443-ისთვის არაფერს აბრუნებს, და თქვენ მიერ დანახული შეცდომა სახელის ამოხსნის ან მიუწვდომლობის ჩავარდნაა და არა პორტზე დროის ამოწურვა. ეს განსხვავება მნიშვნელოვანია, რადგან უფრო მოკლე სახელით ან სხვა ქსელით ხელახლა ცდა ვერასდროს გამოასწორებს სტრიქონს, რომელსაც ფორმა ვერ აანალიზებს.

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

გამოიყენეთ კლიენტი, რომელიც პორტს აჩვენებს

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

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

სერვერს ორი პორტი აქვს და ორივე უნდა დაემთხვეს

IKE იწყება UDP 500-ზე, და NAT-ის გავლა ჩვეულებრივ IKE-ს და შეფუთულ ESP-ს UDP 4500-ზე გადააქვს. ეს strongSwan-ში ცალკე პარამეტრებია, ამიტომ ერთ მორგებულ პორტზე გადატანილმა სერვერმა ორივე ერთსა და იმავე მნიშვნელობაზე უნდა შეცვალოს:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

როცა ერთი პორტი ორივე როლს ემსახურება, დემონმა იმავე სოკეტზე უნდა გაარჩიოს IKE ESP-in-UDP-სგან, რასაც აკეთებს ოთხბაიტიანი არა-ESP მარკერით, რომელიც IKE შეტყობინებას წინ უსწრებს. ამიტომ კლიენტი ვერ შეძლებს მორგებულ პორტზე მოლაპარაკებას და შემდეგ ჩუმად 4500-ზე გაგრძელებას, და ამიტომ ფრაზა „უბრალოდ შეცვალეთ პორტი“ ჩარჩოების მოთხოვნას მალავს.

გადამისამართება მსმენელი არ არის

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

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

ტესტირებისას გამოყავით სამი ეტაპი

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

tcpdump -ni eth0 -vv udp port 4443

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

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