IKEv2 იყენებს UDP 500-სა და 4500-ს: რომელი გადააქვს მონაცემებს?

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

ორი პორტი, ორი საქმე

IKEv2 იწყება გასაღებების გაცვლით UDP 500-ზე, სადაც მხარეები ადასტურებენ ერთმანეთს და ქმნიან უსაფრთხოების ასოციაციას გვირაბისთვის. შემდეგი მონაცემთა გზა ცალკე საკითხია: ეს შეიძლება იყოს მშობლიური ESP, რომელიც IP პროტოკოლის ნომერია და არა პორტი, ან UDP-ში შეფუთული ტრაფიკი 4500-ზე. ამ ორის გამიჯვნა firewall-ის მიმოხილვაში არის განსხვავება მოლაპარაკე გვირაბსა და მომუშავე გვირაბს შორის. ერთი სოკეტი ატარებს მართვას, მეორე — დატვირთვას.

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

რატომ არსებობს 4500 საერთოდ

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

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

სად იცვლება წყაროს პორტი

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

MOBIKE-ის მხარდამჭერი იმპლემენტაციები NAT-ის გამოვლენის გარეშეც შეიძლება გადავიდნენ 4500-ზე, და ზოგი განლაგება განზრახ აიძულებს ამ გზას. ამიტომ 4500-ის დანახვა გადაწყვეტილების მტკიცებულებაა და არა სახლის როუტერის დამტკიცება.

შეამოწმეთ ორივე ნაკადი ყოველ საზღვარზე

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

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

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

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