Azure VM VPN-ის ჩართვის შემდეგ IMDS-სა და WireServer-ს ვერ აღწევს

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

სიმპტომი გატეხილ აგენტს ჰგავს

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

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

168.63.129.16 საჯარო დანიშნულება არ არის

168.63.129.16 Azure-ის სპეციალური ვირტუალური პლატფორმის მისამართია, და მისი ერთ-ერთი როლი WireServer-ია, რომელსაც VM აგენტი ქსოვილთან სასაუბროდ იყენებს. Microsoft ადასტურებს, რომ აგენტის ტრაფიკი TCP 80 და 32526 პორტებზე ხელმისაწვდომი უნდა დარჩეს. ეს ჩვეულებრივი ინტერნეტ ჰოსტი არ არის და არ არის ის, რაც სრული გვირაბის VPN-მა შორეულ გასასვლელამდე უნდა ატაროს. ამიტომ ჯანსაღად მოჩვენებულ გვირაბს მაინც შეუძლია აგენტის გაშიმშვილება.

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

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

169.254.169.254-ს საკუთარი წესები აქვს

169.254.169.254 Azure Instance Metadata Service-ის link-local მისამართია. მასზე მიმართულ მოთხოვნებს საკუთარი მოთხოვნები აქვს: ძირითადი NIC და ძირითადი IP, მისამართის მხარდამჭერი DHCP კონფიგურაცია და ნებისმიერი HTTP პროქსის გვერდის ავლა. მათი შორეული VPN გასასვლელით ან თვითნებური ინტერნეტ კარიბჭით გაგზავნა არ არის ის წვდომის მოდელი, რომელსაც Microsoft აღწერს.

ეს პროქსის პუნქტი იჭერს მათ, ვინც მარშრუტი გაასწორა და მაინც ხარვეზებს ხედავს. სტუმრის HTTP პროქსის შეუძლია IMDS გატეხოს, მაშინ როცა ip route get ზუსტად იმ ინტერფეისს აბრუნებს, რომელსაც ელოდებით, ამიტომ მარშრუტებთან ერთად პროქსის გამონაკლისებიც შეამოწყეთ.

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

წაიკითხეთ სტუმრის პოლიტიკური მარშრუტიზაცია, და არა მხოლოდ მთავარი ცხრილი

Linux სტუმარზე სამი მხოლოდ-წაკითხვის ბრძანება ყოფს ფენებს: ip -4 rule show პოლიტიკის წესებისთვის, შემდეგ ip -4 route get 168.63.129.16 და ip -4 route get 169.254.169.254 იმ გადაწყვეტილებებისთვის, რომლებსაც ბირთვი რეალურად იღებს. გაუშვით ისინი VPN-ის დაკავშირებამდე და შემდეგ. ამ ორი გამოსავლის სხვაობა თქვენი ცვლილებების ნაკრებია და უფრო სასარგებლოა, ვიდრე ნებისმიერი ვარაუდი იმაზე, თუ რა გააკეთა კლიენტმა.

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

წინაღდეგით იმ რეცეპტს, რომელიც ორივე /32 მარშრუტს ძველი კარიბჭით ამატებს. link-local პლატფორმის გზა და ზოგადი WAN-ის შემდეგი ნაბიჯი სხვადასხვა ობიექტია, და საერთო გამონაკლისი რეალურ პოლიტიკურ კონფლიქტს მალავს.

ადმინისტრირება და აღდგენა ცალკე შეინახეთ

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

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

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