عميل VPN على خادم في الشبكة المحلية: لماذا تخرج الردود في الاتجاه الخطأ

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

الرد حزمة جديدة وليس عكسًا للمسار

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

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

أبقِ شبكتين فرعيتين في ذهنك أثناء قراءة البقية. الأولى مجموعة عناوين VPN التي يأتي منها العملاء البعيدون، في هذا المثال 10.64.0.0/24. الثانية الشبكة المحلية التي يجب أن تبقى عاملة، 172.16.24.0/24 مع موجّهها على 172.16.24.1. الخلل أن الحركة بينهما يحددها المسار الافتراضي.

أثبت ذلك بالالتقاط والبحث

قبل تغيير أي شيء، تحقّق من الجهاز الذي ستستخدمه الاستجابة. البحث أسرع من الالتقاط ويجيب عن السؤال نفسه الذي ستجيب عنه النواة عند بناء الحزمة.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

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

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

ثبّت أضيق مسار يتجاوز النفق

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

استخدم replace بدلًا من add، لأن العميل الذي يعيد الاتصال سيكون قد ثبّت مدخله الخاص، ويفشل add الثاني بخطأ «المسار موجود» يبدو كأنه مشكلة أذونات. على مضيف Windows المكافئ هو route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p، حيث يحفظ -p المدخل بعد إعادة التشغيل، إذ قد يعيد العميل بناء الجدول عند عودة النفق. على مضيف Windows حديث المكافئ المدعوم هو New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore، مع الاحتفاظ بأمر route الأقدم كصيغة قديمة.

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

احتفظ بالرد بعد إعادة الاتصال

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

قد يُفشل جدار حماية يحتفظ بالحالة مسارًا صحيحًا. إذا أظهر الالتقاط الآن أن الرد يخرج عبر eth0 ومع ذلك انتهت مهلة العميل، فتحقّق هل يُسقِط المضيف الحزمة قبل إرسالها. التصفية الصارمة للمسار العكسي مع net.ipv4.conf.all.rp_filter مضبوطًا على 1 تُسقِط الحزم التي لا يُوجَّه مصدرها عائدًا عبر الواجهة التي وصلت منها، وهذا بالضبط الحالة غير المتماثلة التي أنشأتها ثم أصلحتها، وحالة Conntrack تحكي القصة نفسها للمنافذ المعاد توجيهها.

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