چگونه OpenVPN گواهی و کلید را حل می‌کند: PEM درون‌خطی یا مسیر فایل

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

دو شکل ذخیره‌سازی، یک دستورالعمل

دستورالعمل‌های cert و key و ca هر یک یک مسیر یا یک بلوک درون‌خطی می‌پذیرند. وقتی مقدار یک مسیر است، OpenVPN آن فایل را باز می‌کند و شیء را از دیسک می‌خواند. وقتی پیکربندی بلوکی را در بر دارد که با برچسب‌های cert محدود شده، همان دستورالعمل در عوض محتوای میان آن برچسب‌ها را مصرف می‌کند و هیچ فایل جدایی در کار نیست.

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

عکس آن درست نیست. قرار دادن client.crt کنار پروفایلی که داده‌های خود را جاسازی می‌کند چیزی را تغییر نمی‌دهد، چون هیچ چیز در پیکربندی به آن فایل اشاره نمی‌کند. این شایع‌ترین دلیل آن است که فایلی که آشکارا وجود دارد نادیده گرفته به نظر می‌رسد.

چگونه یک بلوک درون‌خطی به شیء تبدیل می‌شود

محتوای درون‌خطی از پیکربندی استخراج و به عنوان متن به تجزیه‌کننده PEM سپرده می‌شود. آن تجزیه‌کننده مرزهای معمول را انتظار دارد: یک خط BEGIN، محتوای base64 و یک خط END متناظر. اگر بلوک به دلیل کپی ناموفق بریده شده باشد، توسط صفحه دانلود در HTML پیچیده شده باشد یا در ویرایشگری باز شده باشد که خط‌تیره‌ها را یکسان‌سازی کرده، تجزیه‌کننده در محتوایی شکست می‌خورد که به نظر موجود می‌آید.

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

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

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

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

چگونه یک ارجاع مسیر حل می‌شود

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

مسیرهای نسبی همان ابهام را به ارث می‌برند. وقتی نام فایل برهنه‌ای می‌بینید، بپرسید پوشه جاری فرایند در محیط تولید چیست، به جای آنکه فرض کنید با ترمینال شما یکسان است.

برای گواهی‌ای که جداگانه ذخیره شده، یک تجزیه برون‌خط شیء را پیش از آنکه چیزی بالاتر از آن را اشکال‌زدایی کنید تأیید می‌کند:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

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

خطای تجزیه‌کننده چه چیزی را می‌تواند بگوید و چه چیزی را نه

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

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

در حین بررسی، نیمه حساس را از گزارش‌های عمومی بیرون نگه دارید. نام دستورالعمل‌ها، متن خطا و ساختار بلوک را به اشتراک بگذارید، در حالی که مواد کلید و هر محتوای شناسایی‌کننده حذف شده است. راهنمای openvpn(8) هر دو شکل دستورالعمل‌های فایل و رفتار پوشه کاری را که پشت آن‌هاست مستند می‌کند.