Azure P2S VPN میں مستقل IP: کلائنٹ کا پتہ کیوں بدلتا ہے
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 معیاری SKU کا عوامی IP استعمال کرتے ہیں، اور وہ تقسیم مستقل ہونی چاہیے۔
یہی استحکام آن پریمائسز ساتھی کو اپنی ترتیب میں درکار ہوتا ہے، اور یہ کسی انفرادی کلائنٹ کی شناخت کے بارے میں کچھ نہیں کہتا۔ جب ساتھی پوچھے کہ وہ کون سا پتہ دیکھے گا، جواب site-to-site میں گیٹ وے کا عوامی IP، یا مشترکہ NAT رینج ہے — کبھی لیپ ٹاپ کی سرنگ لیز نہیں۔
گروپ پول آپ کو ایسی رینج دیتے ہیں جس کے خلاف قاعدہ لکھنا کارآمد ہے
Virtual WAN point-to-site صارف گروپوں کی حمایت کرتا ہے، اور ہر گروپ کو اس کا اپنا کلائنٹ پتہ پول دیا جا سکتا ہے۔ رکنیت شناخت سے طے ہوتی ہے، اس لیے جس رینج میں کلائنٹ آتا ہے وہ قابل پیشین گوئی ہو جاتی ہے: کارروائیاں ایک رینج میں، ٹھیکیدار دوسری میں، اور رینج وہ چیز ہے جس کا نام فائر وال یا 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 ہے۔ وہ پیر سابقے کی اجازت دیتے ہیں، ان کی طرف نظر آنے والا پتہ گیٹ وے کا ہے، اور کوئی لیپ ٹاپ ری بوٹ کرے تو وہ نہیں بدلتا۔
کوئی اور اجازت فہرست میں ترمیم کرنے سے پہلے پول جانچیں
پول کی دو خصوصیات وہ رویہ پیدا کرتی ہیں جس کا الزام لوگ کلائنٹ پر ڈالتے ہیں۔ بہت چھوٹا پول لیز جلدی دوبارہ استعمال کرتا ہے، اس لیے پتے مسلسل سرکتے دکھتے ہیں اور پتے پر مبنی کوئی بھی قاعدہ بناوٹ ہی سے غیر مستحکم لگتا ہے۔ جو پول آن پریمائسز رینجوں یا مجازی نیٹ ورک کی پتہ جگہ سے ہم پلہ ہو وہ ایسی روٹنگ ابہام پیدا کرتا ہے جسے کوئی فائر وال قاعدہ درست نہیں کرتا۔
کسی قاعدے کو چھونے سے پہلے تین چیزیں ایک صفحے پر رکھیں: point-to-site پول، مجازی نیٹ ورک کی پتہ جگہ اور آن پریمائسز رینج۔ یہ ہم پلہ نہیں ہونے چاہئیں، اور پول کو ہر بیک وقت کلائنٹ کے لیے جگہ اور دوبارہ جڑنے کے لیے کچھ حاشیہ درکار ہے۔
پھر اس ترتیب سے چکر بند کریں:
- دو مشینوں سے دونوں ترتیبوں میں جڑ کر پتوں کا موازنہ کریں؛ اگر وہ بدل سکتے ہیں تو پتے پر مبنی کوئی قاعدہ محفوظ نہیں۔
- دیکھیں کہ گیٹ وے Virtual WAN ہے یا نہیں؛ اگر ہے تو فی پتہ قواعد کے بجائے گروپ پول استعمال کریں۔
- پوچھیں کہ جب قاعدہ غلط شخص سے ٹکرائے تو کیا ہوتا ہے؛ جواب رسائی کا واقعہ ہو تو کنٹرول شناخت پر منتقل کریں۔
- کون سی رینج کس گروپ کی ہے، NSG تعریفوں والے اسی مخزن میں درج کریں۔
- پول، توثیق یا گیٹ وے کی کسی بھی تبدیلی کے بعد دوبارہ آزمائیں، کیونکہ وہ تبدیلیاں اعلان کے بغیر نقشہ بندی دوبارہ لکھتی ہیں۔