تعطل الوصول إلى شبكة LAN عبر OpenVPN؟ افحص المناطق والمسارات وطريق العودة

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

أي مرشّح يرى حزمة متجهة إلى شبكة LAN

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

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

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

انظر إلى هدف التمرير في المنطقة التي تحمل النفق: القيمة accept هي ما يحتاجه السلّم، وreject تفسّر كل مهلة أدناه. وهناك إعدادان مجاوران ينتجان العَرَض نفسه، فاستبعدهما ما دمت هنا. فالعزل اللاسلكي يخفي المضيفين السلكيين عن العملاء اللاسلكيين، والموجّه الذي يعتبر مضيفي LAN الخاملين غير متصلين قد يُسقط الردود حتى بعد نجاح التمرير.

لماذا يحتاج النفق المنقسم إلى دفع البادئة

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

push "route 192.168.50.0 255.255.255.0"

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

ip route show | grep 192.168.50

نظير موقع إلى موقع يطلب أكثر من دفع. فعلى الخادم أن يعرف البادئات التي تقع خلف ذلك النظير، وهذا ما يفعله سطر iroute في ملف client-config-dir الخاص به، كما يحتاج جدوله هو إلى مسار مطابق داخل النفق.

الرد يحتاج إلى عنوان يستطيع الوصول إليه

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

tcpdump -ni tun0 host 192.168.50.20

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

سلّم ينتهي في المكان الصحيح

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

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

الأسماء تنتمي إلى نهاية السلّم، لا إلى بدايته. فمشاركة تستجيب كـ 192.168.50.20 وليس كـ nas.local تشير إلى الترجمة أو إلى لاحقة بحث، وتعديلات جدار الحماية لا تغيّر أيًّا منهما.

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