OpenVPN يتصل دون أن يمرّ شيء: ابحث عن طبقة إسقاط الحزم

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

المقبس إما مرتبط أو غير مرتبط

الخدمة التي تُبلّغ عن كونها نشطة قد تظل مرتبطة بعنوان أو نقل لم تقصده أبدًا. استعلم عن المقبس نفسه: ss -lunp يسرد مستمعي UDP، ويسرد ss -ltnp مستمعي TCP، والعمود الجدير بالقراءة هو العنوان المحلي، لا الحالة.

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

ss -lunp | grep 1194
ss -ltnp | grep 1194

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

التقط الحزمة الخارجية، لا النفق

رشّح على الواجهة الفيزيائية والمنفذ الحقيقي، مع استبدال واجهتك: tcpdump -ni eth0 udp port 1194. الحزم الصادرة التي لا يعود منها شيء تشير إلى ما هو أعلى في المسار: تصفية المزوّد، أو جهاز NAT، أو عنوان بعيد ليس العنوان الذي تظنه. الصمت في الاتجاهين يشير إلى توجيه العميل أو جدار حماية محلي. الردود التي تصل دون تقدّم في النفق تشير إلى قناة التحكم، أي عدم تطابق في المفتاح أو التشفير، لا إلى التصفية.

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

العدادات أولًا، والتتبع فقط عندما تكذب

ابدأ بالعدادات، لأنها لا تكلف شيئًا. إما nft list ruleset أو iptables -L -n -v يجيب عن السؤال الوحيد المهم هنا: هل طابقت القاعدة؟ الترتيب يحدد النتيجة، لأن أول تطابق يفوز، ولهذا يترك DROP واسع قبل ACCEPT لاحق ذلك ACCEPT ميتًا، ولهذا نادرًا ما تصلح إضافة قاعدة أي شيء.

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

فقط عندما تبقى العدادات غامضة يستحق السجل الضجيج، وحتى ذلك الحين لشريحة ضيقة فقط: قاعدة iptables تحدّد المعدل وتضيف بادئة لأسطر سجلها، أو قاعدة nftables تحمل meta nftrace set 1 مع تشغيل nft monitor trace. التتبع يسمّي السلسلة والقاعدة التي قبلت الحزمة أو أسقطتها. أزل كليهما بعد ذلك وأبقِ تسجيل الحمولة خارج الأمر.

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

التوجيه وطريق العودة

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

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

ما يجب أن يذكره السجل

لكل تغيير، دوّن المرحلة التي اختبرتها والأدلة التي قرأتها وقيمة العداد على جانبيها. تلك الملاحظة هي ما يجعل "إنه يعمل الآن" قابلة للبقاء في المراجعة التالية.

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