کدام فایل CA در پروفایل OpenVPN فقط با رمز عبور قرار می‌گیرد؟

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

ترتیب مهم است: دو پرسش آخر تنها زمانی معنا دارند که بدانید کدام ماده باید وجود داشته باشد.

با آنچه پروفایل از قبل دارد آغاز کنید

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

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

بسته تحویل‌شده را از نظر فایل‌هایی که پروفایل به آن‌ها اشاره دارد بررسی کنید: یک گواهی CA، گاهی گواهی و کلید جدای کلاینت، و احتمالاً فایل tls-auth یا tls-crypt. پروفایلی که به چهار فایل اشاره دارد اما با دو فایل می‌رسد ناقص است، و هیچ اندازه اشاره به فیلدها این را درست نمی‌کند. به‌جای جایگزین کردن گواهی‌ای که تصادفاً دارید، قطعه گمشده را از اپراتور بخواهید.

چهار نوع ماده را از هم جدا کنید

گواهی CA ماده عمومی است که برای تأیید هویت سرور به کار می‌رود. گواهی کلاینت کاربر یا دستگاه را به سرور معرفی می‌کند. کلید خصوصی نیمه پنهان آن گواهی کلاینت است و هرگز نباید کلید امضای CA یا کلید سرور باشد. ماده tls-auth یا tls-crypt یک راز مشترک جداست که کانال کنترل را محافظت می‌کند. این چهار مورد قابل تعویض نیستند، و هدایت فیلد CA به یک گواهی کلاینت شکست تأییدی پدید می‌آورد که شبیه مشکل اعتماد به نظر می‌رسد.

احراز هویت فقط با رمز عبور تغییر می‌دهد که کدام یک از این چهار مورد را لازم دارید، نه معنای آن‌ها را. با auth-user-pass و remote-cert-tls server کلاینت همچنان سرور را بر پایه CA تأیید می‌کند، به همین دلیل فیلد CA حتی وقتی هیچ گواهی کلاینتی وجود ندارد هم ظاهر می‌شود. سیاست اپراتور تعیین می‌کند آیا گواهی کلاینت هم لازم است یا نه، و هیچ گفت‌وگویی نمی‌تواند این را به شما بگوید.

کلاینت را به فایل اعتماد هدایت کنید

خودِ فایل گواهی CA را انتخاب کنید، نه پوشه‌ای که آن را دارد و نه بسته .p12 که هویت کلاینت را در خود دارد. در Windows نحو مسیر و انتخابگر فایل متفاوت از نمونه‌های Linux در بیشتر راهنماها رفتار می‌کنند، پس از آنچه کلاینت نصب‌شده می‌پذیرد استفاده کنید و تأیید کنید که حساب اجراکننده آن می‌تواند فایل را بخواند. مشکل مجوز و فایل گمشده در گفت‌وگو یکسان به نظر می‌رسند اما خطوط گزارش متفاوتی تولید می‌کنند. پس از انتخاب، تنظیمات پروفایل را دوباره باز کنید تا تأیید شود کلاینت انتخاب را نگه داشته است.

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

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

خطای بعدی را بخوانید، نه همان خطا را

هدف از ارائه CA درست تغییر خطاست، نه ناپدید کردن آن. شکست هویت سرور پس از بارگذاری CA یعنی گواهی با نام مورد انتظار یا انتظار remote-cert-tls مطابقت نداشته، که ترمیمی متفاوت از رد رمز عبور است. رد رمز عبور یعنی لایه TLS موفق شده و اعتبارنامه نادرست است. نخستین پیام تازه را نگه دارید؛ همان پیام سودمند است.

کلاینتی که متصل می‌شود اما به جایی نمی‌رسد، اعتماد را کاملاً پشت سر گذاشته و اکنون با پرسش مسیریابی یا DNS روبه‌روست.

هرگز تأیید را غیرفعال نکنید تا از آن گفت‌وگو بگذرید. کلاینتی که هر گواهی‌ای را می‌پذیرد دلیلی برای درخواست CA ندارد، و تونلی که می‌سازد همانی نیست که اپراتور در نظر داشت.