Azure-ის IP ნაკადის შემოწმება ამბობს, რომ დაშვებულია, მაგრამ VPN მაინც არ მუშაობს
IP ნაკადის შემოწმება პასუხობს ფილტრაციის კითხვას და არა მარშრუტიზაციისას. წაიკითხეთ ეფექტური მარშრუტები და შემდეგი ნახტომი VM-ის NIC-ზე, სანამ გვირაბს დაადანაშაულებთ.
საიტ-საიტ გვირაბი დაკავშირებულია, VM ჯანმრთელია, მაგრამ ლოკალური კლიენტი ვერაფერს იღებს. ხსნით Network Watcher-ს, უშვებთ IP ნაკადის შემოწმებას და ის ამბობს Access allowed, ამიტომ ბილეთი იხურება როგორც VPN-ის პრობლემა. ეს შედეგი არ ნიშნავს იმას, რასაც ჰგავს, რადგან IP ნაკადის შემოწმება აფასებს თქვენ მიერ აღწერილი ნაკადის უსაფრთხოების წესებს და არასოდეს ამოწმებს, აქვს თუ არა Azure-ს მარშრუტი თქვენს ლოკალურ პრეფიქსამდე.
ფილტრაციის კითხვა და მარშრუტიზაციის კითხვა ცალკეა და Network Watcher მათ სხვადასხვა იარაღით პასუხობს. იმის ცოდნა, რომელი იკითხეთ, დიაგნოზის დიდი ნაწილია.
რას წყვეტს IP ნაკადის შემოწმება სინამდვილეში
IP ნაკადის შემოწმება იღებს VM-ს, ქსელურ ინტერფეისს, მიმართულებას, ხუთმაჩვენებლიან მნიშვნელობებს და პროტოკოლს, შემდეგ იუწყება NSG-ისა და უსაფრთხოების ადმინისტრატორის წესის გადაწყვეტილებას ამ ნაკადისთვის. ის მუშაობს TCP-სა და UDP-ზე, ამიტომ ICMP წესების ტესტერი არ არის და დაბლოკილი ping თქვენი სერვისის შესახებ არაფერს ამტკიცებს. მიეცით მას რეალური ნაკადი და არა ვარაუდი. ლოკალური გარემოდან მონაცემთა ბაზის პორტზე შემომავალი კავშირი სხვა აღწერაა, ვიდრე VM-ის მიერ წამოწყებული გამავალი კავშირი.
თუ კარიბჭე მისამართებს თარგმნის, გამოიყენეთ ის წყაროს მისამართი, რომელიც აღწევს თქვენ მიერ შეფასებულ საზღვრამდე და არა კლიენტის კონფიგურაციაში არსებული. შედეგიც ისე წაიკითხეთ, როგორც არის. Access allowed ნიშნავს, რომ ფილტრის შრე პაკეტს გაუშვებდა, თუ ის მოვიდოდა, და მეტს არაფერს.
რასაც ვერ გეტყვით, არის Azure-ის მიერ არჩეული მარშრუტი, უშვებს თუ არა სტუმრის firewall პორტს ან უსმენს თუ არა რამე. ეს სხვა შრეებში ცხოვრობს.
რას მატებს შემდეგი ნახტომი და ეფექტური მარშრუტები
შემდეგი ნახტომი პასუხობს გადაგზავნის კითხვას: ამ დანიშნულებისთვის რომელი ტიპის შემდეგ ნახტომს ირჩევს Azure, რომელ მისამართზე, რომელი მარშრუტების ცხრილიდან. ეფექტური მარშრუტები ჩამოთვლიან, რა აქვს NIC-ს რეალურად. გაუშვით ორივე და მიიღებთ Azure-ის მხარის გზას, რომელსაც მწვანე IP ნაკადის შემოწმება ცარიელს ტოვებს.
Microsoft-ის IP ნაკადის შემოწმების მიმოხილვა პირდაპირ აღნიშნავს ფილტრაციის არეალს, ხოლო შემდეგი ნახტომისა და მარშრუტების დიაგნოსტიკის გვერდები გადაგზავნის მხარეს მოიცავს. ჩაწერეთ სწორი გვერდი, როცა დაკვირვებას წერთ.
ბრძანებები საკმარისად მოკლეა, რომ ჭურვიდან გაუშვათ. az network nic show-effective-route-table ჩამოთვლის ინტერფეისზე გამოყენებულ მარშრუტებს. az network watcher show-next-hop წყაროსა და დანიშნულებასთან ერთად აბრუნებს არჩეულ ნახტომს. შეადარეთ თქვენთვის მნიშვნელოვანი პრეფიქსი იმ ცხრილს და შემდეგ დაადასტურეთ, რომელი ჩანაწერი იმარჯვებს.
გაიარეთ დაბრუნების გზა VM-ის NIC-დან
ეს გააკეთეთ სამიზნე VM-ის NIC-დან, ლოკალური კლიენტის პრეფიქსისთვის და არა ინტერნეტისთვის. დაბრუნების გზაში იმალება საიტ-საიტ ხარვეზები, რადგან გვირაბის სტატუსის შემოწმება მხოლოდ იმას იტყობინება, რომ უსაფრთხოების ასოციაციები აწეულია.
თუ მოსალოდნელი მარშრუტი არ არის, შეამოწმეთ კარიბჭის კონფიგურაციის მიერ მოწოდებული დისტანციური პრეფიქსები, VNet-ის კავშირის დიზაინი და მარშრუტების გავრცელების ნებისმიერი პარამეტრი. ლოკალური ქსელის კარიბჭის ობიექტი აღწერს ლოკალურ მხარეს; მისი არსებობა არ ამტკიცებს, რომ ყოველი საჭირო პრეფიქსი NIC-ზე არის და უპირატესია. ეს სხვადასხვა ფაქტია და მხოლოდ ერთი მათგანი ჩანს პორტალის შეჯამებაში.
წაიკითხეთ შემდეგი ნახტომის ტიპი და ნუ დააკოპირებთ მაგალითს
მართული VPN კარიბჭის გზა ჩვეულებრივ აჩვენებს VirtualNetworkGateway შემდეგი ნახტომის ტიპად. VirtualAppliance აღწერს სხვა გადაგზავნის დიზაინს, ჩვეულებრივ firewall-ს ან ქსელურ ვირტუალურ მოწყობილობას.
ნუ შექმნით მოწყობილობის მარშრუტს სავარაუდო VPN საბოლოო წერტილისკენ მხოლოდ იმიტომ, რომ ძველმა ფორუმის პასუხმა ეს ტიპი გამოიყენა. თუ მომხმარებლის მიერ განსაზღვრული მარშრუტი ცვლის განზრახ გზას, იპოვეთ მისი მფლობელი და მიზანი შეცვლამდე. მეორე NIC-მაც შეიძლება შეცვალოს, რომელ ინტერფეისს იყენებს სტუმარი, და მისი მოცილება შეიძლება სხვა სერვისი გატეხოს ამ მარშრუტის გასწორების ნაცვლად.
გადადით საზღვარზე, რომელიც ჯერ კიდევ ვერ მუშაობს
როცა ფილტრაცია და მარშრუტიზაცია ორივე შეესაბამება დიზაინს, ხარვეზი სხვაგანაა. შეამოწმეთ სტუმრის საკუთარი მარშრუტების ცხრილი, მისი firewall და მიბმულია თუ არა მსმენელი მოსალოდნელ მისამართზე. შემდეგ შეამოწმეთ VPN-ის დაცული ტრაფიკის სელექტორები და ლოკალური პასუხის გზა. თითოეული მათგანი ცალკე ტესტია ცალკე შედეგით.
დაასრულეთ დაშვებული აპლიკაციის მოთხოვნით და ორივე ბოლოს დაკვირვებებით. დაშვების შედეგი და სწორი შემდეგი ნახტომი ორი მტკიცებულების ნაწილია და არა იმის მტკიცება, რომ კავშირი წარმატებით დასრულდა.