لماذا لا يقبل خادم VPN خلف CGNAT أي اتصال أبدًا

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

تأكيد العنوان المشترك يستغرق دقيقتين ويمنع أسبوعًا من تغييرات الإعدادات.

العلامات التي تشير إلى NAT الخاص بالمشغّل

قارن عنوان WAN في صفحة حالة الموجّه بالعنوان الذي يُبلّغ عنه استعلام خارجي. عنوان WAN داخل 100.64.0.0/10 هو العلامة المعتادة، والنطاقات الخاصة 10/8 و172.16/12 و192.168/16 تعني الشيء نفسه. إذا أظهر traceroute نفس القفزة العامة مكرّرة، أو أجابت قفزة مبكرة بعنوان خاص، فهناك مترجم آخر بين الموجّه والإنترنت. بعض مزوّدي الخدمة يدرجون العنوان المخصّص في بوابة العملاء فقط، لذا صدّر تلك القيمة مع نتيجة traceroute.

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

لماذا لا تستطيع إعادة التوجيه وDNS الديناميكي إصلاح ذلك

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

إعادة تهيئة العميل لن تساعد أيضًا، لأن الفشل يحدث قبل قراءة أي إعداد في العميل.

التمرير عبر VPS بمسارات صريحة

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

على VPS، أضف إدخال دليل خاصًا بالعميل كي يعرف الخادم أي نظير يملك شبكة المنزل الفرعية، وأضف مسار نواة مطابقًا.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

سطر iroute يخبر OpenVPN أي عميل يستقبل حركة المرور الخاصة بشبكة المنزل الفرعية؛ وسطر route يضع تلك الشبكة الفرعية في جدول نواة VPS كي تدخل الحزم النفق أصلًا. لخدمة منشورة، أضف قاعدة NAT للوجهة تمرّر المنفذ العام إلى 10.8.0.10 وفعّل net.ipv4.ip_forward.

اختبر المسار من الخارج

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

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

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

بدائل تستحق التسعير أولًا

عنوان IPv4 مخصّص من مزوّد الخدمة هو الحل الأقصر وعادةً برسوم شهرية صغيرة. يزيل IPv6 الأصلي الترجمة عند الطرفين عندما يحمله VPN وشبكة العميل وسجلات DNS جميعًا. طبقة شبكية متداخلة مع موجّه شبكة فرعية داخل شبكة المنزل تحقق التمرير نفسه دون VPS، مقابل الاعتماد على خدمة تنسيق.

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