Azure کا IP فلو تصدیق کہتا ہے اجازت ہے، مگر VPN پھر بھی ناکام ہوتا ہے

سائٹ ٹو سائٹ ٹنل منسلک ہے، VM صحت مند ہے، مگر آن پریمائز کلائنٹ کو کچھ نہیں ملتا۔ آپ Network Watcher کھولتے ہیں، IP فلو تصدیق چلاتے ہیں، اور وہ کہتی ہے Access allowed، چنانچہ ٹکٹ VPN مسئلے کے طور پر بند ہو جاتا ہے۔ یہ نتیجہ وہ معنی نہیں دیتا جو دکھتا ہے، کیونکہ IP فلو تصدیق آپ کے بیان کردہ فلو کے سیکیورٹی قواعد کا جائزہ لیتی ہے اور کبھی یہ نہیں جانچتی کہ Azure کے پاس آپ کے آن پریمائز پریفکس تک کوئی روٹ ہے یا نہیں۔

فلٹرنگ کا سوال اور روٹنگ کا سوال الگ ہیں، اور Network Watcher ان کا جواب مختلف اوزاروں سے دیتا ہے۔ یہ جاننا کہ آپ نے کون سا پوچھا، تشخیص کا بڑا حصہ ہے۔

IP فلو تصدیق دراصل کیا طے کرتی ہے

IP فلو تصدیق ایک VM، نیٹ ورک انٹرفیس، سمت، پانچ گنا اقدار اور پروٹوکول لیتی ہے، پھر اس فلو کے لیے NSG اور سیکیورٹی ایڈمنسٹریٹر قاعدے کا فیصلہ بتاتی ہے۔ یہ TCP اور UDP پر کام کرتی ہے، اس لیے یہ ICMP قاعدے کی جانچنے والی نہیں ہے اور بلاک شدہ ping آپ کی سروس کے بارے میں کچھ ثابت نہیں کرتا۔ اسے اندازے کی بجائے اصل فلو دیں۔ آن پریمائز سے ڈیٹا بیس پورٹ تک آنے والا اندرونی کنکشن، VM کے شروع کردہ بیرونی کنکشن سے مختلف وضاحت ہے۔

اگر گیٹ وے پتے تبدیل کرتا ہے، تو وہ ماخذ پتہ استعمال کریں جو آپ کی جانچی ہوئی حد تک پہنچتا ہے، کلائنٹ کنفگ والا نہیں۔ نتیجہ بھی جیسا ہے ویسا پڑھیں۔ Access allowed کا مطلب ہے کہ فلٹر پرت پیکٹ آنے پر اجازت دیتی، اور اس سے زیادہ کچھ نہیں۔

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

اگلا ہاپ اور مؤثر روٹس کیا اضافہ کرتے ہیں

اگلا ہاپ فارورڈنگ کے سوال کا جواب دیتا ہے: اس منزل کے لیے Azure کون سی اگلی ہاپ قسم چنتا ہے، کس پتے پر، کس روٹ جدول سے۔ مؤثر روٹس وہ فہرست کرتے ہیں جو NIC کے پاس واقعی ہے۔ دونوں چلائیں اور آپ کو Azure طرف کا وہ راستہ ملے گا جو سبز IP فلو تصدیق خالی چھوڑ دیتی ہے۔

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

کمانڈز شیل سے چلانے کے لیے کافی مختصر ہیں۔ az network nic show-effective-route-table انٹرفیس پر لاگو روٹس کی فہرست دیتا ہے۔ az network watcher show-next-hop ماخذ اور منزل کے ساتھ منتخب ہاپ واپس دیتا ہے۔ اپنے لیے اہم پریفکس کا اس جدول سے موازنہ کریں، پھر تصدیق کریں کہ کون سا اندراج جیتتا ہے۔

VM کے NIC سے واپسی کا راستہ چلیں

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

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

مثال کاپی کرنے کی بجائے اگلی ہاپ کی قسم پڑھیں

منظم VPN گیٹ وے کا راستہ عام طور پر اگلی ہاپ قسم کے طور پر VirtualNetworkGateway دکھاتا ہے۔ VirtualAppliance مختلف فارورڈنگ ڈیزائن بیان کرتا ہے، عام طور پر فائر وال یا نیٹ ورک ورچوئل آلات۔

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

اس حد پر جائیں جو اب بھی ناکام ہو رہی ہے

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

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