عميل OpenVPN يصل إلى الخادم لكن ليس إلى مضيفي الشبكة المحلية: قائمة تحقق

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

الخطوة الأولى: راقب قرار التوجيه لدى العميل

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

ip route get 192.168.50.10

إذا ذكر الجواب محولك الفيزيائي وبوابة المكتب، فلا يمكن لأي تغيير على جانب الخادم أن يساعد. OpenVPN لا يمنح المسارات إلا عندما يدفعها الخادم، لذا ابحث عن push "route 192.168.50.0 255.255.255.0" في إعدادات الخادم، ثم أعد توصيل العميل بعد ذلك. معظم العملاء يطبّقون المسارات المدفوعة وقت الاتصال، لا عند إعادة تحميل الملف الشخصي.

على Windows للسؤال نفسه أمر مختلف. Find-NetRoute -RemoteIPAddress 192.168.50.10 يطبع الواجهة والقفزة التالية التي تختارها الحزمة، و route print -4 يبيّن ما إذا كانت البادئة المدفوعة موجودة أصلًا.

الخطوة الثانية: تأكيد أن الخادم سيمرّر الحزمة

إذا كان مسار العميل صحيحًا، تصل الحزمة إلى الخادم، وعلى الخادم أن يوافق على تمريرها. مفتاح النواة هو البوابة الأولى، وعلى sysctl net.ipv4.ip_forward أن يعيد 1. ضبطه بـ echo 1 > /proc/sys/net/ipv4/ip_forward يعمل حتى إعادة التشغيل التالية، وهذا بالضبط سبب عودة الشكوى نفسها بعد أسابيع.

اكتبه في مكان يبقى بعد إعادة التشغيل:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

البوابة الثانية هي جدول التصفية. المضيف الذي عليه Docker غالبًا يحمل سياسة FORWARD تساوي DROP، والنفق يرث ذلك القرار. iptables -L FORWARD -v -n يُظهر السياسة وعدادات الحزم معًا؛ إذا كانت السياسة DROP، فالمسار إلى الشبكة المحلية يحتاج قبولًا صريحًا واحدًا لاتجاه النفق نحو الشبكة وآخر للرد.

الخطوة الثالثة: تابع الحزمة إلى الشبكة المحلية وابحث عن الرد

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

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

الطلبات التي تظهر على tun0 ثم مرة أخرى على eth0 بمصدر 10.8.0.x، يتبعها صمت، تعني أن الحزمة وصلت وأن الرد ذهب إلى مكان آخر. مضيف الشبكة المحلية يرد على بوابته الافتراضية، وتلك البوابة ليس لديها مسار لتجمّع VPN، فيموت الرد على موجّه الشبكة المحلية. عمل ping لمضيف الشبكة المحلية من الخادم لا يثبت شيئًا عن هذا المسار، لأن تلك الحركة لا تعبر النفق أبدًا.

الخطوة الرابعة: الاختيار بين الترجمة ومسار عودة

إصلاحان يسدان الثغرة، والاختيار له عواقب تتجاوز ما إذا كان ping يعمل. ترجمة المصدر تجعل الخادم هو المرسل الظاهري:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

اقصر القاعدة على التجمّع وواجهة الشبكة المحلية، ثم اجعلها دائمة، وإلا فإن إعادة تحميل الجدار الناري التالية تزيل إصلاحك بهدوء. التكلفة هي الهوية: كل عميل يبدو كخادم VPN في سجلات الشبكة المحلية وقواعد الوصول، و per-client policy becomes guesswork.

مسار ثابت لـ 10.8.0.0/24 على موجّه الشبكة المحلية، يشير إلى خادم VPN، يُبقي عناوين العملاء مرئية وهو الجواب الأفضل على المدى الطويل عندما يكون ذلك الموجّه ملكك. كثير من المواقع تشغّل الاثنين لفترة، NAT للإصلاح الفوري والمسار بمجرد كتابة سياسة الجدار الناري. إذا كان الخادم نظيرًا من موقع إلى موقع بدلًا من تجمّع، فجانب الخادم يحتاج أيضًا إلى iroute للشبكة الفرعية البعيدة، وإلا وُجد مسار النظير لكن حركة العملاء لا ترتبط به أبدًا.

الخطوة الخامسة: التحقق من العميل وتسجيل ما تغيّر

أغلق الحلقة من العميل، لا من الخادم. اتصل بخدمة حقيقية على مضيف الشبكة المحلية، ثم أكّد أن عدادات الترجمة تحركت باستخدام iptables -t nat -L POSTROUTING -v -n، لأن قاعدة بصفر حزم هي قاعدة لم تطابق أبدًا. conntrack -L -s 10.8.0.5 يُظهر التدفق وحالته عندما تحتاج دليلًا على أن اتجاه العودة متتبَّع.

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