پینگ به همتای تونل IPv6 شما ناموفق است؟ نشانی :: را بررسی کنید

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

نشانه‌ای که به نشانی اشاره می‌کند

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

شناسه تمام‌صفر به عنوان anycast رزرو شده است

RFC 4291 شناسه رابط تمام‌صفر را به عنوان نشانی anycast روتر زیرشبکه نگه می‌دارد، بنابراین یک /64 مانند 2001:db8:4a::/64 هیچ میزبان قابل استفاده‌ای در 2001:db8:4a:: ندارد. این رزرو جای خود را می‌ارزد: اعلان‌های روتر و کشف همسایه همان شکل را نشانی می‌کنند و روتر برای پیشوندی که سرویس می‌دهد پاسخ می‌دهد. تخصیص آن مقدار به نقطه پایانی تونل نقش روتر را به یک برگ می‌دهد و همین است که چیزی برنمی‌گردد. هر شناسه دیگری در پیشوند به عنوان میزبان کار می‌کند، پس اصلاح معمولاً یک رقم است.

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

نشانی‌های میزبان را تخصیص دهید و پیشوند را مسیریابی کنید

برای دو سر ::1 و ::2 را انتخاب کنید، یکی را با ip -6 addr add 2001:db8:4a::2/64 dev tun0 اضافه کنید و سپس پیشوند دور را مسیریابی کنید نه اینکه بخواهید به آن نشانی بدهید. یک مسیر برای 2001:db8:4a::/64 از تونل سر دور را قابل‌دسترس می‌کند؛ نشانی به‌تنهایی فقط رابط محلی را پیکربندی‌شده می‌کند.

برای تونل کامل مرحله سومی هست، یک مسیر پیش‌فرض برای unicast جهانی از طریق دستگاه، که معادل IPv6 فرستادن همه چیز به تونل است. اگر آن را جا بیندازید، IPv6 همچنان از پیوند فیزیکی استفاده می‌کند در حالی که IPv4 داخل تونل سفر می‌کند، پس میزبان دقیقاً همان ترافیکی را نشت می‌دهد که فکر می‌کردید پوشش داده شده است. با ip -6 route get 2001:4860:4860::8888 تأیید کنید و بخوانید کدام دستگاه را نام می‌برد، نه اینکه پاسخ را فرض کنید.

multicast پیش از مسیریابی رد می‌شود

Android نشانی‌ها و مسیرها را برای VpnService.Builder از طریق LinkAddress اعتبارسنجی می‌کند و آن سازنده multicast را یکسره رد می‌کند. اگر پیشوند multicast را به عنوان مسیر به آن بدهید، نتیجه به جای مسیر، شکست پارامترهای نامناسب LinkAddress است، که پاسخی از جنس اعتبارسنجی است نه شبکه. این رد شدن با رسانه می‌خواند: دستگاه tun نقطه‌به‌نقطه multicast لایه پیوند ندارد، پس مسیر گروهی روی آن مدل تحویلی برای نصب ندارد. نشانی‌های گروهی را خود پشته می‌سازد و مصرف می‌کند، نه اینکه دستی پیکربندی شوند.

نشانی‌های IPv6 all-nodes و solicited-node زیر همان قاعده‌اند. رابط آن‌ها را حمل می‌کند چون پشته آن‌ها را آنجا گذاشته است، نه چون سیاستی چنین قصدی داشته.

تونل در عوض چه چیزی می‌تواند حمل کند

انتقال کشف multicast از طریق تونل به لایه‌ای نیاز دارد که عضویت گروهی را بفهمد: پل TAP که یک قطعه Ethernet ارائه می‌دهد، رله سطح برنامه، یا پروتکل مسیریابی که صریحاً به آن گفته شود به کدام همتاها تکثیر کند. هیچ‌یک از این‌ها در مدل VpnService وجود ندارد، جایی که برنامه بسته‌ها را می‌خواند و می‌نویسد و هیچ فراخوانی برای پیوستن به گروه برای تونل ندارد. یا مؤلفه‌ای را که گروه‌ها را می‌فهمد اضافه کنید یا شرط را از طراحی حذف کنید.

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

سه بررسی پیش از تخصیص هر چیز

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

مسیری که پلتفرم هرگز نصب نکرده با انتظار بیشتر اشکال‌زدایی نمی‌شود، و نشانی‌ای که هرگز میزبان نبوده با پینگ بهتر درست نمی‌شود.