أين ينتمي المسار في OpenVPN: إلى العميل أم إلى الخادم؟
مسار عارٍ في إعداد الخادم يغيّر الخادم لا العميل. اختر ملف العميل أو دفعًا عامًا أو دفعًا لعميل واحد، ثم تحقّق مما وصل.
تُضيف route 10.60.0.0 255.255.255.0 إلى إعداد الخادم، ثم تُعيد التشغيل، وتُعيد توصيل حاسوب محمول، ولا تزال الشبكة الفرعية غير قابلة للوصول من ذلك الحاسوب. لقد قُبِل السطر، وبدأت الخدمة بنظافة، ولا شيء في السجل يبدو خاطئًا. الذي حدث هو أن المسار ثُبِّت على الجهاز الذي حرّرته: البوابة تعتقد الآن أنها تستطيع الوصول إلى تلك البادئة، بينما لم يُخبَر العميل بشيء. الموضع هو السؤال كله، وهناك أربعة أماكن يمكن أن يعيش فيها السطر نفسه.
المواضع الأربعة ومن يستقبل كلًّا منها
يمكن إضافة مسار عبر إعداد العميل نفسه، أو عرضه على كل عميل عبر دفع عام، أو عرضه على عميل واحد عبر ملف خاص بالعميل، أو كتابته في سياق التوجيه الخاص بالخادم.
تستخدم تلك الحالات الأربع صياغة تكاد تكون متطابقة وتُنتج نتائج مختلفة تمامًا. تؤثر الحالات الثلاث الأولى فيما يرسله العميل إلى النفق؛ وتؤثر الرابعة في كيفية وصول الخادم إلى شبكة، وهو مفيد عندما يحتاج الخادم نفسه إلى مسار وضار عندما يُظنّ أنه توزيع.
حدّد أيًّا من الأربعة تريد قبل كتابة السطر، ثم أكّد المستفيد.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
لماذا يُفاجئ المسار الخام في الخادم الناس
إعداد الخادم هو أول ما ينظر إليه المسؤولون، وتوجيه المسار هناك يُقرأ كبيان عن شبكة VPN. وهو ليس كذلك. OpenVPN يعامله كتثبيت مسار محلي على الجهاز الذي يعمل عليه الخفي، وهو بالضبط نوع التغيير الذي قد تجريه باستخدام ip route ثم تنساه.
التوزيع يتطلب دفع المسار، والدفع يتطلب أن يسحب العميل. العميل الذي يبدأ مع تعطيل الخيارات المسحوبة يتجاهل العرض تمامًا. تحقّق من طرفي تلك المصافحة قبل إعادة كتابة ملف الخادم، لأن سجل الخادم لن يشتكي: من جهته أُرسل العرض. كما أن المسار المقبول لا يصل إلا عند الاتصال التالي، ولا يصل أبدًا في الجلسة التي أنت فيها الآن.
بمجرد أن ترى العمليتين منفصلتين، يتوقف الفشل عن أن يكون غامضًا: الخادم يستطيع الوصول إلى البادئة، والعميل لا يستطيع، والقولان صحيحان في الوقت نفسه.
ملفات لكل عميل والهوية التي تطابقها
يُسمّى الملف الخاص بالعميل تبعًا للهوية التي صادق عليها الخادم، وهي افتراضيًا الاسم الشائع في الشهادة. اسم الاتصال الودود في عميل سطح المكتب ليس تلك القيمة، وعدم التطابق يُنتج ملفًا لا يُقرأ أبدًا.
افحص الدليل الذي يستخدمه الخادم فعليًا، ثم أكّد أن اسم الملف يطابق الهوية المصادق عليها تمامًا، بما في ذلك حالة الأحرف.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/داخل ذلك الملف لا يزال المسار بحاجة إلى الدفع، لأن سياق العميل الواحد مجموعة خيارات تُطبّق على جلسة ذلك العميل وليس جدول توجيه محليًا. والمسار الخام هناك له المشكلة نفسها التي للمسار الخام في الملف العام.
ملف العميل نفسه والأداة التي تملكه
المسار الموضوع في إعداد العميل يُثبَّت عندما يتصل ذلك العميل ويُزال عندما ينقطع، وهو دورة الحياة الصحيحة لوجهة ثابتة.
إذا كان مدير الشبكة يملك الملف الشخصي، فقد يستورد تلك الخيارات مرة واحدة ثم يحتفظ بنسخته. تعديل الملف المُنزَّل بعد ذلك لا يغيّر شيئًا، وهذا مصدر شائع لعبارة "المسار موجود لكنه لا يُطبَّق".
افحص الملف الشخصي النشط لا الملف الذي نزّلته، وافحص الإعدادات المستوردة التي يعرضها المدير. ثم اتصل واسأل النظام أي مسار يستخدمه عنوان محدد، بدلًا من افتراض أن النفق فاز لأن المسار كان موجودًا في ملف نصي.
تحقّق على العميل ثم افحص مسار العودة
اسأل جدول التوجيه الخاص بالعميل عن الوجهة، لا جدول الخادم. البحث عن مضيف واحد داخل البادئة يكفي لإظهار الواجهة والخطوة التالية التي ستُستخدم.
ip route get 10.60.0.10إذا أشار البحث إلى النفق فقد نجح التوزيع والمشكلة المتبقية في مكان آخر. وإذا أشار إلى البوابة الافتراضية فالمسار لم يُثبَّت، أو حُجبه خيار على جانب العميل، أو ينتمي إلى ملف شخصي لا يستخدمه العميل.
افترض أن التوزيع نجح وما زال لا شيء يستجيب: فافحص إعادة التوجيه على البوابة، ومسار العودة على الجانب الآخر، وأي جدار ناري بينهما. المسار يختار طريقًا، ولا يمنح وصولًا.