خطای curl 77: مکان‌های تأیید گواهی در نصب VPN

دستور نصب یک‌خطی را از یک آموزش کپی می‌کنید، Enter را می‌زنید و curl: (77) را دریافت می‌کنید. پیام به مکان‌های تأیید گواهی اشاره دارد، پس غریزه می‌گوید گواهی ارائه‌دهنده VPN خراب است و به سراغ پرچمی بروید که تأیید را نادیده می‌گیرد. این برداشت نادرست است و عمل بر اساس آن یک مشکل فایل محلی را به تصمیمی امنیتی تبدیل می‌کند. از ابتدا آن را مرور کنیم.

گام 1: بخوانید که این عدد چه معنایی دارد

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

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

گام 2: دستوری را که کپی کرده‌اید بخوانید

دستورهای کپی‌شده حروف را پنهان می‌کنند. حرف کوچک -l همان --list-only است که به فهرست کردن پروتکل‌ها مربوط می‌شود. حرف بزرگ -L همان --location است که یک تغییرمسیر HTTP را دنبال می‌کند. این‌ها املای جایگزین نیستند، و آموزشی که یکی را می‌نویسد و دیگری را توصیف می‌کند مردم را به مسیر تغییرمسیری می‌فرستد که هرگز منظور نبوده است.

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

گام 3: پیدا کنید آن ساخت از کدام ورودی CA استفاده می‌کند

با شناسایی فایل اجرایی شروع کنید، چون پاسخ به نحوه کامپایل آن بستگی دارد:

curl --version

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

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

گام 4: ورودی را درست کنید، نه تأیید را

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

نشانی URL را به HTTP تغییر ندهید، --insecure اضافه نکنید، و به گواهی‌ای که از یک دانلود توضیح‌نشده کپی شده اعتماد نکنید. هر یک از این تغییرها آنچه را که حاضرید بپذیرید عوض می‌کند، به جای درست کردن آنچه curl نمی‌توانست بخواند، و این تغییر معمولاً از حادثه بیشتر عمر می‌کند.

مرجع این اعداد فهرست خطاهای curl است و آن‌قدر کوتاه است که یک بار با دقت خوانده شود.

گام 5: دانلود کنید، نگاه کنید، سپس اجرا کنید

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

curl -fL -o vpn-installer.sh https://example.invalid/install.sh
file vpn-installer.sh
head -n 40 vpn-installer.sh

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

به یاد داشته باشید HTTPS چه کرد و چه نکرد. انتقال به میزبانی را که با آن تماس گرفتید احراز هویت کرد؛ محتوای اسکریپت را بررسی نکرد و به شما نمی‌گوید ناشر قابل اعتماد است یا نه.

گام 6: مراحل نصب را جدا نگه دارید

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

اگر نصب موفق شد و تونل بالا آمد، پیش از بستن تیکت مسیرها و یک مقصد واقعی را بررسی کنید. خطای curl وقتی درست شده است که یک curl -I https://example.invalid ساده دوباره کار کند، نه وقتی نصب‌کننده از شکایت دست بردارد.