این خطا پیش از درخواست گذرواژه می‌رسد و همین بخش سودمند است: هنوز هیچ چیزی احراز هویت نشده، پس مشکل اعتبارنامه‌ها نیست. در لینوکس همان پنجره AnyConnect می‌تواند از نسخه قدیمی پروتکل، گروه تبادل کلید 1024 بیتی یا مجموعه رمزیی بیاید که سیاست رمزنگاری سیستم آن را رد می‌کند. آن را روی سه ماشین به سه روش مختلف برطرف کرده‌ام و آنچه این راه‌حل‌ها را از هم جدا می‌کند دامنه اثر است، نه زیرکی. هرکدام در جای درست قابل دفاع و در هر جای دیگر پیش‌فرض بدی است.

پیش از دست زدن به سیاست، پیام را بخوانید

رشته دقیق را از پنجره بردارید. شکایت نسخه به لایه پروتکل اشاره دارد، شکایت گواهی به اعتماد یا نام‌گذاری، و ورود ناموفق به اعتبارنامه‌ها. دروازه‌ای که TLS 1.0 با گروه DHE 1024 بیتی، AES-256-CBC و امضای SHA-1 ارائه می‌دهد می‌تواند گواهی کاملاً معتبر داشته باشد و باز هم پیش از ارسال اعتبارنامه‌های شما توسط سیاستی مدرن رد شود.

نقطه پایانی را با OpenSSL سیستم، با نام میزبان واقعی و پورتی که کلاینت استفاده می‌کند بررسی کنید.

شکست openssl s_client -connect vpn.example.com:443 -servername vpn.example.com در حالی که -tls1 -cipher DEFAULT@SECLEVEL=0 موفق می‌شود نشان می‌دهد مرز، نسخه و اندازه کلید با هم است. اگر فرمان نخست به‌جای هشدار پروتکل، کلید DH کوچک گزارش کند، نسخه درست است و فقط گروه نیاز به توجه دارد. هرگز کلید خصوصی یا گذرواژه را در بررسی نگذارید.

گزینه 1: کل میزبان را با سیاست رمزنگاری شل کنید

در Fedora و RHEL 8 و 9، update-crypto-policies --set LEGACY سیاست سیستم OpenSSL را پایین می‌آورد و update-crypto-policies --show تأیید می‌کند چه چیزی فعال است. این کار معمولاً تونل را برمی‌گرداند، اما سیاست هنگام شروع فرایند خوانده می‌شود، پس پیش از آزمون دوباره کلاینت و هر فرایند کمکی که ساخته است را دوباره راه‌اندازی کنید. همچنین پروتکل‌های قدیمی‌تر و گروه‌های ضعیف‌تر را برای هر کلاینت TLS روی ماشین مجاز می‌کند، از مرورگر پنجره کناری تا مدیر بسته‌ای که هسته را به‌روز می‌کند.

این گستردگی هم همه هدف است و هم همه مشکل. LEGACY در سطح کل میزبان است، پایدار و آسان برای فراموش کردن، پس باید یک گام تشخیصی یا استثنای مستند در یک ساخت مدیریت‌شده باشد، هرگز حالت استراحت یک ایستگاه کاری نه. یکی را دیده‌ام که دو سال روی LEGACY ماند چون یک پورتال داخلی به آن نیاز داشت و هیچ‌کس نمی‌توانست بگوید کِی شروع شده.

Debian و Ubuntu هیچ کلید واحدی برای این کار ندارند. معادل آن ویرایش /etc/ssl/openssl.cnf است که MinProtocol پایین‌تر و CipherString = DEFAULT@SECLEVEL=0 را در بخش پیش‌فرض‌های سیستم تنظیم می‌کند. همان دامنه، فایل متفاوت، کمی آسان‌تر از نظر دور افتادن در هنگام ارتقای نسخه.

گزینه 2: یک فایل پیکربندی برای یک کلاینت

پیکربندی OpenSSL برای هر فرایند تغییر را درون یک درخت فرایند نگه می‌دارد، اما تنها اگر فایل به همان شکلی که کتابخانه انتظار دارد سیم‌کشی شده باشد. نام‌گذاری یک بخش ssl_conf کافی نیست: OpenSSL کلید سطح بالای openssl_conf را می‌خواند، آن را تا یک بخش راه‌اندازی دنبال می‌کند و تنها سپس به پیش‌فرض‌های SSL می‌رسد.

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

OPENSSL_CONF را به آن فایل اشاره دهید و کلاینت VPN را از طریق پوششی که آن را صادر می‌کند اجرا کنید. هر چیز دیگری روی میزبان سیاست پیش‌فرض را نگه می‌دارد و همین ویژگی است که هنگام رسیدن پرسش انطباق اهمیت دارد. پیش از سرزنش دروازه تأیید کنید فایل واقعاً مؤثر است: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 باید رمزهای TLS 1.0 را فهرست کند و نتیجه خالی یعنی زنجیره شکسته است و کلاینت بی‌صدا پیش‌فرض‌های سیستم را نگه داشته.

فایل به نسخه حساس است. OpenSSL 1.1.1 و 3.x همان نام‌های بخش را می‌پذیرند، اما پردازش دستورها پیرامون ارائه‌دهندگان در 3.x تغییر کرده، پس با گزارش خود کلاینت و یک دست‌دادن آزمایشی بررسی کنید، نه با فرض اینکه فایل خوانده شده. غلط تایپی در نام بخش به‌صورت باز شکست می‌خورد و کلاینت بی‌صدا از پیش‌فرض‌های سیستم استفاده می‌کند.

محدودیت پوشش است. هر چیزی که به GnuTLS یا NSS پیوند خورده باشد OPENSSL_CONF را نادیده می‌گیرد و هر فرایند کمکی که کلاینت بدون به‌ارث بردن محیط اجرا کند نیز همین‌طور. پیش از ساخت پوشش با ldd بررسی کنید باینری واقعاً به کدام کتابخانه TLS پیوند خورده، چون پاسخ تعیین می‌کند این گزینه اصلاً وجود دارد یا نه.

گزینه 3: یک ماشین مجازی یا کانتینر یک‌بارمصرف

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

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

مقایسه چه چیزی برایتان می‌گذارد

با سه پرسش انتخاب کنید: چه کسی به پروتکل قدیمی نیاز دارد، برای چه مدت، و چه کسی متوجه می‌شود اگر استثنا از دلیلش عمر بیشتری کند. یک برنامه، یک نفر، چند روز، به پیکربندی هر فرایند اشاره دارد. یک ناوگان کامل پشت یک دستگاه به خود دروازه اشاره دارد. هر چیزی که به سیاست دائمی LEGACY روی میزبان نیاز دارد، تصمیمی خرید در لباس فنی است.

اصلاح پایدار به دستگاه تعلق دارد: TLS 1.2 یا بالاتر، گروهی دست‌کم 2048 بیتی، رمز AEAD و گواهی با امضای مدرن. این تغییر را از مالک دستگاه بخواهید، سپس نسخه و رمز مذاکره‌شده را در گزارش کلاینت تأیید کنید. استثنا را با میزبان، دروازه، پروتکل مذاکره‌شده، تأییدکننده و تاریخ انقضا بنویسید، چون همان یادداشت است که مانع پیش‌فرض شدن یک راه‌حل موقت می‌شود.

مقالات مرتبط