FortiGate خلف NAT: local-gw وlocalid وعنوان IP العام

يمكن لجهاز FortiGate خلف NAT أن يمتلك 10.0.0.2 على واجهة WAN الخاصة به بينما يعرضه الإنترنت كـ 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 مستخدم أو معرّف مفتاح. مع 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 النفق يعمل، ويقرر توافق الهوية ما إذا كان النظير سيقبله، ويقرر توجيه البادئة الداخلية ما يعبر فعلًا. لا يمكن لمعرّف محلي صحيح أن يوفر مسارًا ثابتًا ناقصًا أو محدّد حركة ناقصًا.

لذا تحقق طبقةً بطبقة. get vpn ipsec tunnel details يعرض ما إذا كان النفق يعمل وأي المحدّدات تم التفاوض عليها، وعدم التطابق بين الشبكة الفرعية البعيدة المضبوطة والمحدّد المتفاوض عليه مشكلة توجيه ترتدي زي المرحلة 2. execute vpn ike gateway clear يفرض إعادة تفاوض، فتختبر الإعداد الحالي لا جلسة أُنشئت قبل آخر تغيير لك. ثم أرسل حركة إلى مضيف في البادئة البعيدة وتأكد من تحرك العدادات، لأن نفقًا يعمل ولا يمرر شيئًا يبدو مطابقًا لنفق سليم حتى تفحص.

احتفظ بالقيم الثلاث في مكان واحد في ملاحظاتك: العنوان المحلي الذي يملكه الجهاز، ونقطة النهاية العامة التي يعرضها جهاز NAT، وسلسلة الهوية التي يتوقعها النظير. تتغير لأسباب مختلفة وفي أوقات مختلفة.

إعادة ترقيم جهاز NAT ليست سببًا للمس local-gw الخاص بـ FortiGate، وتغيير الهوية ليس سببًا لإعادة ترقيم أي شيء. خلط الاثنين هو كيف يُعاد بناء نفق يعمل أثناء نافذة صيانة غير مرتبطة. دليل إرشادات NAT في Cloud VPN هو المرجع للطوبولوجيا المدعومة على ذلك الجانب.

الاختبار الذي يحسم الأمر ممل وسريع: التقط على الواجهة الخارجية، وتأكد من وصول UDP 500 و4500 من النظير، وتأكد من أن الهوية في تبادل IKE تطابق ما ضُبط النظير لتوقعه، ثم تأكد من أن المحدّدات المتفاوض عليها تغطي الشبكات الفرعية التي تهمك. إذا فشل الفحص الأول فجهاز NAT هو المشتبه به. وإذا فشل الثاني فحقول الهوية هي. وإذا فشل الثالث فلم يكن NAT ولا الهوية هما المشكلة أصلًا.