Azure P2S VPN کا واپسی ٹریفک صرف ایک سمت میں کام کرتا ہے

ٹنل کا آئیکن سبز ہے، NSG اجازت دیتا دکھائی دیتا ہے، مؤثر راستے درست دکھائی دیتے ہیں، پھر بھی VM منسلک کلائنٹ کی طرف واپس کنکشن نہیں کھول سکتا۔ عام مفروضہ یہ ہے کہ کام کرنے والا point-to-site ٹنل ہم آہنگ ہوتا ہے: اگر کلائنٹ VM تک پہنچ سکتا ہے تو VM بھی کلائنٹ تک پہنچتا ہے۔ یہی مفروضہ استدلال کی غلطی ہے، کنفیگریشن کی نہیں۔ ٹنل غیر مطلوبہ بہاؤ کی ایک سمت لے جا سکتا ہے اور دوسری گرا سکتا ہے، اور ازالہ اس بات پر منحصر ہے کہ کون سی پرت اسے گرا رہی ہے۔

افسانہ: منسلک ٹنل دو طرفہ ٹنل ہوتا ہے

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

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

رسائی جانچنے سے پہلے سمت جانچیں

ایک کلائنٹ پتہ، ایک VM پتہ اور ایک پروٹوکول منتخب کریں۔ کلائنٹ سے جڑیں اور نتیجہ درج کریں؛ پھر وہی امتحان VM سے شروع کریں اور اسے بھی درج کریں۔ اگر پہلا کامیاب اور دوسرا ناکام ہو تو کلائنٹ پول، گیٹ وے کی وابستگی اور کلائنٹ سے VNet تک راستہ سب کام کر رہے ہیں۔

اگلا قدم ثبوت ہے، مزید قواعد نہیں۔ VM سب نیٹ پر NSG دونوں سمتوں میں جانچیں، VM کے NIC پر مؤثر راستے پڑھیں، اور کلائنٹ کے ٹریفک بھیجنے کے دوران VM پر پیکٹ کیپچر کریں۔ بغیر جواب آنے والی درخواست فلٹر یا واپسی راستے کا مسئلہ ہے؛ کبھی نہ آنے والی درخواست راستے کا مسئلہ ہے۔ ناکام ping کو VM کی عدم رسائی کا ثبوت نہ سمجھیں، کیونکہ TCP کے کام کرتے وقت ICMP پالیسی جواب گرا سکتی ہے۔

IKEv2 point-to-site واپسی راستہ ہی عام مشتبہ ہے

اس مضمون کے پیچھے موجود Azure رپورٹ میں، ایک کلائنٹ IKEv2 کے ذریعے VM تک پہنچ سکتا تھا، لیکن VM سے کلائنٹ کی طرف آنے والا ICMP اس وقت تک ناکام رہا جب تک گیٹ وے کی ٹنل قسم OpenVPN پر تبدیل نہیں کی گئی۔ رپورٹ نگار کہتا ہے کہ مائیکروسافٹ نے IKEv2 point-to-site راستے میں ایک حد کی تصدیق کی، جہاں VM سے کلائنٹ کی طرف واپسی ٹریفک ہم آہنگ طریقے سے روٹ نہیں ہوتا جب تک کلائنٹ نے سیشن شروع نہ کیا ہو۔ IKEv2 ٹریفک سلیکٹرز پر انحصار کرتا ہے، اور گیٹ وے نے اس صورت میں واپسی سمت کا احترام نہیں کیا۔

یہ OpenVPN کو عام طور پر بہتر ٹنل قسم نہیں بناتا۔ یہ اس کام کے بوجھ کے لیے جانچ میٹرکس میں ٹنل قسم کو متغیر بنا دیتا ہے۔

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

افسانہ: broadcast کے ذریعے دریافت VNet کی حد عبور کرتی ہے

دوسرا مفروضہ غیر متعلقہ وجہ سے ناکام ہوتا ہے۔ Azure ورچوئل نیٹ ورک broadcast ٹریفک نہیں لے جاتا، اس لیے VM site-to-site یا point-to-site کنکشن کے ذریعے آن پریمیس نیٹ ورک سے broadcast فریم حاصل نہیں کر سکتا۔ broadcast کے ذریعے ساتھی ڈھونڈنے والی ایپلیکیشنز، جیسے پرانی فائل براؤزنگ یا کچھ ڈیوائس ڈسکوری پروٹوکول، راستے کیسے بھی لکھے جائیں، دور والا کنارہ کبھی نہیں دیکھیں گی۔

broadcast کے ذریعے دریافت کو DNS ناموں، ڈائریکٹری سروس یا واضح ساتھی فہرست سے بدلیں۔ اگر ایپلیکیشن کے پاس unicast متبادل نہیں تو ڈیزائن کو چوڑا ٹنل نہیں بلکہ مختلف دریافت طریقہ درکار ہے۔

کیا بدلنا ہے، اور اسے کیسے ثابت کرنا ہے

اگر سمتی امتحان صرف IKEv2 پر ناکام ہو تو گیٹ وے کی ٹنل قسم، کلائنٹ پتوں کا پول اور درست ICMP یا TCP امتحان درج کریں، پھر متاثرہ کلائنٹس کے لیے منظور شدہ OpenVPN پروفائل کا جائزہ لیں۔ اگر ہر ٹنل قسم پر ناکام ہو تو واپسی راستے پر کام کریں: کلائنٹ پتہ VM سب نیٹ سے روٹ کے قابل ہونا چاہیے، صارف کا متعین کردہ کوئی بھی راستہ درست اگلے ہاپ کی طرف اشارہ کرے، اور کلائنٹ فائر وال آنے والا بہاؤ قبول کرے۔ NSG اور راستوں کے ثبوت ٹکٹ کے ساتھ منسلک کریں۔

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