სჭირდება თუ არა დაწყვილებულ Azure VNet-ს საკუთარი VPN კარიბჭე?
დაწყვილებულ VNet-ს შეუძლია hub-ის VPN კარიბჭის გამოყენება მხარდაჭერილი SKU-ით და ერთი პარამეტრით peering-ის თითოეულ მიმართულებაში. შეამოწმეთ ეფექტური მარშრუტები და არა peering-ის სტატუსი.
ახალი spoke VNet ჩნდება, hub-ს უკვე აქვს მომუშავე site-to-site კარიბჭე და აშკარა კითხვაა, უნდა გადაიხადოთ თუ არა მეორე კარიბჭისთვის. ჩვეულებრივ არა: კარიბჭის ტრანზიტი საშუალებას აძლევს spoke-ს გამოიყენოს hub-ის კარიბჭე peering-ის გავლით. სამი პირობა წყვეტს, იმუშავებს თუ არა ეს, და არცერთი მათგანი არ ჩანს peering-ის სტატუსის ნიშანზე. Peering-ის კავშირი და სხვისი კარიბჭის გამოყენების ნებართვა ცალკე პარამეტრებია, ამიტომ ორი VM, რომლებსაც უკვე შეუძლიათ ერთმანეთის ping, VPN გზის შესახებ არაფერს ამტკიცებს.
პირველი პირობა: კარიბჭე და spoke-ში მისი არქონა
Azure მხარს უჭერს კარიბჭის ტრანზიტს VPN Gateway-ის SKU-ებისთვის Basic-ის გარდა, და მისი გადატანა შეუძლია როგორც რეგიონულ, ისე გლობალურ peering-ს. Spoke მოიხმარს კარიბჭეს, რომელიც მას არ ეკუთვნის, ამიტომ საკუთარი ვერ ექნება: თუ spoke-ში უკვე არსებობს კარიბჭე, ან უკვე არჩეულია დისტანციური კარიბჭის ვარიანტი, სასურველი ტრანზიტის პარამეტრი მიუწვდომელი ან არაეფექტური იქნება. შეამოწმეთ ეს სანამ რაიმეს გამართავთ, რადგან გამორთული მონიშვნის უჯრა სიმპტომია და არა ხარვეზი. ჯერ წაიკითხეთ SKU და არსებული კარიბჭე, შემდეგ შეხედეთ peering-ის პარამეტრებს.
არ წაშალოთ არსებული spoke-ის კარიბჭე, რომ ვარიანტი გამოჩნდეს, სანამ არ გაიგებთ, რა არის მასზე დამოკიდებული. მიგრაციის თანმიმდევრობა მონიშვნის უჯრაზე მნიშვნელოვანია.
მეორე პირობა: ერთი პარამეტრი peering-ის თითოეულ მიმართულებაში
Peering ორი ობიექტია, თითო თითოეულ VNet-ზე, და ტრანზიტის პარამეტრები ამ წყვილის სხვადასხვა მხარესაა. Hub-ის peering spoke-ისკენ უნდა აძლევდეს hub-ის კარიბჭეს spoke-ის მომსახურების უფლებას; spoke-ის peering hub-ისკენ უნდა მიიღებდეს hub-ის კარიბჭეს. Microsoft-ის კარიბჭის ტრანზიტის გზამკვლევი მათ მიმართულების მიხედვით ასახელებს და ეს მათი სწორად შენახვის ერთადერთი გზაა:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
remote-ის იარლიყით მართვის ელემენტი მნიშვნელობას იცვლის იმის მიხედვით, რომელი VNet-ის peering-ს არედაქტირებთ, ამიტომ წაიკითხეთ მიმართულება და არა სიტყვა. დააყენეთ ორივე მხარე, შეინახეთ და დაადასტურეთ, რომ peering ორივე ადგილას დაკავშირებულად იუწყება.
მესამე პირობა: მისამართების სივრცე და ნებართვების საზღვრები
ტრანზიტს არ შეუძლია ერთი და იგივე დანიშნულების პრეფიქსი ორ ქსელს ნიშნავდეს, ამიტომ hub-ის, spoke-ისა და ლოკალური ქსელის დიაპაზონები უნდა იყოს განცალკევებული, სანამ რომელიმე ეს იმუშავებს. VNet-ები შეიძლება სხვადასხვა გამოწერაში ან სხვადასხვა მოიჯარეში იყოს; ეს აკრძალვა არ არის, მაგრამ ვინაობას, რომელიც ქმნის ან აახლებს თითოეულ peering-ს, სჭირდება საჭირო ნებართვები ამ ქსელზე. ნებართვებზე ხშირად ვარდება გამოწერებს შორის ცვლილებები და შეცდომის ტოპოლოგიის პრობლემად წაკითხვა იოლია.
ცვლილებამდე ჩაწერეთ დიაპაზონები და მფლობელები. რომელიმეში გამოცნობა იძლევა peering-ს, რომელიც ერთვება და არაფერს მარშრუტიზაციას უკეთებს.
დაადასტურეთ ეფექტური მარშრუტებით და არა peering-ის სტატუსით
შეხედეთ spoke-ის დატვირთვის ქსელური ინტერფეისის ეფექტურ მარშრუტებს და იპოვეთ ლოკალური ქსელის რეალური პრეფიქსი. შეამოწმეთ ქვექსელის მარშრუტების ცხრილი და გამორთულია თუ არა კარიბჭის მარშრუტების გავრცელება, რადგან მომხმარებლის განსაზღვრულმა მარშრუტმა ან შემოწმების მოწყობილობამ შეიძლება გადაფაროს ის გზა, რომელსაც peering-ის დროშები მიანიშნებს. შემდეგ დაადასტურეთ საპირისპირო მიმართულება: ლოკალურმა ქსელმა უნდა იცოდეს, როგორ მიაღწიოს spoke-ის პრეფიქსს site-to-site კავშირით, იქნება ეს ნასწავლი განცხადებებით თუ ცხადი მარშრუტით და მომხმარებლის მოწყობილობაზე შესაბამისი დაცული ქსელის ჩანაწერით. თუ პრეფიქსი რომელიმე მხარეს აკლია, peering-ის დროშები არ არის ის, რაც უნდა შეიცვალოს.
გამოსცადეთ ერთი სერვისი spoke-ის დატვირთვიდან და თვალყური ადევნეთ პასუხს. VPN კარიბჭიდან ან hub-ის VM-იდან ტესტი სხვა წყაროს პრეფიქსსა და სხვა გზას იყენებს.
თუ ტოპოლოგია point-to-site კლიენტებსაც ემსახურება, ცალკე შეამოწმეთ მათი დაყენებული მარშრუტები. Windows-ის კლიენტის პაკეტებს შეიძლება დასჭირდეს ხელახლა გენერაცია ტოპოლოგიის ცვლილების შემდეგ, და ეს კლიენტის მარშრუტიზაციის ამოცანაა და არა მტკიცება, რომ კარიბჭის გაზიარება ჩავარდა.
რას არ იძლევა კარიბჭის გაზიარება
კარიბჭის ტრანზიტი მარშრუტიზაციის მოხერხებულობაა და არა ავტორიზაცია. ქსელის უსაფრთხოების ჯგუფები, ლოკალური ფილტრები და სერვისის დონის წესები კვლავ წყვეტენ, რას მიაღწევს spoke-ის დატვირთვა, ამიტომ ჩართეთ კონკრეტული წყაროდან დანიშნულების სერვისი იმის ნაცვლად, რომ ივარაუდოთ, თითქოს საერთო გვირაბი ყველაფერს იძლევა მის უკან.
peering-ის ასევე არ არის გამტარი ისე, როგორც ხალხი იმედოვნებს. კიდევ ერთი spoke-ის ან კერძო საბოლოო წერტილის დამატება შემოაქვს თავისი მარშრუტიზაციისა და წვდომის მოთხოვნები, რომლებსაც არსებული ტრანზიტის პარამეტრი არ ფარავს.