رد شدن اتصال مشکل گواهی نیست: راهنمای عملی VPN

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

دو بررسی این موارد را در کمتر از یک دقیقه از هم جدا می‌کند و هیچ‌کدام به تنظیمات اعتماد دست نمی‌زند.

خطا را در لایه‌ای بخوانید که آن را تولید کرده است

ECONNREFUSED از connect یعنی تلاش انتقال رد شده است: چیزی با reset پاسخ داده یا پشته از پورت غیرقابل‌دسترس خبر داده است. مشکل گواهی نمی‌تواند چنین خطایی تولید کند، چون دست‌دادن TLS هرگز بدون اتصال انتقال آغاز نمی‌شود. اگر رد شدن می‌بینید، کلاینت هرگز به مرحله ارائه گواهی نرسیده است. همین یک واقعیت ابطال را به‌عنوان علت کنار می‌گذارد.

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

رد شدن TCP: هیچ‌کس گوش نمی‌دهد

برای TCP بررسی کنید که نمونه موردنظر در حال اجرا و به نشانی و پورت پروفایل متصل باشد. ss -lntp شنونده‌ها را نشان می‌دهد و نبود یکی توضیح معمول است. دیوار آتشی که به‌جای دورانداختن رد می‌کند همان پیام را در سمت کلاینت تولید می‌کند، به همین دلیل هر دو را بررسی می‌کنید.

خانواده نشانی را هم بررسی کنید. سرویسی که به 127.0.0.1 یا فقط به IPv6 متصل است، کلاینتی را که به دیگری تفکیک می‌شود رد می‌کند.

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

UDP دست‌دادنی برای رد کردن ندارد

OpenVPN روی UDP اتصالی به معنای TCP برقرار نمی‌کند، پس در زمان connect چیزی برای رد کردن نیست. در Linux، خطایی که یک سوکت UDP نشان می‌دهد می‌تواند از ICMP port-unreachable تولیدشده توسط یک داده‌نگاره قبلی بیاید. صفحه راهنمای udp(7) این رفتار ناهمگام را توصیف می‌کند.

به همین دلیل کلاینت UDP می‌تواند رد شدن را چاپ کند در حالی که فرایند سرور در حال اجراست اما به نشانی مورد انتظار متصل نیست.

CRL واقعاً کجا بررسی می‌شود

CRL در طول دست‌دادن TLS و پس از آنکه همتا گواهی خود را ارائه کرد مشورت می‌شود، و فقط اگر پیکربندی سرور آن را فعال کند. گزینه crl-verify در OpenVPN به فایل اشاره می‌کند و شکست در گزارش سرور به‌صورت خطای اعتبارسنجی با نام گواهی ظاهر می‌شود.

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

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

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

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

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