NAT المزدوج وشبكتك الافتراضية: العميل يعمل والخادم لا

موجّهك يقف خلف موجّه آخر، وعنوان WAN خاص، ومع ذلك يتصل عميل VPN. هذه التركيبة تفاجئ من يتوقعون أن يكسر NAT المزدوج الأنفاق، لكن الاتصالات الصادرة هي ما تتعامل معه الترجمة أفضل من غيره. استضافة خادم VPN خلف الطبقتين نفسيهما هي الحالة التي تفشل عادة. ارسم اتجاه الاتصال قبل أن تغيّر أي شيء.

ارسم اتجاه الاتصال أولاً

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

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

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

الصادر: العميل يسأل والمترجمون يعيّنون

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

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

wg show
ping -c3 10.8.0.1

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

الوارد: إعادة التوجيه لا تغطي إلا المعدات التي تملكها

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

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

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

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

اختبر متغيراً واحداً في كل مرة

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

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

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

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