Azure P2S: VNet-ის ცვლილების შემდეგ ერთ Windows კლიენტს მარშრუტები დაკარგა

ორი ლეპტოპი ერთსა და იმავე Azure point-to-site კარიბჭესთან ავთენტიფიცირდება და მხოლოდ ერთი აღწევს ახლად დაკავშირებულ VNet-ს. ორივე Connected-ს აჩვენებს, ამიტომ ავთენტიფიკაცია განსხვავება არ არის; განსხვავება დანიშნულების მარშრუტებია. დაიწყეთ წარუმატებელი კლიენტიდან, შეადარეთ ერთი დანიშნულება და მხოლოდ ამის შემდეგ გადაწყვიტეთ, ჰყოფს თუ არა ამ ნაპრალს კარიბჭის პაკეტი თუ ლოკალური მარშრუტების ცხრილი.

დაიწყეთ წარუმატებელი კლიენტიდან და არა კარიბჭიდან

დაადასტურეთ ტოპოლოგია ლეპტოპის დადანაშაულებამდე. შეამოწმეთ, რომელი VNet-ებია დაკავშირებული კარიბჭის VNet-თან და ახალი ქსელი პირდაპირ peer-ია თუ ცალკე site-to-site გვირაბით აღწევს. თუ ახალი VNet საერთოდ არ არის დაკავშირებული კარიბჭის VNet-თან, არც ერთი კლიენტის პაკეტი ვერ შეძლებს იქ მარშრუტიზაციას და მომუშავე ლეპტოპი სწორედ ის ანომალიაა, რომელიც უნდა აიხსნას. ჩაწერეთ პასუხი, რადგან ის განსაზღვრავს, კლიენტს ამუშავებთ თუ კარიბჭეს.

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

შეადარეთ ერთი დანიშნულება route print-ით

აირჩიეთ დაშვებული რესურსის IP და შეადარეთ ორივე ლეპტოპი ორჯერ: გათიშულ მდგომარეობაში, შემდეგ დაკავშირებულში. Windows-ში route print -4 ჩამოთვლის IPv4 მარშრუტებს დანიშნულების პრეფიქსით, ინტერფეისით, შემდეგი ნახტომით და მეტრიკით. ჩაწერეთ ის სტრიქონი, რომელიც რეალურად მოიგებდა ამ დანიშნულებისთვის, ნაცვლად იმისა, რომ დაითვალოთ VPN სიტყვის შემცველი ჩანაწერები.

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

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

TTL expired მარშრუტების განაწილების ხარვეზი არ არის

ping, რომელიც TTL expired in transit-ს აბრუნებს, ამბობს, რომ პაკეტმა ნახტომების კვოტა ამოწურა, რაც ჩვეულებრივ გადაგზავნის მარყუჟს ნიშნავს და არა გატეხილ VPN დრაივერს. Windows-ის ping TTL-ს 255-მდე იღებს და მნიშვნელობის აწევა მარყუჟს არ აკეთილშობილებს; ის მხოლოდ იმავე შეცდომას აყოვნებს. მოექეცით შეტყობინებას როგორც ბილიკის სიმპტომს და არა როგორც მტკიცებულებას მარშრუტების განაწილებაზე.

გამოიყენეთ tracert -4 10.24.1.10 რომ ნახოთ სად მეორდება ბილიკი. თუ იგივე ორი ნახტომი არაერთხელ ჩნდება, მოძებნეთ მარშრუტი, რომელიც გვირაბისკენ მიმავალ ტრაფიკს უკან გვირაბში ან ლოკალურ როუტერში აბრუნებს, რომელიც მას უკან აგზავნის.

ხელახლა შექმენით პაკეტი იმ კარიბჭეზე, რომელიც ფლობს მას

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

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

Azure P2S მარშრუტიზაციის სცენარები ყოფს პირდაპირ peer-ილ VNet-ებს სხვა გვირაბებით მისაწვდომი ქსელებისგან და ახალი პაკეტი ვერ გახდის peer-ს ტრანზიტულს. Windows-ის site-to-site ან BGP ზოგიერთ სცენარს ხელით კონფიგურირებული დისტანციური მარშრუტებიც სჭირდება, ამიტომ პაკეტის განახლება მარშრუტების განაწილების უნივერსალური მექანიზმი არ არის.

დროებითი მარშრუტი დროებით დატოვეთ

ხელით მარშრუტს შეუძლია გამოყოს დაკარგული კლიენტის მარშრუტი, მაგრამ ააგეთ ის რეალური დიზაინიდან: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, მუდმივი დროშის გარეშე, რათა გადატვირთვისას გაქრეს. ინტერფეისის ინდექსი და შემდეგი ნახტომი აირჩიეთ დაკავშირებული VPN ადაპტერიდან და არა გამოცნობით.

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

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