تعذّر تشغيل AWS Client VPN على Linux؟ طابِق بيئة التشغيل

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

الخطأ يسمّي مكتبة، لا الشبكة

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

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

كلاهما ينتهي بنافذة تُغلق، ولهذا يجري الخلط بينهما في تقارير الأعطال.

مفاتيح العولمة مشكلة مختلفة

الأخطاء التي تذكر ICU أو العولمة تأتي من بيئة تشغيل .NET الكامنة تحت بعض إصدارات العميل، لا من حزمة TLS. إن ضبط مفتاح العولمة الثابتة يغيّر طريقة تعامل تلك البيئة مع بيانات الثقافة، ولا يوفّر libssl مفقودة. وتطبيقه لإسكات خطأ TLS يتركك بعميل يبدأ ثم يفشل في مكان آخر.

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

إذا كان المضيف عاجزًا فعلًا عن توفير بيئة التشغيل المطلوبة، فالجواب المدعوم هو مضيف مختلف، لا مضيف معدَّل.

لماذا يرتدّ استيراد OpenSSL قديمة

نسخ libssl وlibcrypto من توزيعة أقدم إلى /usr/lib ينجح غالبًا بما يكفي ليكون مغريًا. وهو أيضًا يضع مكتبة خارج سيطرة مدير الحزم، فكل تحديث أمني لاحق إما يفوّتها أو يتعارض معها. وعلى مضيف يشغّل أيضًا متصفحًا أو عميل SSH، تكون قد غيّرت حزمة التشفير لبرامج لم تطلب ذلك قط.

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

الحل القديم في منتدى ما هو لقطة لحزمة إصدارين، وليس ضمانًا للتوافق.

احتفظ بتعريف خدمة المورّد

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

إذا احتجت إلى تغيير، فاستخدم drop-in بدلًا من ذلك: ملف تجاوز صغير في دليل .d الخاص بالوحدة يضيف توجيهًا واحدًا أو يستبدله، مع تعليق يوضح سبب وجوده وكيفية التراجع عنه. فتبقى ملفات المورّد سليمة، ولا يلغي تحديث الحزمة التالي عملك بصمت ولا يكرّره.

اكتب مسار التجاوز في ملاحظاتك، لأن المدير التالي سينظر هناك أولًا.

أثبت التشغيل قبل تنقيح المسارات

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

لا تُرفق أبدًا مفتاحًا خاصًا أو ملفًا شخصيًا كاملًا يحوي بيانات اعتماد مضمّنة كمادة تشخيصية.

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