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

تصمیم بگیرید آزمون چه چیزی را باید اثبات کند

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

سودمندترین شکل، یک نقطه پایانی تأییدشده را نام می‌برد که نشانی مبدأ مشاهده‌شده را گزارش می‌کند.

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

مشاهده را در بافت درست اجرا کنید

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

روی یک میزبان معمولی این یعنی همان کاربر و همان واحد. در محیط کانتینری یعنی وارد شدن به فضای نام شبکه کانتینر به جای آزمودن از میزبان. روی سرویس systemd می‌تواند یعنی یک واحد گذرا با همان تنظیمات.

درخواست بعدی تنها وقتی معنا دارد که در بافت درست باشید.

خانواده‌های نشانی را جداگانه بررسی کنید

هر خانواده را صریح بخواهید، چون یک درخواست موفق IPv4 اصلاً مسیر IPv6 را به کار نمی‌گیرد. انتخاب‌گرهای --ipv4 و --ipv6 انتخاب را تحمیل می‌کنند و تفاوت میان دو نتیجه خودش اطلاعات است.

curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-source

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

هر دو پاسخ را کنار هم ثبت کنید. یکی از آن‌ها به تنهایی نیمی از یک واقعیت است.

چهار چیزی را اضافه کنید که بررسی خروج از قلم می‌اندازد

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

CheckWhat it provesWhat it does not
Included and excluded destinationsThe split behaves as designed for those flowsCoverage of any other destination
Resolver pathWhere a fresh lookup actually travelledWhere a cached answer came from
Tunnel-down behaviourThe failure policy for a new requestWhat an already open connection does
Reconnect and restartThe requirement survives the lifecycle eventBehaviour under load or partial failure

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

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

شواهد ثبت کنید، نه حکم

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

این حساب‌رسی سوابق اپراتور VPN نیست و گواهی برای هر برنامه آینده روی دستگاه هم نیست.

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

مقالات مرتبط