عندما يستحق NAT مكانه داخل شبكة VPN من موقع إلى موقع

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

حدّد أي عنوان يُعاد كتابته

تغيّر ترجمة المصدر ما تراه الخدمة البعيدة وسجلاتها كعميل، فيصبح مضيف الفرع عنوان بوابة عند الوصول. أما ترجمة الوجهة أو البادئة فتعرض عنوانًا بديلًا لمورد بعيد بدلًا من ذلك. تحتاج بعض عمليات النشر إلى ترجمة منسّقة على الجانبين لفصل شبكتين متطابقتين، والتركيب هو حيث يبدأ معظم الالتباس.

اكتب المصدر قبل الترجمة، والوجهة كما تسميها التطبيقة، وزوج العناوين الذي يطابقه كل بوابة. ثلاثة أعمدة تكفي، والعمود الثالث هو الذي يتركه الناس.

ترتيب المحدّدات مهم أيضًا. يحدث اختيار سياسة IPsec وترجمتها في مراحل محددة، لذا محدّد مكتوب لعناوين ما قبل الترجمة قد لا يطابق الحزمة أبدًا في المرحلة التي افترضتها. افحص السياسة المثبّتة بدل السياسة التي كنت تنوي تثبيتها، لأن الاثنتين تختلفان تمامًا عندما تقبل قاعدة مكوّن واحد ويتجاهلها آخر:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

اتبع الحمولة ومسار العودة

السجل الذي يسجّل المصدر المترجم بدل مضيف الفرع الفردي سيكسر أي قاعدة أو تقرير مربوط بالعنوان الأصلي. قبل تغيير التعيين، اكتشف ما إذا كان أي شيء في المصب يتخذ قرارًا من ذلك الحقل: قوائم الوصول، تقارير التدقيق، حدود المعدل، فحوص الترخيص. كل واحد منها موضع تظهر فيه الترجمة لاحقًا كفشل غير مفسّر.

تحتاج البروتوكولات التي تحمل عناوين داخل حمولتها إلى تخطيط منفصل، لأن إعادة كتابة الترويسة الخارجية لا تمس المرجع الداخلي. FTP النشط وSIP وبعض منتجات الوصول البعيد هي الحالات الكلاسيكية، والتصميم الذي يتجاهلها سيعمل لحركة الويب ويفشل للتطبيق الذي كان مهمًا.

تعتمد حركة العودة على تعيينات ذات حالة. قد يفقد تجاوز فشل البوابة تلك الحالة، وقد يتجاوزها التوجيه غير المتماثل، وقد يمسحها إعادة التشغيل بينما تبقى الجلسات مفتوحة على الطرف البعيد. لهذا فإن الطلب الذي يصل إلى الوجهة والجلسة التي تكتمل نتيجتا قبول مختلفتان.

وازن ذلك مقابل إعادة ترقيم موقع

إزالة التعيين كليًا بإعادة ترقيم أحد الموقعين المتعارضين تترك خطة عناوين يمكن قراءتها دون جداول ترجمة. وهي مكلفة تشغيليًا: سجلات DNS والتعيينات الثابتة وقواعد الجدار الناري وكل عنوان موثّق يجب أن تتغير معًا. تتحقق الكلفة مرة واحدة، في نافذة مخططة، بحالة نهائية واضحة. ما تشتريه هو القدرة على قراءة التقاط حزم بعد سنوات دون جدول بحث.

تتجنب الترجمة معظم التغييرات المحلية وتنشئ تعيينًا يجب صيانته في DNS والتوثيق واستكشاف الأخطاء إلى الأبد. تتحقق الكلفة باستمرار، في شكل كل مهندس مستقبلي عليه أن يتعلم أن بادئة واحدة تعني شيئًا آخر داخل النفق.

لاتصال مؤقت أو شبكة شريك لا تتحكم بها، تستحق الكلفة المستمرة الدفع عادةً. أما الموقعان اللذان تملكهما وستملكهما لسنوات، فإعادة الترقيم غالبًا القرار الأرخص عندما تُحسب الهجرة بصدق.

أثبت الاتجاهين بجلسة حقيقية

اختبر جلسة تطبيق بدل مسبار واحد. طلب صدى ناجح يثبت أن اتجاهًا واحدًا لبروتوكول واحد يعمل، وهو متوافق تمامًا مع مسار عودة يفشل مع أي شيء ذي حالة. استخدم الخدمة التي دفعت إلى التصميم، واقرأ سجلها في الطرف البعيد لترى أي عنوان مصدر سجّلته.

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

ثم أكّد أن الخدمات المقصودة فقط يمكن الوصول إليها عبر التعيين. الترجمة تغيّر العنونة ولا تفعل شيئًا للتصريح، لذا تظل سياسة الجدار الناري تقرر ما المسموح. التصميم الذي يعتمد على بادئة مترجمة غامضة كضابط وصول له لا يملك أي ضابط وصول على الإطلاق.

سجّل التعيين والجلسة المختبَرة والعناوين التي رصدها كل جانب. الشخص التالي الذي سيصلح هذا النفق يحتاج تلك الحقائق الثلاث أكثر من حاجته إلى ملف الإعداد.