ერთ Azure VM-ს გვირაბი სჭირდება: სტუმრის კლიენტი თუ VPN კარიბჭე?

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

ორი სამუშაო, რომლებიც ერთნაირად გამოიყურება

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

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

პირობა პირველი: სჭირდება სხვა რამეს შორეული მხარე?

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

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

პირობა მეორე: შეგიძლიათ შეინარჩუნოთ ადმინისტრირების გზა?

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

შეამოწმეთ მანამდე და მერე. Linux-ში ip route get <management-ip> გვიჩვენებს, რომელ ინტერფეისსა და წყაროს გამოიყენებდა ბირთვი ახლა; შეადარეთ ეს პასუხს, სანამ გვირაბი ჩართულია. გაყოფილი გვირაბი გამოკვეთილი დანიშნულებების სიით უფრო ადვილად დასაცავია, ვიდრე ნაგულისხმევი მარშრუტი, და ჩვეულებრივ სწორედ ეს სჭირდება დატვირთვას.

პირობა მესამე: ვინ აყენებს განახლებებს შუაღამისას?

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

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

რას არ აკეთებს მართული კარიბჭე

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

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

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

დაგეგმეთ ზრდის გზა, სანამ დაგჭირდებათ

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

სწორი საწყისი წერტილი, როცა კავშირი ქსელური მასშტაბისაა და არა დატვირთვის, Azure VPN Gateway-ის მიმოხილვაა.

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