نفق VPN لا يتصل أبدًا: أين تتوقف الحزم فعليًا

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

أثبت أين يتوقف المرور

التقط على واجهة الخروج لدى العميل وعلى الخادم في اللحظة نفسها. قارن ما غادر بما وصل، ولاحظ في أي اتجاه يظهر الفرق.

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

PPTP يموت دون البروتوكول 47

يحمل PPTP التحكم على TCP 1723 وبياناته داخل GRE، وهو البروتوكول 47 في IP وليس رقم منفذ. إعادة توجيه 1723 وحدها تنتج النتيجة الكلاسيكية: يتصادق الاتصال ثم يصمت، لأنه لا توجد قاعدة للبروتوكول الذي يحمل الحمولة. لا يستطيع العميل تمييز ذلك من كلمة مرور مرفوضة، ولهذا يجب أن يأتي الالتقاط قبل تعديلات الإعداد.

يعمل التمرير في الاتجاه المعاكس لإعادة التوجيه الواردة، وكثيرًا ما تستخدم البرمجيات الثابتة تسمية واحدة للاثنين بما يكفي لإرباك الجميع. على عميل Linux يمكن لجدار الحماية المحلي إسقاط GRE قبل أن يكون الموجّه معنيًا، لذا يحتاج البروتوكول 47 إلى قاعدته الخاصة ويجب تحميل مساعد conntrack. يحتفظ ufw في Ubuntu بهذه القواعد في ملف before، لأن قواعد السماح العادية لا تستطيع التعبير عن رقم بروتوكول. أعد تحميل جدار الحماية بعد ذلك بدلًا من إعادة تشغيل الجهاز.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP وIPsec خلف NAT مزدوج

L2TP داخل IPsec يحتاج UDP 500 لتبادل المفاتيح، وUDP 4500 عند اكتشاف NAT، وESP كالبروتوكول 50. كل منها يرشح بشكل مستقل، فالقاعدة التي تسمح بواحد لا تثبت شيئًا عن الآخرين. راوتران على التوالي يترجمان كل حزمة مرتين، ولم يعد الطرفان يتفقان على ما تم التفاوض عليه.

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

شبكات المشغل ومشاركة العناوين

عنوان WAN ضمن 10.0.0.0/8 أو 172.16.0.0/12 أو 192.168.0.0/16 أو 100.64.0.0/10 يعني أن الموجّه لا يملك عنوانًا عامًا، ولا يمكن لأي إعادة توجيه واردة من الإنترنت الوصول إليه. كما يرشح NAT من فئة المشغل البروتوكولات التي لا يتوقعها، وGRE ضحية متكررة على وصلات الجوال. قارن عنوان WAN على الموجّه نفسه، لا العنوان الذي يذكره موقع بحث لعنوان عميل خلفه.

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

اقرأ قائمة المستمعين قبل إغلاق المنافذ

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

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

إعدادات SoftEther الافتراضية مثال جيد: TCP 443 و992 و5555، مع ميزتي L2TP/IPsec ونفق DNS التي تضيف مقابسها الخاصة. إيقاف تلك الميزات يزيل المستمعين بدلًا من إخفائهم، والفحص من مضيف خارجي يخبرك ما إذا كان المشغل يسمح بمرور المنفذ أصلًا. المستمع الذي يستجيب محليًا قد يظل مغلقًا في المنبع، لذا قارن عنوان WAN الخاص بالموجّه بما يذكره خدمة خارجية.