آیا --key-password در OpenConnect گذرواژهٔ حساب VPN شماست؟

نام گزینه را تحت‌اللفظی بخوانید. آن یک کلید را نام می‌برد و سردرگمی زمانی آغاز می‌شود که فایلی که باز می‌شود با حسابی که احراز هویت می‌شود اشتباه گرفته شود. گذرواژهٔ حساب را در آن گزینه بچسبانید و کلاینت تلاش می‌کند با آن یک فایل کلید باز کند، که به دلایلی شکست می‌خورد که هیچ ارتباطی با ورود به VPN ندارد.

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

دو راز، دو کار متفاوت

نقش‌ها را دسترسی به فایل در برابر اجازهٔ ورود به شبکه بخوانید. گذرواژهٔ کلید، کلید خصوصی PEM را که در --sslkey نام برده شده رمزگشایی می‌کند تا گواهی کلاینت TLS بتواند ارائه شود. این رمزگشایی به‌صورت محلی و درون فرایند کلاینت رخ می‌دهد و عبارت عبور خودش هرگز به دروازه نمی‌رود. آنچه دروازه می‌بیند گواهی و امضایی است که با کلید ساخته شده. راهنمای OpenConnect گزینهٔ --key-password را کنار --certificate و --sslkey نگه می‌دارد و در نسخه‌هایی که می‌توانند از کلید نگهداری‌شده در TPM استفاده کنند، همان گزینه در عوض گذرواژهٔ کلید ریشهٔ ذخیره‌سازی را حمل می‌کند.

گذرواژهٔ حساب از نوع دیگری است. به تبادل احراز هویت می‌رود: فرمی با نام کاربری و گذرواژه، یک توکن، یک دور SAML یا ترکیبی که دروازه اعلام می‌کند. برخی استقرارها وقتی گواهی تنها عامل است اصلاً آن را نمی‌خواهند و برخی حتی پس از گواهی هم می‌خواهند، زیرا گواهی دستگاه را اثبات می‌کند در حالی که حساب شخص را اثبات می‌کند.

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

چه وقت گذرواژهٔ کلید واقعاً لازم است

این گزینه فقط وقتی معنا دارد که کلید رمزگذاری‌شده‌ای برای باز کردن باشد. اگر با نام کاربری و گذرواژه و بدون گواهی کلاینت متصل می‌شوید، --key-password چیزی برای اثرگذاری ندارد و افزودنش چیزی را تغییر نمی‌دهد. اگر با --certificate و --sslkey متصل می‌شوید، قالب خود فایل کلید تعیین می‌کند که اصلاً عبارت عبور خواسته شود یا نه.

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

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

هر دو راز را از تاریخچهٔ پوسته بیرون نگه دارید

آرگومان‌های خط فرمان از طریق جدول فرایندها برای دیگر کاربران محلی قابل خواندن‌اند و اغلب در تاریخچهٔ پوسته، اسکریپت‌ها و رونوشت‌های پشتیبانی ثبت می‌شوند. OpenConnect می‌تواند گذرواژهٔ حساب را با --passwd-on-stdin از ورودی استاندارد بخواند و عبارت عبور کلید می‌تواند از یک پرسش تعاملی یا یک عامل به‌جای آرگومان بیاید. هیچ‌یک از این سازوکارها راز را به‌تنهایی امن نمی‌کند، اما هر دو آن را از در معرض‌ترین جاها دور نگه می‌دارند.

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

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

دکمهٔ مردهٔ میزکار نقص دیگری است

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

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

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