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

گام 1: مشخص کنید کدام مسیر IPv6 را آزمایش می‌کنید

این را در یک جمله بگویید. درخواست به نشانی IPv6 خود سرور تونل، تونل را آزمایش می‌کند؛ درخواست به میزبانی آن‌سوی خروج، خروجِ IPv6 خروج را آزمایش می‌کند؛ درخواست به یک نشانی IPv6 خصوصی، مسیر داخلی را آزمایش می‌کند.

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

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

ip -6 route get 2001:db8:1::10 مسیر، نشانی مبدأ و رابطی را که هسته به کار می‌برد چاپ می‌کند، و بقیهٔ آزمایش به همین واقعیت وابسته است.

وجود یک رابط با انتخاب‌شدنش یکی نیست. میزبان‌های دوصفحه جدول اولویت دارند و /etc/gai.conf در Linux می‌تواند تغییر دهد کدام خانواده برای نامی که به هر دو تحلیل می‌شود برنده شود.

گام 3: از مقصد و نامی مشروع استفاده کنید

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

درخواست را در قالبی اجرا کنید که نشانی به‌کاررفته را نشان دهد: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. گزینهٔ -6 خانواده را تحمیل می‌کند و این‌گونه «IPv6 کار نمی‌کند» را از «IPv6 ترجیح داده نشد» جدا می‌کنید.

برای یک بررسی محض دسترسی‌پذیری که ICMPv6 در آن مجاز است، ping -6 -c 3 2001:db8:1::10 کافی است. مسیر را ثابت می‌کند و هیچ چیز بالاتر از آن را.

گام 4: هر دو سر را تطبیق دهید

وقتی به هر دو سر دسترسی دارید، tcpdump -ni any ip6 and host 2001:db8:1::10 را روی کارخواه و معادلش را روی منبع، با برچسب زمان اجرا کنید و تأیید کنید که همان جریان در هر دو دیده می‌شود. همین است که یک نتیجهٔ محتمل را به شاهد تبدیل می‌کند: دید کارخواه به‌تنهایی نمی‌تواند پاسخ منبع را از پاسخ چیزی در میان تشخیص دهد. ثبت را باریک و محدود به همان یک مقصد نگه دارید تا خروجی خوانا بماند و نشست بی‌ربط کسی به فایل نرسد.

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

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

گام 5: بنویسید آزمایش چه چیزی را ثابت نکرد

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

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

مقالات مرتبط