NAT المرآة: لماذا يفشل طرف VPN من الداخل

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

الحزمة تخرج وتعود

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

الآن يتلقى العميل حزمة من عنوان لم يرسل إليه شيئاً، فيسقطها. هذا التفاوت هو الخلل كله.

يصف RFC 4787 السلوك المتوقع من NAT في هذه الحالة، والخلاصة القصيرة أن هذا السلوك اختياري عملياً حتى حيث يكون محدداً نظرياً. بعض الموجهات تسمي الإعداد NAT loopback، وبعضها يسميه hairpin NAT أو NAT reflection، وبعضها لا يعرض شيئاً إطلاقاً. الموجه الذي يفتقر إليه ليس مساء التهيئة؛ إنه يفعل الشيء العادي، والإصلاح ينتمي إلى مكان آخر. لا تستنتج من فشل اختبار محلي أن قاعدة التمرير العامة خاطئة.

الفحص 1: اختبر المسارين منفصلين

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

اختبار محلي دقيق يحتفظ باسم المضيف ويستبدل العنوان فقط: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ يرسل الطلب إلى العنوان العام مع تقديم اسم الخادم الصحيح. وهذا يفصل مشكلة تحليل الاسم عن مشكلة الترجمة، وهما سهلتا الالتباس عندما يعمل الاسم نفسه من مقهى. لاحظ هل يفشل العميل عند اتصال TCP أم لاحقاً عند TLS، لأن الأول يشير إلى الترجمة والثاني إلى الهوية.

الفحص 2: اقرأ ما يراه الخادم

أكثر ملاحظة مفيدة هي رؤية الخادم. شغّل التقاطاً على مضيف VPN مصفّى إلى عنوان العميل المحلي وإلى عنوان الموجه المحلي، ثم أعد المحاولة المحلية. إن لم يصل شيء، فالحزمة لم تنجُ من الترجمة.

إن وصل اتصال من عنوان الموجه المحلي بدلاً من عنوان العميل، فإن hairpinning يحدث وقد أعيدت كتابة المصدر. هذه تهيئة تعمل، لا عطل.

الفحص 3: أصلحه دون لمس المسار الخارجي

توجد ثلاثة أشكال مدعومة، بترتيب متزايد من نطاق الأثر. الأضيق هو DNS المنقسم: انشر سجلاً داخلياً بحيث يحل اسم الخادم نفسه إلى العنوان الداخلي للعملاء على الشبكة المحلية، ما يتجنب المسار العام بالكامل. التالي هو تفعيل خيار loopback أو reflection الموثق في الموجه، إن وجد، وتطبيقه على هذه الخدمة فقط. الأوسع هو قاعدة NAT للمصدر على الموجه تعيد كتابة الزيارات القادمة من الشبكة المحلية إلى الخادم ليعود الرد عبر الموجه؛ على موجه Linux تكون قاعدة MASQUERADE في POSTROUTING مطابقة لعنوان الخادم ومنفذه. الأشكال الثلاثة تُبقي المسار الخارجي دون مساس، وهي الخاصية التي يجب الحفاظ عليها.

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

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

الفحص 4: تحقق من المسارين بعد ذلك

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

أبقِ السجل قصيراً: أي عنوان استخدم كل عميل، وما رآه الخادم، وأي الإصلاحات الثلاثة طُبّق. إن متطلبات hairpinning في RFC 4787 هي المرجع لما يُتوقع من NAT هنا، وتشرح لماذا يعمل موجه بلا هذه الميزة بشكل طبيعي. الفشل المحلي الذي لا يستطيع العالم الخارجي إعادة إنتاجه هو سؤال ترجمة حتى يثبت العكس، فاختبره على هذا الأساس.