بسته AWS Client VPN را روی اوبونتو نصب کردید، اجرا کردید و پیش از خوانده شدن هر پروفایلی، خطای بارگذار درباره یک کتابخانه مشترک گم‌شده گرفتید. غریزه اول این است که آن کتابخانه را از نسخه‌ای قدیمی‌تر بردارید و ادامه دهید. این کار معمولاً یک وابستگی خراب را با سیستمی عوض می‌کند که دیگر با پایگاه داده بسته‌های خودش هم‌خوان نیست. خطای راه‌اندازی مسئله مرز پشتیبانی است، نه شبکه.

خطا نام یک کتابخانه را می‌برد، نه شبکه را

کلاینت دسکتاپ VPN باید محیط اجرای خود را بارگذاری کند پیش از آنکه بتواند به پروفایل یا نقطه پایانی شما نگاه کند. وقتی بارگذار پویا نمی‌تواند یک نماد را حل کند، فرایند در همان ثانیه اول می‌میرد و پنجره هرگز ظاهر نمی‌شود. هیچ اندازه‌ای از ویرایش پروفایل، کار DNS یا تغییر مسیرها به آن مرحله نمی‌رسد. پیام را تحت‌اللفظی بخوانید، چون دقیقاً می‌گوید بارگذار کدام شیء را می‌خواست.

به همین ترتیب دو خانواده خطا را از هم جدا می‌کنید. شیء مشترک گم‌شده یک مشکل بسته‌بندی روی میزبان شماست، در حالی که رد احراز هویت تصمیمی از سمت سرویس است که بسیار دیرتر در توالی می‌رسد.

هر دو با پنجره‌ای که بسته می‌شود پایان می‌یابند، به همین دلیل در گزارش‌های باگ با هم اشتباه گرفته می‌شوند.

سوئیچ‌های جهانی‌سازی مسئله دیگری‌اند

خطاهایی که ICU یا جهانی‌سازی را ذکر می‌کنند از محیط اجرای .NET زیر برخی بیلدهای کلاینت می‌آیند، نه از پشته TLS. تنظیم سوئیچ جهانی‌سازی ناوارد تغییر می‌دهد که آن محیط چگونه داده‌های فرهنگ را مدیریت می‌کند و libssl گم‌شده را تأمین نمی‌کند. اعمال آن برای خاموش کردن یک خطای TLS شما را با کلاینتی رها می‌کند که شروع می‌شود و بعد جای دیگری شکست می‌خورد.

این دو را در جعبه‌های جدا نگه دارید: یکی رفتار محیط اجرا را تغییر می‌دهد، دیگری پیونددهنده را راضی می‌کند. دست بردن به اولی وقتی دومی را دارید عادتی است که ارزش کنار گذاشتن دارد.

اگر میزبان واقعاً نمی‌تواند محیط اجرای لازم را فراهم کند، پاسخ پشتیبانی‌شده میزبان دیگری است، نه میزبانی تغییریافته.

چرا وارد کردن OpenSSL قدیمی نتیجه معکوس می‌دهد

کپی کردن libssl و libcrypto از توزیعی قدیمی‌تر به /usr/lib به‌قدری زیاد کار می‌کند که وسوسه‌کننده باشد. همچنین کتابخانه‌ای را بیرون از کنترل مدیر بسته قرار می‌دهد، پس هر به‌روزرسانی امنیتی بعدی یا آن را از دست می‌دهد یا با آن برخورد می‌کند. روی میزبانی که مرورگر یا کلاینت SSH هم اجرا می‌کند، پشته رمزنگاری را برای برنامه‌هایی تغییر داده‌اید که هرگز چنین چیزی نخواسته‌اند.

مسیر پشتیبانی‌شده همان منبع بسته مستند و حل وابستگی‌های آن برای دقیقاً نسخه سیستم‌عامل و معماری شماست. الزامات کلاینت AWS برای لینوکس و یادداشت‌های انتشار نسخه‌ای را که نصب می‌کنید بررسی کنید، چون ماتریس پشتیبانی میان نسخه‌ها جابه‌جا می‌شود.

راه‌حل قدیمی یک انجمن، تصویری از یک جفت نسخه است، نه تضمین سازگاری.

تعریف سرویس فروشنده را نگه دارید

برخی راهنماها یک یونیت مینیمال systemd به شما می‌دهند تا یونیت بسته‌بندی‌شده را جایگزین کند. آن یونیت معمولاً آرگومان‌ها، تنظیمات سخت‌سازی و یکپارچگی‌ای را که فروشنده بعداً افزوده کنار می‌گذارد، و خطای حاصل جایی ظاهر می‌شود که آن را به ویرایش مرتبط نخواهید کرد.

اگر تغییری لازم دارید، به‌جای آن از drop-in استفاده کنید: یک فایل بازنویسی کوچک در پوشه .d یونیت که یک دستور را اضافه یا جایگزین می‌کند، همراه با توضیحی که می‌گوید چرا وجود دارد و چگونه برگردانده می‌شود. فایل فروشنده دست‌نخورده می‌ماند و به‌روزرسانی بعدی بسته نه کار شما را بی‌صدا باطل می‌کند و نه آن را تکراری.

مسیر بازنویسی را در یادداشت‌هایتان بنویسید، چون مدیر بعدی اول همان‌جا را نگاه می‌کند.

پیش از اشکال‌زدایی مسیرها، راه‌اندازی را اثبات کنید

کاری کنید کلاینت با پروفایل تأییدشده به‌طور قابل‌اعتماد بالا بیاید، سپس وارد شوید، سپس تونل را تأیید کنید، و تنها پس از آن به مسیرها، DNS و منابع خصوصی نگاه کنید. هر مرحله شاهد خودش را تولید می‌کند و درهم آمیختن آن‌ها باعث می‌شود مشکل محیط اجرا شبیه مشکل مسیریابی به نظر برسد. اگر به پشتیبانی فروشنده نیاز دارید، نخستین رویداد مفید راه‌اندازی را ثبت کنید، نه تصویر صفحه از پنجره‌ای که بسته می‌شود.

هرگز کلید خصوصی یا پروفایل کامل با اعتبارنامه‌های جاسازی‌شده را به‌عنوان مواد تشخیصی پیوست نکنید.

یک پرسش بیشتر این تیکت‌ها را حل می‌کند: آیا نسخه نصب‌شده کلاینت هنوز روی این نسخه سیستم‌عامل پشتیبانی می‌شود؟ اگر نه، راه‌حل یک جفت پشتیبانی‌شده است، نه شکار کتابخانه دیگر.

مقالات مرتبط