چرا OpenConnect پس از تعویض گواهی، دروازه را رد می‌کند؟
شکست تأیید پس از تعویض گواهی دروازه، تصمیمی درباره اعتماد است، نه تونلی خراب. بین CA صادرکننده و تثبیت یک کلید یکی را انتخاب کنید.
دروازه‌ها گواهی‌ها را جایگزین می‌کنند و کلاینتی که دیروز وصل می‌شد، در نخستین تبادل TLS متوقف می‌شود. پیام به جای نقص شبکه، دلیلی برای تأیید نام می‌برد، و خود ماشین تغییر نکرده است، که همان سرنخ مفید است. آنچه شکسته، رابطه میان گواهی‌ای است که اکنون ارائه می‌شود و ریشه‌هایی که کلاینت حاضر است در نظر بگیرد. تعمیر آن تصمیمی درباره اعتماد است، پس پیش از نوشتن هر گزینه‌ای آن تصمیم را بگیرید.
پیش از تغییر هر تنظیم اعتماد، شکست را بخوانید
خطای از نوع «امضاکننده غایب» یعنی زنجیره به چیزی می‌رسد که کلاینت نمی‌پذیرد. می‌تواند گواهی تمدیدشده از یک مرجع داخلی، جایگزینی از یک مرجع عمومی، یا دستگاهی در میانه باشد که گواهی خودش را ارائه می‌کند. فقط جمله‌بندی نمی‌تواند آن موارد را از هم جدا کند، پس پیش از تصمیم به صادرکننده نگاه کنید.
اتصال را یک بار در پیش‌زمینه اجرا کنید و بگذارید شکست بخورد، چون خروجی تعاملی نام سرور، زنجیره صادرکننده و اثر انگشتی را که کلاینت محاسبه کرده در خود دارد. آن صادرکننده را با مرجعی مقایسه کنید که سازمان شما واقعاً اداره می‌کند. اگر اثر انگشت تغییر کرده ولی صادرکننده نه، آن را مشکوک بدانید تا زمانی که تمدید از راه کانالی که از پیش به آن اعتماد دارید تأیید شود. حدس زدن در این مرحله همان راهی است که فرد در پایان کلید یک شنودگر را تثبیت می‌کند.
نسخه کلاینت را در همان یادداشت ثبت کنید. بخش زیادی از شکست‌هایی که شبیه مشکلات اعتماد به نظر می‌رسند از کلاینت قدیمی‌تری می‌آید که با تبادل جدیدتر دروازه روبه‌رو می‌شود.
میان اعتماد به صادرکننده و تثبیت یک کلید یکی را انتخاب کنید
هر دو گزینه اتصال را موفق می‌کنند. بعدها به شکل‌های متضاد می‌شکنند، پس انتخاب به شکستی تعلق دارد که می‌توانید تحمل کنید.
| Approach | Good fit | What breaks it |
|---|---|---|
Trust the issuing CA with --cafile | Internal PKI you can obtain over an already trusted channel | CA rotation, or a client that still falls back to public roots |
Pin one key with --servercert | No CA relationship, or exactly one key should ever be accepted | Any reissue that generates a new key pair |
وقتی گواهی از مرجعی می‌آید که می‌توانید مستقل تأیید کنید، سراغ فایل CA بروید، چون تمدیدها سپس بدون دست زدن به آرگومان‌های کلاینت کار می‌کنند. آن را با کلیدی جفت کنید که ریشه‌های سیستم را غیرفعال می‌کند، وگرنه یک مرجع عمومی می‌تواند بررسی را به جای شما برآورده کند. در عوض وقتی دروازه CA قابل تهیه ندارد یا وقتی هدف تنگ‌ترین استثنای ممکن است، تثبیت کنید. هیچ‌یک از دو راه به‌طور انتزاعی امن‌تر نیست: CA در طول تمدیدها مقیاس می‌گیرد، تثبیت آسان‌تر بازبینی می‌شود.
هر کدام را انتخاب کنید، مقدار مورد اعتماد باید از کانالی برسد که پیش از رخ دادن تغییر قابل اعتماد بود. مدیر، یک نشست کنسول روی دروازه، یا نسخه‌ای که از پیش گرفته شده، همه پذیرفتنی‌اند. کپی کردن هر اثر انگشتی که اعلان نشان می‌دهد راحت است و دقیقاً همان چیزی است که شنودگر امیدش را دارد.
مقدار را در همان فرمانی بگذارید که واقعاً اجرا می‌کنید
تثبیت در گزینه گواهی سرور می‌رود و پیشوندش رمزگذاری را تعیین می‌کند: خلاصه‌های هگزادسیمال کلید عمومی زیر sha1 یا sha256، و تثبیت کلید base64 زیر pin-sha256. ارائه آن، اعتماد سیستم را برای آن اجرا هم غیرفعال می‌کند، پس کلید تثبیت‌شده تمام تصمیم می‌شود.
sudo openconnect --protocol=gp vpn.example.com --user alice \
--servercert pin-sha256:AbCdEf... # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trustکلاینت خلاصه بریده‌شده را تطبیق می‌دهد و تنها چهار نویسه پس از پیشوند را می‌پذیرد، که تله است نه راحتی. مقدار کوتاه‌شده محلی می‌گذرد و همچنان دروازه‌ای را که قصد داشتید شناسایی نمی‌کند. به جای بازتایپ از یک پیام، رشته کامل را که کلاینت در نخستین تلاش چاپ کرد کپی کنید. سپس گزینه تمام‌شده را به اسکریپت پوششی، فایل واحد یا نمایه‌ای که اتصال را اجرا می‌کند منتقل کنید، تا تصمیم اعتماد قابل بازبینی و ویرایش‌های بعدی عمدی باشند.
اجراکننده‌های رومیزی و افزونه NetworkManager نسخه خودشان از آرگومان‌های اتصال را ذخیره می‌کنند. اسکریپتی که روی دیسک ویرایش شده به نمایه‌ای که پیش‌تر وارد شده نمی‌رسد، پس مقدار ذخیره‌شده همچنان برنده است.
جابه‌جایی را بدون قفل کردن خودتان بیرون مدیریت کنید
گزینه می‌تواند بیش از یک بار داده شود، پس تغییر برنامه‌ریزی‌شده می‌تواند کلید خارج‌شونده و ورودی را با هم بپذیرد. تثبیت جدید را پیش از جابه‌جایی دروازه اضافه کنید، تا زمانی که نشست‌ها مهاجرت می‌کنند هر دو را فهرست کنید، و کنارگذاشته را وقتی کلید قدیمی رفت حذف کنید. آن پنجره به یک مسئول نیاز دارد، چون تثبیت دوگانه فراموش‌شده کلیدی را مورد اعتماد رها می‌کند بی‌آنکه کسی مراقبش باشد. بازسازی‌ای که جفت کلید تازه تولید می‌کند تثبیت خالص را می‌شکند، و بازیابی همان رویه در جهت دیگر است.
تاریخ تغییر را کنار تثبیت بنویسید. تثبیتی که تاریخ بازبینی ندارد، قطعی آینده با پیام خطای گیج‌کننده است.
پیش از ویرایش اعتماد، نسخه کلاینت را کنار بگذارید
کلاینت قدیمی ممکن است هنگام تجزیه پاسخ احراز هویتی که دروازه از آن پس تغییر داده شکست بخورد، و پیام سطحی همچنان از اتصال می‌گوید نه از تجزیه‌گر. نسخه نصب‌شده را با آنچه دروازه مستند می‌کند مقایسه کنید، و پیش از تغییر هر تنظیم اعتماد، بسته‌ای فعلی را در نمایه‌ای یک‌بارمصرف بیازمایید.
openconnect --versionپس از تعمیر، دو چیز را بررسی کنید نه یکی: بارگذاری پورتال از تونل، و پاسخ یک نشانی داخلی معمولی. دست‌دادن کامل فقط ثابت می‌کند که تصمیم اعتماد پذیرفته شده است.