NAT کے پیچھے FortiGate: local-gw، localid اور عوامی IP

NAT کے پیچھے FortiGate اپنے WAN انٹرفیس پر 10.0.0.2 رکھ سکتا ہے، جبکہ انٹرنیٹ اسے 198.51.100.40 کے طور پر دکھاتا ہے، اور دونوں اعداد حقیقی ہیں۔ وہ پتہ جس سے ڈیوائس بندھتی ہے اور وہ شناخت جو IKE تصدیق کے دوران بھیجتی ہے الگ فیصلے ہیں، الگ فیلڈز میں، الگ سامعین کے لیے کیے گئے۔ NAT راستے میں بیرونی ایڈریسنگ دوبارہ لکھتا ہے؛ تصدیق شدہ شناخت کو دور کے ساتھی کی توقع کے مطابق دوبارہ نہیں لکھتا۔ اس شکل میں زیادہ تر فیز 1 ناکامیاں درست قدر کو غلط فیلڈ میں رکھنے سے آتی ہیں۔

تین قدریں، تین مالک

تین قدروں اور ہر ایک کے مالک کے نام سے شروع کریں۔ local-gw وہ پتہ ہے جو FortiGate اپنے بیرونی انٹرفیس پر IKE کے ماخذ کے طور پر استعمال کرتا ہے، اور یہ ایسا پتہ ہونا چاہیے جو ڈیوائس کے پاس واقعی ہو۔ عوامی اینڈ پوائنٹ NAT ڈیوائس کا پتہ ہے، اور اس کا مالک وہ ہے جو ترجمہ کرتا ہے۔ IKE شناخت ایک سٹرنگ ہے جسے ساتھی اپنی ترتیب سے ملاتا ہے، اور اس کا IP پتہ ہونا بالکل ضروری نہیں۔

فیلڈز کے نام بدلی کی دعوت دینے کے لیے کافی قریب ہیں، اور یہی جال ہے۔ localid اور localid-type شناخت بیان کرتے ہیں؛ local-gw مقامی بندھن بیان کرتا ہے۔

ایک مثال فرق کو واضح کرتی ہے۔ FortiGate پر config vpn ipsec phase1-interface کھولیں، پھر set interface "wan1" اور set local-gw 10.0.0.2 — وہ پتہ جو باکس کے پاس ہے، اور یہی IKE ساکٹ کو کامیابی سے باندھنے دیتا ہے۔ local-gw کو 0.0.0.0 پر چھوڑ دیں تو انٹرفیس کا پتہ استعمال ہوتا ہے، جو عام طور پر وہی چیز ہے مگر کم واضح۔ local-gw کو 198.51.100.40 پر سیٹ نہ کریں، کیونکہ ڈیوائس کے پاس وہ پتہ نہیں اور ساکٹ اس سے نہیں بندھے گا۔ دو قدروں کو کاغذ پر برابر دکھانا ترتیب نہیں ہے۔

مرحلہ 1: وہ شناخت چنیں جو ساتھی قبول کرے گا

اب شناخت، جو ایک مختلف فیصلہ ہے۔ set localid وہ قدر لیتا ہے جس کا ساتھی موازنہ کرے گا، اور set localid-type FortiGate کو بتاتا ہے کہ اس کی تشریح کیسے کرنی ہے: ایک پتہ، ایک FQDN، صارف FQDN یا کلید ID۔ auto کے ساتھ ڈیوائس اسے اخذ کرتی ہے، عام طور پر باہر جانے والے انٹرفیس کے پتے سے، جو عین وہی قدر ہے جو NAT ڈیوائس بدلنے والا ہے۔

یہی اخذ کرنا اس ٹوپولوجی میں واضح شناخت کی اہمیت کی وجہ ہے۔ اگر ساتھی پتہ شناخت کی توقع کرتا ہے، تو localid-type address اور localid کو اس عوامی پتے پر سیٹ کریں جو ساتھی دیکھے گا، پھر تصدیق کریں کہ ساتھی اس قدر کو روٹنگ ہدف کے بجائے شناخت کے طور پر قبول کرتا ہے۔ اگر ساتھی FQDN کی توقع کرتا ہے، تو localid-type fqdn اور وہ نام استعمال کریں جس کے ساتھ یہ ترتیب دیا گیا تھا۔ diagnose vpn ike gateway list سے تصدیق کریں کہ واقعی کیا بھیجا گیا، جو گیٹ وے کی حالت اور زیر استعمال شناخت کنندگان دکھاتا ہے، نہ کہ وہ جو آپ ٹائپ کرنا چاہتے تھے۔ یہ نہ مانیں کہ شناخت کی قسم کا آپشن کوئی بھی غیر مقامی پتہ قبول کرتا ہے؛ پہلے ریلیز کی دستاویزی معنویت دیکھیں۔

مرحلہ 2: UDP 500 اور 4500 کو ڈیوائس کی طرف بھیجیں

تیسری قدر NAT ڈیوائس کی ہے، اور یہی وہ ہے جسے لوگ جانچنا بھول جاتے ہیں۔ عوامی اینڈ پوائنٹ کو UDP 500 اور UDP 4500 FortiGate کی طرف بھیجنا ہوگا، کیونکہ NAT-T کی شناخت اور اس کے بعد آنے والا لفافہ شدہ ESP دونوں ان پورٹس کے آنے پر منحصر ہیں۔ یہ ڈیزائن ایک سے ایک میپنگ فرض کرتا ہے; ایک عوامی پتہ کئی ساتھیوں کے درمیان پورٹ کی بنیاد پر بانٹنا مختلف حدود والی مختلف ٹوپولوجی ہے۔

بھیجنے کی تصدیق کیپچر سے کریں، امید سے نہیں: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 دکھاتا ہے کہ پیکٹ آ رہے ہیں یا نہیں اور جواب جا رہے ہیں یا نہیں۔

Google Cloud VPN NAT کے پیچھے ساتھی کے لیے معاون ترتیب کے طور پر NAT-T کے ساتھ ایک سے ایک NAT کی دستاویز کرتا ہے، اور اگر دور کا سرا Cloud VPN گیٹ وے ہو تو یہی وہ حد ہے جس کے خلاف ڈیزائن کرنا ہے۔ ایک سے کئی یا پورٹ کی بنیاد پر بانٹنا وہی معاون ٹوپولوجی نہیں، اور مقامی شناخت کی کوئی بھی ٹیوننگ اسے نہیں بدلتی۔ اگر دور کا پہلو کوئی اور ڈیوائس ہو، تو اس کی اپنی دستاویزات طے کرتی ہیں کہ وہ شناخت کے طور پر کیا قبول کرے گا اور ترجمہ شدہ ساتھی پتہ برداشت کرے گا یا نہیں۔ مقامی فیلڈ بدلنے سے پہلے اسے پڑھیں، کیونکہ مقامی پہلو اس قاعدے پر بات نہیں کر سکتا جو دور کا پہلو نافذ نہیں کرتا۔

مرحلہ 3: دیکھیں کہ فیز 1 کیا حل نہیں کرتا

NAT ٹریورسل سرنگ کو اوپر اٹھاتا ہے، شناخت کا اتفاق فیصلہ کرتا ہے کہ ساتھی اسے قبول کرے گا یا نہیں، اور اندرونی سابقے کی روٹنگ فیصلہ کرتی ہے کہ واقعی کیا گزرتا ہے۔ درست مقامی ID غائب اسٹیٹک روٹ یا غائب ٹریفک چنندہ فراہم نہیں کر سکتا۔

اسی لیے تہہ در تہہ جانچیں۔ get vpn ipsec tunnel details دکھاتا ہے کہ سرنگ اوپر ہے یا نہیں اور کون سے چنندہ پر بات ہوئی، اور ترتیب شدہ دور کے سب نیٹ اور طے شدہ چنندہ کے درمیان فرق فیز 2 کے لباس میں روٹنگ مسئلہ ہے۔ execute vpn ike gateway clear دوبارہ بات چیت پر مجبور کرتا ہے، اس لیے آپ موجودہ ترتیب جانچ رہے ہیں، آپ کی آخری تبدیلی سے پہلے قائم سیشن نہیں۔ پھر دور کے سابقے میں کسی ہوسٹ پر ٹریفک بھیجیں اور تصدیق کریں کہ کاؤنٹر ہل رہے ہیں، کیونکہ اوپر ہونے مگر کچھ بھی نہ گزارنے والی سرنگ جانچنے تک کام کرنے والی جیسی ہی دکھتی ہے۔

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

NAT ڈیوائس کی دوبارہ نمبرنگ FortiGate کے local-gw کو چھونے کی وجہ نہیں، اور شناخت بدلنا کسی چیز کی دوبارہ نمبرنگ کی وجہ نہیں۔ دونوں کو ملانا ہی وہ طریقہ ہے جس سے کام کرنے والی سرنگ غیر متعلقہ دیکھ بھال کی ونڈو میں دوبارہ بنائی جاتی ہے۔ Cloud VPN NAT رہنمائی اس طرف کی معاون ٹوپولوجی کا حوالہ ہے۔

جو امتحان اسے طے کرتا ہے وہ بورنگ اور تیز ہے: بیرونی انٹرفیس پر کیپچر کریں، تصدیق کریں کہ UDP 500 اور 4500 ساتھی سے آ رہے ہیں، تصدیق کریں کہ IKE تبادلے میں شناخت اس سے میل کھاتی ہے جس کی توقع کے لیے ساتھی ترتیب دیا گیا تھا، پھر تصدیق کریں کہ طے شدہ چنندہ آپ کے لیے اہم سب نیٹ ڈھکتے ہیں۔ اگر پہلی جانچ ناکام ہو، تو مشکوک NAT ڈیوائس ہے۔ اگر دوسری، تو شناخت فیلڈز ہیں۔ اگر تیسری، تو NAT یا شناخت کبھی مسئلہ نہیں تھی۔