ორი საჯარო IP ერთ Azure VPN VM-ზე: რომელი რას აკეთებს

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

გადაწყვეტილება 1: სად მთავრდება გვირაბი

Azure-ის საჯარო IP დაკავშირებულია NIC-ის კერძო IP კონფიგურაციასთან; ეს არ არის მისამართი, რომელსაც სტუმრის ოპერაციული სისტემის შიგნით ამატებთ. წაიკითხეთ დაკავშირება ვარაუდის ნაცვლად: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. რომელი კერძო მისამართიც არ უნდა დააბრუნოს ამ მოთხოვნამ, სწორედ ის უნდა ჰქონდეს სტუმარს რეალურად.

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

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

გადაწყვეტილება 2: რომელ წყაროს იყენებს გადამისამართებული კლიენტი

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

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

გადაწყვეტილება 3: რომელი Azure გასვლის მეთოდი იმარჯვებს

Microsoft დოკუმენტაციაში აღწერსგასვლის პრიორიტეტულობის რიგს: მოქმედი მარშრუტი მოწყობილობისკენ ან კარიბჭისკენ პრიორიტეტს იღებს, ხოლო ქვექსელის NAT Gateway კავშირი პრიორიტეტულია ინსტანსის დონის საჯარო IP-ზე შესაბამის გზაზე. ეს რიგია მიზეზი, რის გამოც 10.20.0.5-ზე თარგმნა არ ამტკიცებს, რომ ვებსაიტი 198.51.100.20-ს დაინახავს. წაიკითხეთ ეფექტური მარშრუტების ცხრილი, NAT Gateway-ის ასოციაცია და NIC-ის საჯარო IP ერთად, სანამ გასვლის დიზაინს მიიღებთ.

შეინახეთAzure NIC-ის გადამისამართების პარამეტრიLinux-ის გადამისამართებისგან ცალკე. ღრუბლის დროშა ნებას რთავს პაკეტებს, რომელთა წყარო ან დანიშნულება NIC-ზე არ არის მინიჭებული; ის არ რთავს net.ipv4.ip_forward-ს და სტუმრის პარამეტრი ღრუბლის ნებართვას არ იძლევა.

გვირაბის სოკეტს თავისი წყაროს გადაწყვეტილება აქვს

WireGuard-ის Address wg-quick-ის ქვეშ ანიჭებს მისამართს WireGuard-ის ინტერფეისს; ეს არ არის გარე UDP მიბმის ინსტრუქცია. დაშიფრული სოკეტის წყარო მიჰყვება მარშრუტების ცხრილს, ამიტომ პოლიტიკის მარშრუტს ან მეორე ნაგულისხმევ მარშრუტს შეუძლია მისი გადაადგილება ინტერფეისის მისამართზე ხელის შეუხებლად.OpenVPN-ის local ოფცია და UDP multihome იგივენაირად იქცევიან: ისინი ეხება მსმენელს და მის პასუხებს, და არა ყოველი გადამისამართებული კლიენტის ინტერნეტ წყაროს.

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

რა უნდა მივიღოთ და რა თანმიმდევრობით

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

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