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

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

ما ثبّته العميل، ولماذا اختفت الشبكة المحلية

ابدأ بقراءة الجدول بدلًا من واجهة العميل. على macOS يطبع netstat -rn الجدول كله، ويسمّي route -n get default الواجهة والمقياس اللذين يفوزان حاليًا؛ وعلى Linux الزوج هو ip route show و ip route get 8.8.8.8. كلاهما يجيب عن سؤال واحد: أي مدخل سيحمل حزمة لا تطابق شيئًا أكثر تحديدًا.

اسم جهاز النفق ليس ثابتًا. ملف IKEv2 على macOS يُظهر عادةً utun متبوعًا برقم، ويُظهر عميل SSL VPN ppp0، ويُظهر OpenVPN tun0. ويمكن أيضًا وجود مسارين افتراضيين في الوقت نفسه بمقياسين مختلفين، وقد لا يستحوذ مدخل العميل إلا بعد إعادة الاتصال بدلًا من لحظة ظهوره. لهذا قد يروي تفريغان للجدول بينهما خمس دقائق قصتين مختلفتين.

لماذا يجب حذف المسار الافتراضي للنفق أولًا

تختار النواة أطول بادئة مطابقة، وعندما تتساوى عدة مسارات في التحديد تختار ذات المقياس الأدنى. لذلك يفوز العميل الذي يثبّت 0.0.0.0/0 بمقياس أفضل بكل وجهة دون حذف المسار الافتراضي الأصلي، ولهذا لا يزال المسار الفيزيائي في الجدول ولا يزال يفسّر الانقطاع. إن حذف المسار الافتراضي للنفق أولًا يعيد السلوك السابق. وعندها فقط يفعل مسار البادئة عبر النفق ما قصده كاتبه.

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

التسلسل على macOS وعلى Linux

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

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

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

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

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

البادئات والمُحلّل ومنطقة DMZ التي تبقى معتمة

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

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

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

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

اقرأ القيمتين قبل تشغيله. peer هو الطرف البعيد لنفق نقطة إلى نقطة، وهو العنوان الذي يحتاجه مسار DMZ؛ وفي نفق موجّه يكون المكافئ هو الواجهة أو البوّابة التي يبلّغ عنها العميل. إن لم يظهر أي منهما، فالعميل ليس في الوضع الذي افترضته.

بعد الاتصال التالي، ومتى تتوقف عن فعل هذا محليًا

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

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

قائمة التحقق قصيرة: اقرأ الجدول، واحذف المسار الافتراضي للنفق، وأعِد المسار الافتراضي للشبكة المحلية، وأضف كل بادئة، وأصلح التحليل بشكل منفصل، وتوقّع عودة المسارات عند إعادة الاتصال.