რატომ წყვეტს Azure VPN პრეფიქსის დამატება კავშირს

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

სამი ობიექტი, რომელთაგან ერთი პრეფიქსს ინახავს

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

არის მესამე დათქმაც, რომელიც უნდა გვახსოვდეს. GatewaySubnet მასპინძლობს მართულ კარიბჭის ინსტანციებს, ზუსტად ეს სახელი უნდა ჰქონდეს, და არა-Basic SKU-ებისთვის მოსალოდნელია, რომ იყოს მინიმუმ /27.

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

რატომ შლიან სწორედ კავშირს

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

ეს წაშლა თავად შეფერხებაა, ამიტომ მოეპყარით როგორც დაგეგმილ ცვლილებას დასაწყისითა და მოსალოდნელი დასასრულით და არა როგორც სწრაფ რედაქტირებას. PowerShell-ში მიმდევრობა მოკლეა: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, შემდეგ Set-AzLocalNetworkGateway ახალი -AddressPrefix მასივით, შემდეგ New-AzVirtualNetworkGatewayConnection იგივე -SharedKey და იგივე კარიბჭეებით. გასაღების ხელახლა გამოყენება მნიშვნელოვანია, რადგან შორეული მხარე ხელახლა არ კონფიგურირდება და ახალი გასაღები ნიშნავს კოორდინაციას მასთან, ვისაც შორეული მოწყობილობა ეკუთვნის. თუ ამ მოწყობილობას სხვა გუნდი მართავს, შეათანხმეთ ფანჯარა მათთან სანამ რამეს წაშლით.

როდის უნდა აშენდეს თავიდან თავად კარიბჭე

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

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

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

წაიკითხეთ მდგომარეობა და არა პორტალის სამკერდე

წაიკითხეთ მდგომარეობა რესურსიდან და არა პორტალის სამკერდიდან. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 აბრუნებს ConnectionStatus შემავალი და გამავალი ბაიტების მრიცხველებთან ერთად, და სწორედ მრიცხველები ყოფენ დაკავშირებულ, მაგრამ არაფრის გადამზიდავ გვირაბს იმისგან, რომელიც არასდროს დამყარდა.

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

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

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

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