Azure VPN-ის NAT გადამკვეთ VNet მისამართებს არ აგვარებს
ერთი და იმავე კერძო დიაპაზონის მქონე ორი VNet მხოლოდ NAT-ის არსებობის გამო არ დაუკავშირდება. ჯერ შეამოწმეთ კავშირის ტიპი, შემდეგ ხელახლა დანომრეთ ან ფლობდით თარგმანის ფსევდონიმს.
ორივე VNet იყენებს 10.40.1.0/24-ს, გვირაბები ადის და არაფერი მუშაობს. მეორე VPN კარიბჭის დამატება ამას არ ცვლის, არც უფრო დაბალი მარშრუტის მეტრიკა, რადგან პრობლემა ბილიკის არჩევაში არ არის. ორი დატვირთვა, რომლებიც ერთსა და იმავე კერძო მისამართს პასუხობენ, ყოველ პაკეტს ტოვებს გაურკვეველი დანიშნულებით და გადაუმოწმებელი დაბრუნების ბილიკით. ნებისმიერი თარგმანის დაგეგმვამდე გაარკვიეთ, როგორი კავშირის ტიპი შექმენით სინამდვილეში, რადგან სწორედ ეს ერთი არჩევანი განსაზღვრავს, საერთოდ არის თუ არა Azure-ის NAT ფუნქცია ხელმისაწვდომი.
რას გეუბნებათ სინამდვილეში ეს სიმპტომი
როდესაც VNet A-ის ჰოსტი აგზავნის 10.40.1.10-ზე, მარშრუტიზაციის ცხრილს მხოლოდ სადღაც შეუძლია მიუთითოს. თუ VNet B-შიც არის 10.40.1.10, ეს მისამართი არ არის დანიშნულება, რომლის გარჩევაც ბილიკს შეუძლია; ეს ერთი მისამართია ორი მფლობელით.
მეორე კარიბჭე, რომელსაც ჩვეულებრივ აყენებენ, არ ეხმარება. ის გაძლევთ სხვა გვირაბს, არა სხვა მისამართს, და დუბლირებული დიაპაზონი გვირაბის შიგნით უცვლელად მოძრაობს. ის ასევე აორმაგებს კონფიგურაციას, რომელიც თანმიმდევრულად უნდა შეინარჩუნოთ. რისი გაკეთებაც მას არ შეუძლია, არის ის, რომ ერთი მისამართი ორ ჰოსტს ნიშნავდეს.
VPN პირების საჯარო მისამართების შეცვლა ასევე არაფერს აკეთებს. ის მისამართები გვირაბის ბოლო წერტილებს განსაზღვრავს, ხოლო შეჯახება შიგნით გადატანილ კერძო დიაპაზონშია.
კავშირის ტიპი განსაზღვრავს, ხელმისაწვდომია თუ არა NAT
Azure VPN Gateway-ს ნამდვილად აქვს NAT შესაძლებლობა და ის დოკუმენტირებულია ბილიკზე დაფუძნებული IPsec-ის საიტებს შორის კავშირებისთვის კონკრეტულ კარიბჭის SKU-ებზე. იგივე დოკუმენტაცია გამორიცხავს VNet-to-VNet და point-to-site კავშირებს, ამიტომ ეს ფუნქცია არ არის მონიშვნის ველი, რომელიც ყველა კარიბჭის ურთიერთობაზე ჩნდება.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
მშობლიური VNet-to-VNet ასევე მოითხოვს, რომ VNet-ის და ლოკალური ქსელის დიაპაზონები თავიდანვე არ გადაიკვეთოს, რაც შეესაბამება გამორიცხვას. VNet-ის დაწყვილება ასევე არ არის გადაკვეთის გადაწყვეტა იმავე მიზეზით.
არსებობს მხარდაჭერილი ალტერნატივა, რომელსაც ხალხი მშობლიურ ტიპს ურევს: მეორე VNet მოდელირდება ლოკალურ ქსელად და უკავშირდება როგორც საიტ-საიტ კავშირი. ეს სხვა რესურსი და სხვა დიზაინია, ამიტომ გადარქმეულ კავშირს მოეკიდეთ როგორც გასამოწმებელ ცვლილებას და არა უბრალო გადარქმევას.
ხელახლა დანომრეთ ან თარგმნეთ იმით, რაც ფლობს ფსევდონიმს
თუ ორივე VNet თქვენია, შეადარეთ დაგეგმილი ხელახალი ნუმერაცია თარგმანის მუდმივ ხარჯს. ხელახალი ნუმერაცია ეხება აპლიკაციის კონფიგურაციას, DNS ჩანაწერებს, უსაფრთხოების წესებს და ყველა არსებულ კავშირს, მაგრამ შემდეგ ტოვებს ჩვეულებრივად წაკითხულ ქსელს. გააკეთეთ ის სათითაოდ, ერთი ქვექსელი ერთდროულად, DNS ცვლილება ბოლოს. ნახევრად დანომრილი დიაპაზონი უარესია ვიდრე რომელიმე ვარიანტი, რადგან მაშინ ორივე პრეფიქსი ავტორიტეტულად გამოიყურება ცხრილის შემდეგ მკითხველისთვის.
სადაც ხელახალი ნუმერაცია პრაქტიკული არ არის, გამოიყენეთ თარგმნილი დიზაინი ფსევდონიმის რეალური მფლობელით. VNet A-ის გამომძახებლები შეიძლება მივიდნენ VNet B-ის 10.40.1.10-მდე როგორც 10.140.1.10, მაგრამ ამ ფსევდონიმს სჭირდება მთარგმნელი მოწყობილობა, მისკენ მიმავალი მარშრუტი და პასუხის შესაბამისი ქცევა. მხოლოდ DNS-ში დამატებული მისამართი თარგმანი არ არის.
ჩაწერეთ ორივე დიაპაზონი ორივე მიმართულებით: რას აკრიფავს გამომძახებელი, რას ხედავს დანიშნულება როგორც წყაროს და რომელ მხარეს შეუძლია ინიცირება. Azure-ის საკუთარი NAT წესები მოიცავს საპირისპირო თარგმანს მათი SNAT შესაბამისობებისთვის, ამიტომ თქვენ ხელით არ წერთ შესაბამის DNAT წესს, მაგრამ ეს მოხერხებულობა მთავრდება იმ კავშირის ტიპებზე, რომლებსაც ფუნქცია მხარს უჭერს.
რა არ იმუშავებს
მომხმარებლის მიერ განსაზღვრული მარშრუტი ან მარშრუტის მეტრიკა ვერ შექმნის დაკარგულ მისამართობრივ განსხვავებას. ორივე მოქმედებს ჯერ კიდევ გაურკვეველ დანიშნულებაზე და პაკეტი აღწევს იმ შემდეგ ნაბიჯამდე, რომელსაც ცხრილი ანიჭებს უპირატესობას.
დუბლირებული დიაპაზონის მარშრუტების ცხრილში უფრო კონკრეტულ პრეფიქსად დამატება გაურკვევლობას მხოლოდ ერთი ნაბიჯით გადაადგილებს. ის ასევე ხშირად ამტვრევს მეორე მიმართულებას, სადაც პასუხს ახლა ორი სარწმუნო წყარო აქვს.
მიიღეთ დიზაინი ორივე მიმართულებით ტრაფიკით
დაამტკიცეთ დიზაინი თითოეული მხრიდან ახალი დაშვებული ოპერაციით და არა გვირაბის სტატუსით. დაკავშირებული IPsec გვირაბი ამბობს, რომ პირები შეთანხმდნენ კრიპტოგრაფიაზე; ის არაფერს ამბობს იმაზე, გახდა თუ არა დანიშნულებები გასარჩევი.
შემდეგ გაუშვით აკრძალული ბილიკები: მისამართი, რომელიც მიუწვდომელი უნდა დარჩეს და სერვისი, რომელიც პოლიტიკამ უნდა დაბლოკოს. თუ ორივე კვლავ წარმატებულია, თარგმანი უფრო ფართოა, ვიდრე დიზაინი ითვალისწინებდა.
დაასრულეთ იმ ფაქტებით, რომლებიც მოგვიანებით ახსნის კონფიგურაციას: საწყისი დიაპაზონი, წარმოდგენილი დიაპაზონი, მთარგმნელი მოწყობილობა და მიმართულება, რომლითაც თითოეულ მხარეს შეუძლია ინიცირება. თუ რომელიმე მათგანი აკლია, შემდეგი ინჟინერი მემკვიდრეობით იღებს ქსელს, სადაც ორი ჰოსტი ერთ სახელს იზიარებს და არავის ახსოვს, რატომ პასუხობს ერთი მათგანი.