სად გამოვიყენოთ NSG Azure-ის საიტიდან საიტზე VPN ტრაფიკისთვის

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

განათავსეთ NSG იქ, სადაც Azure აფასებს მას

სამუშაო დატვირთვის ფილტრაციის მხარდაჭერილი საზღვარი არის სამიზნე ქვექსელი ან სამიზნე ქსელური ინტერფეისი. კარიბჭის ქვექსელი ინფრასტრუქტურაა, და Azure ადასტურებს, რომ იქ NSG-ები არ არის მხარდაჭერილი და შეიძლება დააზიანოს კარიბჭის მუშაობა.

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

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

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

იპოვეთ წყაროს მისამართი გაშიფვრის შემდეგ

შიდა წყარო არის ლოკალური კლიენტის კერძო მისამართი, ან მისამართი, რომელსაც მოწყობილობა ან VPN-ის NAT წარადგენს თარგმანის შემდეგ. ეს არ არის ლოკალური VPN კარიბჭის საჯარო მისამართი, რომელიც გარე გაცვლას ეკუთვნის.

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

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

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

შეამოწმეთ ნაგულისხმევი VirtualNetwork-ის არე

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

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

Microsoft-ის სერვისის ტეგების დოკუმენტაცია ჩამოთვლის, რას მოიცავს VirtualNetwork ტეგი, და ეს არის ის ცნობარი, რომელზეც მიუთითებენ, როცა ვიღაც ამტკიცებს, რომ ტეგი მხოლოდ VNet-ის დიაპაზონს ნიშნავს.

წაიკითხეთ ეფექტური წესები ორივე საზღვარზე

როცა მოქმედებს ორივე — ქვექსელის NSG და NIC-ის NSG — ნაკადმა უნდა დააკმაყოფილოს ორივე. ნებართვა ერთში არ აუქმებს უარყოფას მეორეში, და პაკეტი რეალურად შეხვდება ერთიან ხედს.

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

თუ მოქმედებს Azure Virtual Network Manager-ის უსაფრთხოების ადმინისტრატორის წესები, გადახედეთ ამ ფენასაც. ადმინისტრაციულ Always allow წესს შეუძლია ტრაფიკის მიწოდება NSG-ის შეფასების გარეშე, ხოლო ადმინისტრაციული Deny აჩერებს მას სანამ NSG-ები დაინახავენ. მხოლოდ NSG-ის გადახედვა არასრულია ასეთი მოწყობისთვის.

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

გადაამოწმეთ ახალი კავშირით

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

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

NSG-ის ნებართვა ერთი წვდომის გადაწყვეტილებაა, არა მარშრუტი და არა მსმენელი. თუ წესი ნაკადს უშვებს და კავშირი მაინც ვერ ხდება, შეამოწმეთ კლიენტის გზა VPN-ში, Azure-ის დაბრუნების მარშრუტი და ჰოსტის ფაირვოლი, სანამ ჯგუფს ხელახლა შეასწორებთ. ჩაწერეთ ფაქტობრივი წყაროს მისამართი, NSG-ის ასოციაციები და შესაბამისი წესი დამტკიცებულ სერვისთან ერთად, რადგან შემდეგი peering-ის ან მარშრუტის ცვლილებამ შეიძლება შეცვალოს, რას მოიცავს VirtualNetwork ტეგი.