რატომ არ ცვლის Azure Point-to-Site VPN თქვენს საჯარო IP-ს
Point-to-site გვირაბი მხოლოდ ვირტუალური ქსელის მარშრუტებს გადააქვს, ამიტომ თქვენი საჯარო IP ლოკალური რჩება, სანამ იძულებითი გვირაბირება და firewall-ის SNAT გასასვლელს Azure-ში გადაიტანს.
Azure VPN კლიენტს Windows-ის ლეპტოპზე ვაერთებ, მისამართის ექოს გვერდს ვხსნი და იმავე საჯარო მისამართს ვხედავ, რომელიც ჩემმა სახლის როუტერმა გასცა. ამასობაში 10.20.0.4-ზე მდებარე jump box პასუხობს და პირადი endpoint-ის სახელი იხსნება, ამიტომ გვირაბი გატეხილი არ არის. Point-to-site კარიბჭე ზუსტად იმას აკეთებს, რასაც მისი ნაგულისხმევი კონფიგურაცია ამბობს: გადააქვს პირადი პრეფიქსები და დანარჩენ ყველაფერს ლოკალურ ბმულზე ტოვებს. Azure-ის კუთვნილი გასასვლელი მისამართის მიღება მარშრუტიზაციის დიზაინის ცვლილებაა, არა შეკეთება.
რას აცხადებს კარიბჭე ნაგულისხმევად
კარიბჭე უგზავნის მარშრუტებს ვირტუალური ქსელის მისამართების სივრცეს, ასევე თანატოლ ქსელებს, სადაც კარიბჭის ტრანზიტი დაშვებულია, და ლოკალურ პრეფიქსებს, რომლებიც site-to-site კავშირით ან BGP-ით ისწავლება. ამ ნაკრებში 0.0.0.0/0 არ არის. თქვენი ოპერაციული სისტემა ნაგულისხმევ მარშრუტს Wi-Fi-ზე ან Ethernet-ზე ინახავს, ამიტომ საჯარო API-ისკენ მიმავალი პაკეტი გვირაბში საერთოდ არ შედის.
მისამართი, რომელსაც კლიენტი გვირაბის შიგნით იღებს, point-to-site-ის აუზიდან პირადი იჯარაა. ის კლიენტს VNet-ის რესურსებისთვის იდენტიფიცირებს; ეს არ არის მისამართი, რომელსაც ინტერნეტი ხედავს, და არასდროს გამოჩნდება როგორც SaaS API-ისკენ მიმავალი გამავალი მოთხოვნის წყარო. ამ იჯარის ირგვლივ აგებული allowlist-ის ჩანაწერი ვერ იმუშავებს, რამდენ ხანსაც არ უნდა დაელოდოთ მის გამოჩენას გამყიდველის ჟურნალებში.
გაყოფილი გვირაბი და იძულებითი გვირაბირება გვერდიგვერდ
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
მხოლოდ მეორე რიგი ცვლის მისამართს, რომელსაც დისტანციური სერვისი ხედავს. დანარჩენი ყველაფერი ამ ცხრილში ხარჯი და ოპერაციული ზედაპირია, რომელსაც თქვენ იღებთ, როცა გასასვლელი Azure-ის შიგნით უნდა შემოწმდეს ან გადაითარგმნოს. თუ ვინმე გთხოვთ, რომ საჯარო IP შეიცვალოს, ის მთელ მარჯვენა სვეტს ითხოვს, და არა კლიენტში პატარა კორექტირებას.
სანამ რამეს გადააკეთებთ, ღირს შუალედური ვარიანტის დასახელება. VNet-ის შიგნით proxy ან კარიბჭის VM გაძლევთ კონტროლირებად წყაროს მისამართს იმ აპლიკაციებისთვის, რომელთა მიმართვაც შეიძლება, კლიენტის ნაგულისხმევი მარშრუტის გადაადგილების გარეშე. ეს ჩვეულებრივ დათვალიერებას ლოკალურად ტოვებს და მაინც აკმაყოფილებს პარტნიორს, რომელსაც მხოლოდ ერთი API გამოძახების Azure-იდან მოსვლა სჭირდება. ის ვერ უმკლავდება, როცა მოთხოვნა ნამდვილად მთელ ტრაფიკს ეხება, რადგან ყველაფერი, რაც proxy-ის პარამეტრს უგულებელყოფს, მაინც ლოკალურად გადის.
აიძულეთ გვირაბი ნაგულისხმევი მარშრუტი ატაროს
ვირტუალური ქსელის კარიბჭეზე კლიენტის მთელი ინტერნეტ ტრაფიკის გვირაბში მიმართვის მხარდაჭერილი გზაა point-to-site კონფიგურაციაში მორგებული მარშრუტების დამატება. ორი ნახევარი მთელ IPv4 სივრცეს ფარავს და თითოეული ლოკალურ ნაგულისხმევ მარშრუტზე უფრო კონკრეტულია, ამიტომ კლიენტი მათ ამჯობინებს არაფრის წაშლის გარეშე:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1ეს ხაზი საილუსტრაციოა და არა კოპირებისთვის სრული: ჯერ მიიღეთ კარიბჭის ობიექტი Get-AzVirtualNetworkGateway-ით და ჩაანაცვლეთ GWOBJ, და გაშვებამდე დაადასტურეთ, რომ SKU და განლაგების მოდელი მორგებულ მარშრუტებს იღებს. იგივე პრეფიქსები პორტალზე point-to-site კონფიგურაციის გვერდზე ჩანს, რაც უფრო უსაფრთხო ადგილია მათი დასაყენებლად, თუ კარიბჭეს ჯერ არ სკრიპტავთ.
ამ პრეფიქსების შეცვლა კლიენტის პაკეტს ბათილს ხდის. ჩამოტვირთეთ VPN კლიენტის პაკეტი ხელახლა და გადააყენეთ, რადგან მარშრუტები პროფილის შიგნით მოძრაობს. კლიენტი, რომელიც ძველი პროფილით ხელახლა უკავშირდება, ძველ მარშრუტთა ნაკრებს ინახავს, და შეიძლება საათი დაკარგოთ იმ ცვლილების გამართვაზე, რომელიც მას არასდროს მიუღწევია.
დაცულ ვირტუალურ WAN ჰაბში ეკვივალენტია ნაგულისხმევი მარშრუტი ჰაბის მარშრუტების ცხრილში, რომელიც point-to-site კარიბჭესთან არის დაკავშირებული, ტრაფიკს კი ჰაბის Azure Firewall იღებს. Firewall ინტერნეტისკენ მიმავალ კავშირებს საკუთარ საჯარო IP მისამართებზე თარგმნის და სწორედ ამ თარგმანიდან მოდის ახალი გასასვლელი მისამართი. როცა firewall-ს რამდენიმე საჯარო IP აქვს, ნებისმიერი მათგანი შეიძლება გამოჩნდეს წყაროდ, ამიტომ allowlist-მა ყველა უნდა შეიცავდეს.
ზემოთ მოცემული ორივე დიზაინი IPv4-ია. ორი /1 პრეფიქსი IPv6-ისთვის არაფერს აკეთებს და point-to-site-ის IPv6 მხარდაჭერა საკმარისად ვიწროა, რომ კომბინაცია გამოსცადოთ სანამ თანასწორობას დაპირდებით.
შეამოწმეთ მარშრუტი, შემდეგ გასასვლელი
პაკეტის ხელახალი დაყენებისა და ხელახალი დაკავშირების შემდეგ დაადასტურეთ, რომ კლიენტმა ნახევრები ნამდვილად დააყენა. Windows-ზე Get-NetRoute -DestinationPrefix 0.0.0.0/1 და იგივე მოთხოვნა 128.0.0.0/1-ისთვის გვირაბის ინტერფეისს უნდა ასახელებდეს, route print კი ორივეს თქვენი საწყისი ნაგულისხმევის გვერდით აჩვენებს. Linux-ზე ip route show-მ ორი პრეფიქსი უნდა ჩამოთვალოს; თუ არ აკეთებს, პროფილს ისინი არასდროს გადაუტანია.
შემდეგ კვლავ შეამოწმეთ საჯარო მისამართი კლიენტიდან და წაიკითხეთ firewall-ის ჟურნალი იმავე კავშირისთვის. წყარო უნდა იყოს firewall-ის საჯარო IP თარგმნილი პორტით. კლიენტი, რომელიც ჯერ კიდევ ლოკალურად გადის, მაშინ როცა ორივე მარშრუტი არსებობს, ნიშნავს, რომ პაკეტებმა Azure-ს მიაღწიეს და სხვა გზით გავიდნენ: მომხმარებლის განსაზღვრული მარშრუტი კარიბჭის ქვექსელზე, firewall, რომელიც თავად იძულებით გვირაბირებულია ლოკალურ ქსელში, ან პოლიტიკა, რომელიც ნაკადს თარგმანამდე ყრის.
იმავე სესიაში კვლავ გამოსცადეთ ერთი პირადი დანიშნულება. Jump host, რომელიც ცვლილების შემდეგ პასუხს წყვეტს, ჩვეულებრივი ნიშანია, რომ ახალმა პრეფიქსებმა რაღაც განდევნა: ან ადრე გამოცხადებული უფრო ვიწრო ლოკალური მარშრუტი, ან სახელების ამოხსნა, რომელიც ახლა თქვენი პირადი ზონებისთვის გადამცემის გარეშე resolver-ზე მიდის.
როდის დატოვოთ გაყოფილი გვირაბი მშვიდად
თუ მიზანი მხოლოდ პირად API-ზე, პირად endpoint-ზე ან შიდა ადმინისტრატორის გვერდზე მისვლაა, ნაგულისხმევი ქცევა უფრო იაფი და მშვიდია. იძულებითი გვირაბირება ამატებს firewall-ის საათებს და მონაცემთა დამუშავების ხარჯებს, გრძელ გზას და კიდევ ერთ ადგილს, სადაც ყოველი კლიენტის ნაკადი შეიძლება ჩავარდეს. ის ასევე გაცილებით მეტ ტრაფიკს იჭერს, ვიდრე ის ერთი დანიშნულება, რომელიც გაწუხებდათ.
მიმართეთ მას, როცა მოთხოვნა გასასვლელის თვალსაზრისითაა ჩამოყალიბებული: პარტნიორმა უნდა დაინახოს ფიქსირებული Azure მისამართი, უსაფრთხოებას კავშირების ჟურნალირება და შემოწმება სურს, ან მონაცემებმა ერთი კონტროლირებადი წერტილიდან უნდა გაიაროს. მაშინაც კი დიზაინი ყველა მომხმარებელს საერთო გასასვლელს აძლევს, ამიტომ მომხმარებლის მიხედვით პასუხისმგებლობა აპლიკაციაში არსებული იდენტობიდან უნდა მოვიდეს, და არა წყაროს მისამართიდან.
სანამ ცვლილებას დახურავთ, დაადასტურეთ ოთხი რამ: დაყენებული კლიენტის პაკეტი ახალია, ორი /1 მარშრუტი გვირაბის ინტერფეისზეა, პირადი დანიშნულება ჯერ კიდევ პასუხობს, და დისტანციური სერვისის ჟურნალი firewall-ის მისამართს აჩვენებს.