Azure S2S VPN დაკავშირებულია, მაგრამ ტრაფიკი არ არის: წაიკითხეთ IKE ჟურნალი

პორტალი წერს Connected-ს, გვირაბს აქვს მუშაობის დროის მთვლელი, და თქვენი ვირტუალური მანქანიდან გაშვებული trace კვდება მეორე hop-ზე. კავშირის მდგომარეობა აღწერს IKE და IPsec მოლაპარაკებას, და არა იმას, გადარჩება თუ არა ერთი პაკეტი პოლიტიკის შრეს რომელიმე მხარეს. ორი ხარვეზი ხსნის ამ ბილეთების უმეტესობას და არც ერთი მათგანი არ სწორდება Azure-ის მარშრუტის შეცვლით. ორივე უკვე ჩაწერილია იმ ჟურნალში, რომელიც კარიბჭემ შექმნა, ამიტომ იქიდან ვიწყებ და არა მარშრუტების ცხრილიდან.

რას ადასტურებს Connected სინამდვილეში

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

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

გახსენით ექსპორტირებული ჟურნალი მარშრუტებზე შეხებამდე

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

ორი ჩანაწერი ატარებს ღირებულების უმეტეს ნაწილს. პირველი დაახლოებით ასე ჟღერს: expected ESP with combined authentication and cipher, received AH. მეორე არის invalid payload შეცდომა IKE გაცვლის დროს, რაც ჩვეულებრივ ნიშნავს არასწორად ფორმირებულ ან მხარდაუჭერელ წინადადების ველს.

ორივე აღწერს, რა შესთავაზა ადგილობრივმა მოწყობილობამ, ამიტომ ორივე peer-ის მხარის პარამეტრია. კავშირის Azure-ის მხარის ხელახლა გენერირება არ ცვლის თქვენი firewall-ის მიერ გაგზავნილ წინადადებას, და ამის მაინც გაკეთება ამ სამუშაოში ყველაზე ხშირად დაკარგული საათია. peer-ზე დააყენეთ მე-2 ფაზა ESP-ზე კომბინირებული ავთენტიფიკაციითა და შიფრით და მიეცით საშუალება, თავად იმოლაპარაკოს ალგორითმზე, შემდეგ შეამოწმეთ, არ ირჩევს თუ არა combined mode-ის მსგავსი სახელის მქონე მწარმოებლის მოსანიშნი უჯრა ჩუმად AH-ის წინადადებას მის ქვეშ.

დაადასტურეთ ვირტუალური ქსელის მისამართების სივრცე

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

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

შეამოწმეთ პრეფიქსები ორივე მიმართულებით

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

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

შეამოწმეთ გზა და არა ping

trace, რომელიც მოქმედ გვირაბს მოქმედი მარშრუტისგან გამოყოფს, ასე გამოიყურება: პირველი hop ადგილობრივი კარიბჭეა, შემდეგ რამდენიმე უპასუხო hop, შემდეგ მოშორებული ჰოსტი პასუხობს. თუ trace ჰოსტამდე ვერასდროს აღწევს, შეამოწმეთ TCP პორტი, რომელსაც აპლიკაცია ნამდვილად იყენებს, რადგან ICMP საკმარისად ხშირად იფილტრება, რომ წარუმატებელი ping ძალიან ცოტას ამტკიცებს. გაუშვით იგივე trace მოშორებული ჰოსტიდან Azure-ის ვირტუალური მანქანისკენ. ორ შედეგს შორის ასიმეტრია ყველაზე სწრაფი გზაა დაკარგული დაბრუნების მარშრუტის ან მხოლოდ ერთი მიმართულების დამშვები წესის საპოვნელად.

ჩაწერეთ peer-ის წინადადება, ორივე მისამართების სივრცე და კავშირის შექმნის დრო ბილეთში, რომ შემდეგმა ინჟინერმა იცოდეს, რომელი მნიშვნელობები აშენდა ხელახლა და რომლებსაც არასდროს შეხებია.

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