متصل بـ OpenVPN ولكن لا تُحمَّل أي صفحة: جولة من جهة العميل

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

ابدأ من العميل واتجه إلى الخارج

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

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

التقاطان يظهران أين تتوقف الحزم

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

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

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

ip -4 route get 9.9.9.9

حقل dev في ذلك الإخراج هو الاسم الذي ستحتاجه قاعدة NAT لاحقًا، فاحتفظ به.

التمرير مفتاح في النواة وسياسة في جدار الحماية

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

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

التمرير نصف العمل فقط. على مضيف يستخدم UFW، تُضبط سياسة التمرير في /etc/default/ufw ويجب أن تكون ACCEPT قبل أن يسري أي إعادة تحميل. وسياسة الرفض الافتراضية على مسار التمرير تُبقي المصافحة سليمة تمامًا بينما تتخلص بصمت من كل حزمة تحاول الخروج عبر النفق، وهو بالضبط العَرَض الذي بدأت به.

المضيفون الذين يديرون nftables مباشرة يواجهون السؤال نفسه بصيغة مختلفة. راقب العدادات على سلسلة التمرير أثناء تشغيل اختبار من العميل، لأن السلسلة التي يُرجَع إليها والتي تُسقط الحزم تبدو متطابقة في ملف الإعداد.

سمِّ واجهة الخروج الحقيقية في قاعدة NAT

ترجمة المصدر مكانها الواجهة التي تغادر المضيف فعلًا، مع المجموعة التي يوزعها الخادم. ويجب أن يصف نصفا القاعدة الواقع، ولا أحدهما اختياري.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

الفشل الكلاسيكي هو قاعدة منسوخة من دليل تقول -o eth0 على جهاز يحمل محوله اسمًا آخر. القاعدة تُثبَّت دون تحذير، ولا تطابق شيئًا، ويبقى العميل بلا إنترنت. والمجموعة هي النصف الآخر من الخطأ نفسه: إذا كان الخادم يدفع 10.44.0.0/24 والقاعدة تغطي 10.8.0.0/24، فلن يطابق شيء أبدًا.

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

iptables -t nat -L POSTROUTING -v -n

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

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

DNS هو الفشل الثاني خلف الأول

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

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

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

قد يعود عملاء Windows إلى المحلل المحلي على أي حال، وهذا ما وُجد block-outside-dns لمنعه، على حساب فقدان أسماء لا يستطيع حلها سوى الشبكة المحلية. وعملاء Linux الذين يستخدمون systemd-resolved يتجاهلون غالبًا محللًا مدفوعًا ما لم يثبته سكربت، فتحقق من resolvectl status لجهاز النفق قبل أن تستنتج أن الدفع قد تُجوهل.

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