متصل بـ OpenVPN ولكن لا يوجد ping أو مشاركة SMB؟ افحص ثلاثة أبواب

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

يفشل كل باب بعرض مختلف، وأول باب فقط يقع على خادم VPN.

إعادة التوجيه سياسة على سلسلة FORWARD

قبول مستمع OpenVPN يحدث على INPUT، ولهذا يمكن للنفق أن يتصل بينما تُسقط كل حزمة موجهة إلى الشبكة المحلية. حركة المرور التي تصل على tun0 وتخرج من واجهة الشبكة المحلية تعبر FORWARD، والمضيف الذي توجد فيه سياسة DROP افتراضية يتجاهلها بصمت. افحص كلًا من sysctl والسلسلة قبل أن تلمس أي شيء آخر: sysctl net.ipv4.ip_forward و iptables -L FORWARD -v -n.

اسمح بالاتجاه الذي تريده والردود التي تنتمي إليه، مثل قاعدة accept من واجهة النفق إلى واجهة الشبكة المحلية مع قاعدة stateful للمرور القائم والمرتبط. إذا كانت الشبكة المحلية خلف راوتر آخر، فإن ذلك الراوتر يحتاج إلى مسار عودة إلى مجموعة العملاء أو source NAT على خادم VPN. أكد هذا المسار بـ ping واحد قبل إضافة مزيد من القواعد، لأن القاعدة التي لا يمكن الوصول إليها لا تظهر أبدًا في عدّاد.

SMB يحتاج أكثر من منفذ واحد

مشاركة الملفات ليست محادثة TCP 445 واحدة. يستخدم الاكتشاف UDP 137 و 138، وتستخدم جلسات NetBIOS الأقدم TCP 139، وتستخدم جلسات SMB الحديثة TCP 445. القاعدة التي تفتح 445 فقط تنتج الحالة المجنونة التي يعمل فيها القرص المعيّن ولا يعمل تصفح الشبكة، أو العكس.

النقل الكبير عبر النفق يصطدم أيضًا بمشاكل MSS التي تشبه المشاركة المعطلة. حزمة SYN التي تعلن حجم مقطع الشبكة المحلية الكامل تُسقطها MTU الأصغر للنفق، وتتعلق الاتصال بعد المصافحة. تقييد MSS على مسار إعادة التوجيه، iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu، يزيل هذا النوع من التوقف. تحقق بنسخ عدة ميغابايت بدلًا من قائمة مجلد، لأن الردود الصغيرة تمر حتى عندما لا تمر عمليات النقل الكبيرة.

محول النفق يصل كملف تعريف شبكة جديد

يصنف Windows كل محول في ملف تعريف شبكة، وعادة ما يقع محول النفق الجديد في Public، حيث تُحظر قواعد مشاركة الملفات والطابعات. هذا قرار جدار حماية للمضيف على خادم الملفات، وليس مشكلة توجيه على خادم VPN. غيّر الفئة عن قصد باستخدام Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private بعد التأكد من أن السياسة تسمح بذلك، لأن الفئة تغيّر أيضًا أي قواعد واردة تُطبق.

الملف التعريفي نفسه يفسر فشل ping بينما ينجح TCP 445: تُسقط طلبات الصدى في Public افتراضيًا.

الأسماء لا تعبر نفقًا موجّهًا من تلقاء نفسها

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

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

اختبر طبقة واحدة في كل مرة واقرأ أول فشل

اعمل صعودًا: ping بوابة النفق، ثم ping مضيف على الشبكة المحلية بالعنوان، ثم افتح منفذ الخدمة باستخدام Test-NetConnection -ComputerName 10.8.0.5 -Port 445، وبعد ذلك فقط صادق على المشاركة. أول خطوة تفشل هي الطبقة التي يجب إصلاحها، وكل خطوة لاحقة ضجيج حتى تنجح. ping يرد بينما يبقى المنفذ مغلقًا يشير إلى جدار حماية خادم الملفات نفسه، والمنفذ الذي يفتح رغم صمت ping يشير إلى تصفية ICMP. اكتب أول خطوة فاشلة قبل تغيير أي شيء، لأن التغيير الثاني يخفي نتيجة الأول.

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

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