چرا فرمان openssl کار می‌کند ولی ساخت VPN شکست می‌خورد

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

زمان اجرا و ورودی‌های ساخت دو بسته متفاوت‌اند

یک توزیع OpenSSL را به بسته زمان اجرا تقسیم می‌کند که کتابخانه مشترک و ابزار خط فرمان را فراهم می‌کند، و بسته توسعه که هدرها، نام‌های پیوند بدون نسخه و فراداده pkg-config را فراهم می‌کند. نصب اولی دومی را نصب نمی‌کند، و کامپایلر فقط به دومی نیاز دارد.

آنچه واقعاً حاضر است را بررسی کنید، نه آنچه به یاد دارید نصب کرده‌اید. در سیستم‌های مشتق از Debian بسته توسعه معمولاً libssl-dev است، در حالی که زمان اجرا یک بسته کتابخانه نسخه‌دار به‌همراه فایل دودویی openssl است.

dpkg -l | grep -E 'libssl-dev|libssl3|openssl'
pkg-config --modversion openssl
openssl version

فرمان نخست نشان می‌دهد کدام یک از سه مورد نصب است، دومی نسخه‌ای را گزارش می‌دهد که سیستم ساخت از طریق pkg-config کشف خواهد کرد، و سومی نسخه زمان اجرا را گزارش می‌دهد. یک خط گمشده در خروجی نخست خطا را بی‌درنگ توضیح می‌دهد. ناهمخوانی نسخه میان دومی و سومی مشکلی دیگر است، و معمولاً یعنی دو نصب با هم رقابت می‌کنند.

خروجی کشف خود ساخت را بخوانید

بیشتر شکست‌ها در گزارش پیکربندی دیده می‌شوند اگر آن را پیش از خلاصه بخوانید. ماژول FindOpenSSL در CMake گزارش می‌دهد کدام شاخه include و کدام کتابخانه‌ها را یافت، و زمانی که یک مؤلفه لازم غایب است با پیامی مشخص شکست می‌خورد.

تأیید کنید پروژه از کدام نسخه ماژول استفاده می‌کند، چون نسخه‌ای که داخل درخت کد منبع بسته‌بندی شده ممکن است متفاوت از نسخه‌ای رفتار کند که همراه CMake نصب‌شده توزیع می‌شود. سپس فهرست مؤلفه‌ها را بخوانید: پروژه‌ای که فقط Crypto می‌خواهد به کتابخانه SSL نیاز ندارد، و پروژه‌ای که SSL می‌خواهد شکست می‌خورد اگر تنها بخشی از بسته توسعه حاضر باشد.

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
grep -i -E 'openssl|ssl' build/CMakeCache.txt

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

ساخت را به‌طور محدود به نصب درست هدایت کنید

وقتی OpenSSL تأییدشده بیرون از مسیر جستجوی پیش‌فرض است، FindOpenSSL متغیر OPENSSL_ROOT_DIR را به‌عنوان اشاره برای همان ساخت مستند می‌کند. در سیستم‌های شبه‌یونیکس از pkg-config هم می‌پرسد، پس PKG_CONFIG_PATH مناسب می‌تواند کمک کند بدون تغییر چیزی به‌صورت سراسری.

cmake -S . -B build -DOPENSSL_ROOT_DIR=/opt/openssl-3.2 -DCMAKE_BUILD_TYPE=Release
ldd build/vpn_client | grep -i ssl

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

این انتخاب‌ها را محلی برای ساخت نگه دارید. جایگزینی کتابخانه‌های سیستم یا ویرایش فایل‌های سراسری pkg-config برای راضی‌کردن یک پروژه همان راهی است که میزکار کارآمد به میزکار خراب تبدیل می‌شود. شاخه ساختی که پیشوند را ثبت می‌کند بازتولیدپذیر است؛ تغییری در کل ماشین حادثه‌ای پشتیبانی است که منتظر پروژه بعدی است. وقتی اشاره را تغییر می‌دهید شاخه ساخت را حذف کنید تا حافظه نهان نتواند پاسخ کهنه را نگه دارد.

بدانید چه وقت مشکل خود کد منبع است

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

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

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