Azure VPN پریفکس شامل کرنے سے کنکشن کیوں ٹوٹتا ہے

غلط Azure آبجیکٹ میں شامل کردہ پریفکس ایسا کنکشن بناتا ہے جو Connected بتاتا ہے اور کچھ آگے نہیں بھیجتا، اور یہ اس اسٹیک میں سب سے مہنگی غلطی کی قسم ہے۔ تین وسائل شامل ہیں اور ان میں سے صرف ایک کے پاس دور کا پتہ کی جگہ ہے: ورچوئل نیٹ ورک گیٹ وے، دور کا رخ بیان کرنے والا مقامی نیٹ ورک گیٹ وے، اور انہیں جوڑنے والا کنکشن۔ پریفکس مقامی نیٹ ورک گیٹ وے کا ہے، تبدیلی لاگو ہونے کے لیے کنکشن دوبارہ بنانا پڑتا ہے، اور گیٹ وے خود عام طور پر اچھوتا رہتا ہے۔ ترتیب پر بات چیت نہیں ہو سکتی، اور پورٹل اس کا صرف ایک حصہ دکھاتا ہے۔

تین آبجیکٹ، جن میں سے ایک پریفکس رکھتا ہے

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

ایک تیسری شرط بھی ہے جسے ذہن میں رکھنا چاہیے۔ GatewaySubnet منظم گیٹ وے انسٹانسز کی میزبانی کرتا ہے، بالکل وہی نام رکھنا چاہیے، اور غیر-Basic SKU کے لیے کم از کم /27 ہونے کی توقع ہے۔

اس سب نیٹ میں اور کچھ نہیں آتا، اور پریفکس کی تبدیلی کا اسے چھونے کی کوئی وجہ نہیں ہے۔ مقامی نیٹ ورک گیٹ وے میں نہ ہونے والا پریفکس کنکشن کی حالت جو بھی کہے، ناقابل رسائی ہے، کیونکہ گیٹ وے ٹنل پر بات چیت کرتے وقت صرف وہی پریفکس پیش کرتا ہے جن کی اسے اطلاع دی گئی تھی۔ اسی لیے علامت غیر متوازن ہے: ٹنل اوپر ہے، سیکیورٹی ایسوسی ایشن ٹھیک ہے، اور ایک سب نیٹ کبھی ٹریفک منتخب کنندگان میں نظر نہیں آتا۔ اگر پڑوسی کام کر رہے ہوں اور ایک دور کی رینج غائب ہو، تو ٹنل دیکھنا بند کریں اور مقامی نیٹ ورک گیٹ وے پڑھیں۔

کنکشن ہی کیوں ہٹایا جاتا ہے

کنکشن آبجیکٹ اپنی پوری زندگی کے لیے طے شدہ کنفیگریشن کو مستحکم رکھتا ہے۔ اسی لیے دستاویزی طریقہ کار پہلے کنکشن ہٹاتا ہے، مقامی نیٹ ورک گیٹ وے کو اپ ڈیٹ کرتا ہے، اور پھر اسی مشترکہ کلید کے ساتھ کنکشن دوبارہ بناتا ہے۔ صرف پریفکس کی تبدیلی کے لیے گیٹ وے انسٹانسز دوبارہ نہیں بنائے جاتے، جو رکاوٹ کو گیٹ وے کی دوبارہ تعیناتی کے بجائے کنکشن توڑنے تک محدود رکھتا ہے۔

وہ حذف کرنا ہی رکاوٹ ہے، اس لیے اسے فوری ترمیم کے بجائے آغاز اور متوقع اختتام والی منصوبہ بند تبدیلی سمجھیں۔ PowerShell میں ترتیب مختصر ہے: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force، پھر Set-AzLocalNetworkGateway نئی -AddressPrefix صف کے ساتھ، پھر New-AzVirtualNetworkGatewayConnection اسی -SharedKey اور انہی گیٹ ویز کے ساتھ۔ کلید کا دوبارہ استعمال اہم ہے، کیونکہ دور کا رخ دوبارہ کنفیگر نہیں ہوتا اور نئی کلید کا مطلب دور کے آلے کے مالک کے ساتھ ہم آہنگی ہے۔ اگر وہ آلہ کوئی دوسری ٹیم چلاتی ہے، تو کچھ بھی ہٹانے سے پہلے ان کے ساتھ وقت کی کھڑکی طے کریں۔

گیٹ وے خود کب دوبارہ بنانا پڑتا ہے

اس مسئلے کے گرد گھومنے والا دوسرا جواب کہتا ہے کہ گیٹ وے دوبارہ بنانا پڑے گا اور کلید دوبارہ بدلنی پڑے گی۔ یہ مختلف قسم کے کاموں کے لیے درست ہے: گیٹ وے کی قسم یا SKU تبدیل کرنا، پوائنٹ ٹو سائٹ اور سائٹ ٹو سائٹ کے درمیان جانا، یا ایسے گیٹ وے کی مرمت کرنا جس کی اپنی کنفیگریشن غلط ہے۔ ایسی تبدیلیاں واقعی گیٹ وے وسائل بدلتی ہیں، اس لیے دوبارہ بنانا واقعی ضروری ہے۔

پوائنٹ ٹو سائٹ کے لیے بنائے گئے گیٹ وے کو سیدھا سائٹ ٹو سائٹ کنکشن نہیں دیا جا سکتا۔ پوائنٹ ٹو سائٹ کنفیگریشن ہٹانا پڑتی ہے اور گیٹ وے دوبارہ بنانا پڑتا ہے، جو نئی مشترکہ کلید اور نیا کلائنٹ پیکج بھی دیتا ہے۔

پوائنٹ ٹو سائٹ پیکج کو اپنا نوٹ چاہیے کیونکہ اس کی مدت ختم ہو جاتی ہے۔ پورٹل مختصر عمر کی فائل بناتا ہے، اس لیے عملی طریقہ یہ ہے کہ اسے ایک بار ڈاؤن لوڈ کریں اور کلائنٹ سرٹیفکیٹ کے ساتھ تقسیم کریں، نہ کہ صارفین کو پورٹل لنک بھیجیں جو ان کے کلک کرنے تک مردہ ہو گا۔ پریفکس کے سوال پر ان میں سے کچھ بھی لاگو نہیں ہوتا۔ دونوں طریقہ کار کو الگ رکھنا ہی پورا نظم ہے: پریفکس کنکشن کی سطح کی تبدیلی ہیں، اور گیٹ وے کی خصوصیات گیٹ وے کی سطح کی تبدیلی ہیں۔

حالت پڑھیں، پورٹل کا بیج نہیں

پورٹل کے بیج کے بجائے وسائل سے حالت پڑھیں۔ Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 واپس کرتا ہے ConnectionStatus انگریس اور ایگریس بائٹ کاؤنٹرز کے ساتھ، اور جڑے ہوئے مگر کچھ نہ ڈھونے والے ٹنل کو کبھی قائم نہ ہوئے ٹنل سے الگ کرنے والے یہی کاؤنٹرز ہیں۔

ٹرانسفر کے وسط میں بڑھنا روک دینے والے کاؤنٹرز تصدیق کی طرف نہیں، راستے کی طرف اشارہ کرتے ہیں. بالکل نہ ہلنے والے کاؤنٹرز پریفکس سیٹ یا مشترکہ کلید کی طرف اشارہ کرتے ہیں۔

VPN پر غلط طور پر ڈالے جانے والے ایک قسم کے ڈسکنکٹ کو ٹائمرز بیان کرتے ہیں۔ Azure کا لوڈ بیلنسر اپنے مقررہ وقت کے بعد غیر فعال بہاؤ بند کرتا ہے، یہ نوٹ لکھے جانے کے وقت ڈیفالٹ چار منٹ اور اوپر کی طرف کنفیگر کیا جا سکتا ہے، اس لیے keepalive کے بغیر VM پر OpenVPN سرور ہر چند منٹ میں گر سکتا ہے جبکہ باقی سب صحت مند دکھتا ہے۔ پلیٹ فارم جس گیٹ وے کو چکری طور پر دوبارہ شروع کرتا ہے وہ بھی VNet کنکشن کو Web App سے روک سکتا ہے، اور وہ ناکامی کلائنٹ کنفیگریشن میں نہیں، پلیٹ فارم کی طرف ہے۔ اشارہ یہ ہے کہ ڈسکنکٹ مقررہ وقفے کی پیروی کرتا ہے یا آپ کی کی گئی تبدیلی کی۔

تینوں آبجیکٹ اور ان کی اقدار ایک ہی ریکارڈ میں رکھیں: ورچوئل نیٹ ورک کی پتہ کی جگہ، مقامی نیٹ ورک گیٹ وے کی پریفکس فہرست، اور کنکشن کی مشترکہ کلید کا حوالہ۔ سائٹ ٹو سائٹ PowerShell مضمون مقامی نیٹ ورک گیٹ وے کے کمانڈز اور وہ ترتیب جس میں وہ آنے چاہئیں، دستاویز کرتا ہے۔ پریفکس کی تبدیلی کا یادداشت سے موازنہ کرنا ہی کام کرتے ٹنل کو دو بار دوبارہ بنانے کا طریقہ ہے۔

پھر اسی ترتیب میں جانچ کریں جس میں آپ نے تبدیلی کی: مقامی نیٹ ورک گیٹ وے نئی پریفکس فہرست دکھاتا ہے، کنکشن دوبارہ Connected ہے، اور نئی رینج کے ہوسٹ پر ٹریفک بھیجنے پر کاؤنٹرز ہلتے ہیں۔ اگر پہلے دو پاس ہوں اور تیسرا مرحلہ ناکام ہو، تو دور کی جانب نے نیا ٹریفک منتخب کنندہ قبول نہیں کیا اور دور کے آلے کو مطابق مرحلہ 2 اندراج چاہیے۔ یہ ٹنل کے دوسرے سرے سے گفتگو ہے، Azure میں ایک اور تبدیلی نہیں۔