Azure سائٹ سے سائٹ VPN ٹریفک کے لیے NSG کہاں لاگو کریں

سائٹ سے سائٹ سرنگ چل رہی ہے، مقامی کلائنٹ کچھ Azure میزبانوں تک پہنچتا ہے اور کچھ تک نہیں، اور کسی نے اسے ٹھیک کرنے کے لیے GatewaySubnet پر نیٹ ورک سیکیورٹی گروپ منسلک کر دیا ہے۔ وہیں رک جائیں۔ Azure GatewaySubnet پر NSG کی حمایت نہیں کرتا، اور گروپ اندرونی پیکٹ کو ایسے نہیں دیکھ سکتا جیسے ورک لوڈ قاعدہ دیکھتا ہے۔ پالیسی منزل سب نیٹ یا NIC پر رکھیں، ڈکرپشن کے بعد موجود ماخذ پتہ ملیں اور پھر پرانے کی بجائے نئے کنکشن سے تصدیق کریں۔

NSG وہاں رکھیں جہاں Azure اس کا جائزہ لیتا ہے

ورک لوڈ فلٹرنگ کی معاون حد منزل سب نیٹ یا منزل نیٹ ورک انٹرفیس ہے۔ گیٹ وے سب نیٹ بنیادی ڈھانچہ ہے، اور Azure دستاویز کرتا ہے کہ وہاں NSG معاون نہیں اور گیٹ وے کے کام کو نقصان پہنچا سکتے ہیں۔

جگہ کے تعین میں ایک منطقی مسئلہ بھی ہے۔ GatewaySubnet پر NSG بیرونی 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 سروس ٹیگ مقامی مجازی نیٹ ورک سے وسیع ہے۔ اس کی تعریف میں منسلک مقامی پتہ جگہیں، ہم مرتبہ نیٹ ورکس اور گیٹ وے سے منسلک دیگر سابقے شامل ہیں۔ اس کا مطلب ہے کہ 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 انجمنیں اور میل کھاتا قاعدہ منظور شدہ سروس کے ساتھ درج کریں، کیونکہ اگلی ہم مرتبگی یا راستے کی تبدیلی VirtualNetwork ٹیگ کے دائرے کو بدل سکتی ہے۔