Azure P2S VPN-ის დაბრუნების ტრაფიკი მხოლოდ ერთი მიმართულებით მუშაობს

გვირაბის ხატულა მწვანეა, NSG დამშვები ჩანს, ეფექტური მარშრუტები სწორად გამოიყურება, და მაინც VM ვერ ხსნის კავშირს დაკავშირებული კლიენტისკენ. ჩვეულებრივი ვარაუდია, რომ მომუშავე point-to-site გვირაბი სიმეტრიულია: თუ კლიენტი აღწევს VM-ს, VM აღწევს კლიენტს. ეს ვარაუდი მსჯელობის შეცდომაა, არა კონფიგურაციის. გვირაბს შეუძლია გადაიტანოს მოუთხოვნელი ნაკადის ერთი მიმართულება და ჩამოაგდოს მეორე, და გასწორება დამოკიდებულია იმაზე, რომელი შრე აგდებს მას.

მითი: დაკავშირებული გვირაბი ორმხრივი გვირაბია

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

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

შეამოწმეთ მიმართულება სანამ ხელმისაწვდომობას შეამოწმებთ

აირჩიეთ ერთი კლიენტის მისამართი, ერთი VM-ის მისამართი და ერთი პროტოკოლი. დაუკავშირდით კლიენტიდან და ჩაწერეთ შედეგი; შემდეგ დაიწყეთ იგივე ტესტი VM-იდან და ისიც ჩაწერეთ. თუ პირველი წარმატებულია და მეორე ვერ, მაშინ კლიენტების პული, კარიბჭის ასოციაცია და კლიენტიდან VNet-ის გზა ყველა მუშაობს.

შემდეგი ნაბიჯი მტკიცებულებაა, არა მეტი წესი. შეამოწმეთ NSG VM-ის ქვექსელზე ორივე მიმართულებით, წაიკითხეთ ეფექტური მარშრუტები VM-ის NIC-ზე, და აიღეთ პაკეტები VM-ზე, სანამ კლიენტი ტრაფიკს აგზავნის. პასუხის გარეშე მოსული მოთხოვნა ფილტრის ან დაბრუნების მარშრუტის პრობლემაა; არასდროს მოსული მოთხოვნა გზის პრობლემაა. არ ჩათვალოთ წარუმატებელი ping VM-ის მიუწვდომლობის მტკიცებულებად, რადგან ICMP პოლიტიკამ შეიძლება პასუხი ჩამოაგდოს, სანამ TCP მუშაობს.

IKEv2 point-to-site დაბრუნების გზა ჩვეულებრივი ეჭვმიტანილია

ამ სტატიის საფუძველში მდგარ Azure ანგარიშში კლიენტი IKEv2-ით აღწევდა VM-ებს, მაგრამ VM-იდან კლიენტისკენ შემავალი ICMP ვერ მუშაობდა, სანამ კარიბჭის გვირაბის ტიპი არ გადაკეთდა OpenVPN-ზე. ანგარიშის ავტორი ამბობს, რომ Microsoft-მა დაადასტურა შეზღუდვა IKEv2 point-to-site გზაზე, სადაც VM-იდან კლიენტისკენ დაბრუნების ტრაფიკი სიმეტრიულად არ მარშრუტირდება, თუ სესია კლიენტს არ დაუწყია. IKEv2 ტრაფიკის სელექტორებს ეყრდნობა, და კარიბჭემ ამ შემთხვევაში დაბრუნების მიმართულება არ დაიცვა.

ეს OpenVPN-ს ზოგადად უკეთეს გვირაბის ტიპად არ აქცევს. ეს გვირაბის ტიპს ამ სამუშაო დატვირთვის ტესტის მატრიცაში ცვლადად აქცევს.

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

მითი: broadcast-ით აღმოჩენა VNet-ის საზღვარს კვეთს

მეორე ვარაუდი უკავშირო მიზეზით ვარდება. Azure-ის ვირტუალური ქსელი broadcast ტრაფიკს არ გადაიტანს, ამიტომ VM-ს არ შეუძლია ლოკალური ქსელიდან broadcast კადრების მიღება site-to-site ან point-to-site კავშირით. აპლიკაციები, რომლებიც პარტნიორებს broadcast-ით პოულობენ, მაგალითად ძველი ფაილების დათვალიერება ან ზოგიერთი მოწყობილობის აღმოჩენის პროტოკოლი, ვერასდროს ნახავენ შორეულ მხარეს, როგორც არ უნდა იყოს მარშრუტები დაწერილი.

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

რა უნდა შეიცვალოს და როგორ დავამტკიცოთ

თუ მიმართულების ტესტი მარცხდება მხოლოდ IKEv2-ზე, ჩაწერეთ კარიბჭის გვირაბის ტიპი, კლიენტის მისამართების პული და ზუსტი ICMP ან TCP ტესტი, შემდეგ შეაფასეთ დამტკიცებული OpenVPN პროფილი დაზარალებული კლიენტებისთვის. თუ ის მარცხდება ყველა გვირაბის ტიპზე, იმუშავეთ დაბრუნების გზაზე: კლიენტის მისამართი უნდა იყოს მარშრუტიზებადი VM-ის ქვექსელიდან, ნებისმიერი მომხმარებლის მიერ განსაზღვრული მარშრუტი უნდა მიუთითებდეს ვალიდურ შემდეგ ჰოპზე, და კლიენტის firewall-მა უნდა მიიღოს შემავალი ნაკადი. მიამაგრეთ NSG-ის და მარშრუტების მტკიცებულებები ბილეთს.

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