تلاش اشتباه VPN: کدام نوع اعتبارنامه از مرز گذشت؟

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

توقف کنید و شواهد را نگه دارید

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

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

چه چیزی می‌تواند از مرز بگذرد

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

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

اثبات کلید، بارگذاری کلید نیست

TLS مدرن این دو ایده را عامدانه جدا نگه می‌دارد. RFC 8446 پیام CertificateVerify را توصیف می‌کند، جایی که کلاینت چالشی را با کلید خصوصی متناظر با گواهی‌اش امضا می‌کند. امضا بدون حمل کلید مالکیت را نشان می‌دهد، از این رو تلاشی که با گواهی تأیید هویت شده به‌طور خودکار افشای کلید نیست.

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

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

تلاش را از گزارش بازسازی کنید

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

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

grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30

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

تصمیم بگیرید، سپس عمل کنید

تصمیم از مصنوع برمی‌آید نه از اینکه خطا چقدر هشداردهنده به نظر می‌رسید. چهار سطر را در برابر واقعیت‌هایی که بازسازی کردید بخوانید:

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

سپس نتیجه محدود را بنویسید: چه فرستاده شد، چه ناشناخته مانده و کدام اعتبارنامه نیازمند اقدام است. همان رکورد است که بازبینی بعدی خواهد خواست و از هر یک از دو نتیجه راحت‌تر سودمندتر است.