ვინ პასუხობს სინამდვილეში VPN-ის გამოყოფილ მისამართზე?

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

მისამართის უკან არსებული პაკეტის გზა

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

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

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

მოდელი A: მისამართს კარიბჭე ფლობს

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

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

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

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

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

მოდელი B: ზედა მოწყობილობა თარგმნის მას

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

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

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

იდენტობა გარე მისამართი არ არის

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

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

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

მიიღეთ დიზაინი ერთი კავშირის დაკვირვებით

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

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

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