სტატიკური IP Azure P2S VPN-ში: რატომ იცვლება კლიენტის მისამართი
Azure point-to-site ყოველ დაკავშირებაზე გასცემს აუზის შემდეგ თავისუფალ მისამართს, ამიტომ კლიენტის ფიქსირებული IP არ არსებობს. წვდომა დაუკავშირეთ დიაპაზონებს ან იდენტობას.
ყოველი Azure point-to-site კლიენტი აუთენტიფიკაციისას იღებს მისამართს აუზიდან და ინახავს მას მხოლოდ იმ კავშირის ხანგრძლივობის განმავლობაში. არ არსებობს სარეზერვო ცხრილი, არ არის მომხმარებლის მიხედვით დაკავშირება და არ არის კარიბჭის ისეთი პარამეტრი, რომელიც ნიშნავს „ყოველთვის მიეცი ამ ადამიანს 172.16.0.10“. სწორედ ეს ერთი მექანიზმი ხსნის ორ სიმპტომს, რომლებსაც ადამიანები მოგვიანებით ხვდებიან: NSG წესს, რომელიც წყვეტს იმ მომხმარებელთან შესაბამისობას, რომელთანაც ადრე შეესაბამებოდა, და დაშვებულთა სიას, რომელიც ჩუმად უშვებს მანქანას, რომელიც არავის განზრახ არ დაუმატებია. წესის უფრო ჭკვიანი IP წესით ჩანაცვლება არცერთს არ ასწორებს, რადგან ის, რასაც წესი ასახელებს, ხელახლა ნაწილდება იმ გრაფიკით, რომელსაც თქვენ არ აკონტროლებთ.
აუზი ტევადობაა და არა იდენტობა. ის არსებობს იმისთვის, რომ ერთდროულმა გვირაბებმა მიიღონ უნიკალური მისამართები, და იმ მომენტში ხელახლა იყენებს მათ, როცა იჯარა მთავრდება. როცა ეს ნათელია, სასარგებლო კითხვა წყვეტს „როგორ დავამაგრო ეს კლიენტი“ ყოფნას და ხდება „რის წინააღმდეგ შემიძლია დავწერო წესი, რომელსაც კარიბჭე ხელახლა არ გამოიყენებს“.
რას აკეთებს კარიბჭე სინამდვილეში, როცა კლიენტი უკავშირდება
კარიბჭე ინახავს კონფიგურირებულ კლიენტის მისამართების აუზს და განიხილავს მას როგორც იჯარების ცხრილს. დაკავშირებისას იღებს შემდეგ თავისუფალ მისამართს, პრაქტიკაში ყველაზე დაბალ ხელმისაწვდომს, და ანიჭებს მას გვირაბის ადაპტერს, სანამ კლიენტი გაითიშება ან იჯარა ამოიწურება. წყვეტს რიგი და არა იდენტობა: ვინც მშვიდი პერიოდის შემდეგ პირველი დაუკავშირდება, იღებს ყველაზე დაბალ მისამართს, რომელიც იმ მომენტში შემთხვევით თავისუფალია.
აუზის ზომა მალავს ქცევას. ლაბორატორიული აუზი, რომელიც ტესტირების მონაწილეთა რაოდენობაზე ერთი-ორი მისამართით დიდია, დეტერმინისტულად გამოიყურება, რადგან იგივე ლეპტოპი ჩვეულებრივ ყოველ დილით იმავე რიგით უკავშირდება. დაამატეთ მესამე მანქანა, შეცვალეთ აუზის ზომა ან დატოვეთ სესია ჩართული სადილის განმავლობაში და ნიმუში იშლება. მისამართი არასოდეს ყოფილა სტაბილური; რიგი იყო.
point-to-site კონფიგურაციის ნებისმიერი ცვლილება ასევე ახდენს იჯარის სივრცის განულებას. სხვა ტიპის აუთენტიფიკაცია, შეცვლილი ზომის აუზი, ახალი აუზის დიაპაზონი ან დანგრეული და ხელახლა აშენებული კარიბჭე ყველა აბრუნებს კლიენტებს აუზში, რომელიც აღარ შეესაბამება მათ ძველ მისამართებს. ამ ცვლილების არაფერი ეხება თქვენს NSG-ს, ამიტომაც გაუმართაობა სპონტანურად გამოიყურება.
ამის დანახვა დაახლოებით ერთ წუთში შეიძლება. დაუკავშირდით, ჩაწერეთ გვირაბის მისამართი კლიენტის კავშირის დეტალებში, გათიშეთ, დააკავშირეთ მეორე მანქანა, შემდეგ კვლავ დააკავშირეთ პირველი. მიღებული მისამართი დამოკიდებულია იმაზე, რასაც მეორე მანქანა იკავებს, და არცერთი პორტალის პარამეტრი არ აღადგენს წინას მოთხოვნით.
კლიენტის IP-ზე დაფუძნებული NSG სინამდვილეში დაკავშირების რიგის შესახებ წესია
წესი, რომელსაც ადამიანები პირველად წერენ, აშკარაა: შემომავალი წესი მართვის VM-ის NIC-ზე ან მის ქვექსელზე, წყაროდ VPN კლიენტის შიდა მისამართით. მოკლეა, გადის ტესტს დაწერის დღეს და ვარდება მაშინვე, როცა აუზში ერთზე მეტი თავისუფალი მისამართია.
აქედან ორი წარუმატებლობის რეჟიმი გამომდინარეობს და მხოლოდ ერთი ჰგავს შეცდომას. ლეგიტიმურ მომხმარებელს უარს ეუბნებიან, რადგან იმ მომენტში სხვას უჭირავს ის მისამართი, რომელსაც წესი ასახელებს, და ეს მოდის როგორც შემაწუხებელი მხარდაჭერის ბილეთი. ან არასასურველ მომხმარებელს უშვებენ, რადგან მან მემკვიდრეობით მიიღო მისამართი, რომელსაც წესი ჯერ კიდევ ენდობა, და ეს საერთოდ არაფრად მოდის, სანამ ვინმე წვდომას აუდიტს არ გაუწევს.
რადგან წესი იჯარას მიჰყვება, ეფექტური პოლიტიკა ამბობს: „ვინც პირველი დაუკავშირდება, ის იღებს მართვის წვდომას“. ეს დაკავშირების რიგის აღწერაა განზრახვის სამოსში და არცერთი წესების ჰიგიენა მას განზრახვის გამოხატულებად არ აქცევს.
კლიენტის იჯარა და კარიბჭის მისამართი სხვადასხვა ობიექტია
დაბნეულობის უმეტესობა ერთი სიტყვიდან მოდის. კარიბჭეს აქვს შედარებით სტაბილური საჯარო IP; კლიენტებს აქვთ აუზიდან მიღებული კერძო მისამართები, რომლებიც სტაბილური არ არის. არაზონალური რეზერვირების VPN კარიბჭისთვის საჯარო IP დინამიკურად გამოიყოფა, მაგრამ ის გადაურჩება ზომის შეცვლას, გადატვირთვას და რუტინულ მომსახურებას — ის იცვლება მაშინ, როცა თავად კარიბჭე წაიშლება და ხელახლა შეიქმნება. ზონალური რეზერვირების და ზონალური კარიბჭის SKU-ები იყენებენ Standard SKU-ის საჯარო IP-ს და ეს გამოყოფა სტატიკური უნდა იყოს.
ეს სტაბილურობაა ის, რაც ადგილობრივ პარტნიორს სჭირდება კონფიგურაციაში და ის არაფერს ამბობს ცალკეული კლიენტის იდენტიფიცირებაზე. როცა პარტნიორი კითხულობს, რომელ მისამართს დაინახავს, პასუხია კარიბჭის საჯარო IP site-to-site-ში ან საერთო NAT დიაპაზონი — არასოდეს ლეპტოპის გვირაბის იჯარა.
ჯგუფური აუზები გაძლევთ დიაპაზონს, რომლის წინააღმდეგ წესების წერა ღირს
Virtual WAN point-to-site მხარს უჭერს მომხმარებელთა ჯგუფებს და თითოეულ ჯგუფს შეიძლება მიენიჭოს საკუთარი კლიენტის მისამართების აუზი. წევრობა განისაზღვრება იდენტობით, ამიტომ დიაპაზონი, რომელშიც კლიენტი ხვდება, პროგნოზირებადი ხდება: ოპერაციები ერთ დიაპაზონში, კონტრაქტორები მეორეში, და დიაპაზონი ისეთი რამ არის, რომელსაც firewall-ის ან NSG წესი გამოცნობის გარეშე დაასახელებს.
მიღებულ წესების ერთობლიობას აქვს ფორმა, რომლის გადახედვაც შეგიძლიათ:
- ერთი აუზი თითო აუდიტორიისთვის, გაზომილი პიკური ერთდროული სესიებით და არა თავების რაოდენობით;
- ჯგუფური წევრობა იდენტობით იმართება და არა წესების რედაქტირებით ყოველ ჯერზე, როცა ვინმე უერთდება;
- NSG ან Azure Firewall წესები დაწერილია აუზის დიაპაზონებზე, არასოდეს ცალკეულ იჯარებზე;
- ცალკე ჰაბი ან კარიბჭე იმ აუდიტორიებისთვის, რომლებმაც არასოდეს უნდა გაიზიარონ დიაპაზონი.
| Rule target | Survives a reconnect | What it still cannot express |
|---|---|---|
| Client tunnel address | No | Follows connection order and admits whoever holds the address next |
| Whole client pool | Yes | Grants every connected client identical access |
| Virtual WAN group pool | Yes | Only as reliable as group membership |
| Gateway public IP | Until the gateway is recreated | Identifies the site, not the person |
მთელი აუზის დაშვებულთა სიაში შეტანა პატიოსანია, მაგრამ უხეში: ამ დიაპაზონის ყოველი დაკავშირებული კლიენტი იღებს ერთსა და იმავე წვდომას. ეს არის პოლიტიკის გადაწყვეტილება, რომლის ხმამაღლა თქმა ღირს და არა გადახედვის დროს აღმოჩენა. ყველაფერი, რასაც ჯერ კიდევ სჭირდება პასუხი თითოეული ადამიანისთვის, რესურსს ეკუთვნის როლების მინიჭებით და არა პაკეტების ფილტრს.
როცა განლაგება ვერ გადავა Virtual WAN-ზე
ბევრი კარიბჭე რჩება ჩვეულებრივ VPN კარიბჭედ და Virtual WAN-ზე გადასვლა შემთხვევითი ცვლილება არ არის. პრაქტიკული პასუხია, თითოეული მომხმარებლის გადაწყვეტილება პაკეტების ფილტრიდან გადავიდეს იმაზე, რამაც უკვე იცის, ვინ არის მომხმარებელი.
რესურსის დონის იდენტობა ყველაზე იაფი ვარიანტია. Storage, SQL და Key Vault ყველა მხარს უჭერს Entra ID აუთენტიფიკაციას მომხმარებლის ან ჯგუფის როლების მინიჭებით, ამიტომ VPN-ს მხოლოდ ქსელური ხელმისაწვდომობის დამტკიცება სჭირდება. დასახელებული ანგარიშების მქონე ნახტომი ჰოსტი იმავეს აკეთებს ადმინისტრაციული სამუშაოსთვის, რადგან ჰოსტი ადამიანს აფიქსირებს და გვირაბი მხოლოდ პაკეტებს გადააქვს. კლიენტების DNS-ში რეგისტრაცია და ნომრის ნაცვლად სახელის დაშვება წესს ერთი დონით ამაღლებს. აპლიკაციის დონის იდენტობა — სერტიფიკატის სუბიექტი, ტოკენის მტკიცება, ჯგუფური წევრობა — მუშაობს, როცა გადაწყვეტილების მისაღებად ქსელს კი არა, აპლიკაციას სთხოვენ.
პარტნიორისთვის, რომელიც ფიქსირებულ წყაროს მისამართს მოითხოვს, პასუხია site-to-site ან ExpressRoute განსაზღვრული პარტნიორის პრეფიქსით. ისინი უშვებენ პარტნიორის პრეფიქსს, მათ მხარეს გამოჩენილი მისამართი კარიბჭეს ეკუთვნის და არ იცვლება, როცა ვინმე ლეპტოპს გადატვირთავს.
შეამოწმეთ აუზი, სანამ კიდევ ერთ დაშვებულთა სიას შეცვლით
აუზის ორი თვისება იწვევს იმ ქცევის უმეტესობას, რასაც ადამიანები კლიენტს აბრალებენ. ძალიან პატარა აუზი სწრაფად იყენებს იჯარებს ხელახლა, ამიტომ მისამართები გამუდმებით მოძრავი ჩანს და მისამართზე დაფუძნებული ნებისმიერი წესი დიზაინით არასაიმედოდ გამოიყურება. აუზი, რომელიც ემთხვევა ადგილობრივ დიაპაზონებს ან ვირტუალური ქსელის მისამართების სივრცეს, ქმნის მარშრუტიზაციის გაურკვევლობას, რომელსაც არცერთი firewall წესი არ ასწორებს.
სანამ წესს შეეხებით, სამი რამ ერთ გვერდზე მოათავსეთ: point-to-site აუზი, ვირტუალური ქსელის მისამართების სივრცე და ადგილობრივი დიაპაზონები. ისინი არ უნდა ემთხვეოდეს, და აუზს სჭირდება ადგილი ყოველი ერთდროული კლიენტისთვის პლუს ზღვარი ხელახალი დაკავშირებისთვის.
შემდეგ დახურეთ ციკლი ამ რიგით:
- დაუკავშირდით ორი მანქანიდან ორივე რიგით და შეადარეთ მისამართები; თუ ისინი შეიძლება გაიცვალოს, მისამართზე დაფუძნებული არცერთი წესი უსაფრთხო არ არის.
- შეამოწმეთ, არის თუ არა კარიბჭე Virtual WAN; თუ არის, გამოიყენეთ ჯგუფური აუზები მისამართის მიხედვით წესების ნაცვლად.
- იკითხეთ, რა ხდება, როცა წესი არასწორ ადამიანს ემთხვევა; თუ პასუხი წვდომის ინციდენტია, კონტროლი იდენტობაზე გადაიტანეთ.
- ჩაწერეთ, რომელი დიაპაზონი რომელ ჯგუფს ეკუთვნის, იმავე საცავში, სადაც NSG-ის განსაზღვრებებია.
- ხელახლა შეამოწმეთ აუზის, აუთენტიფიკაციის ან კარიბჭის ნებისმიერი ცვლილების შემდეგ, რადგან ეს ცვლილებები გადაწერენ დაკავშირებას გამოცხადების გარეშე.