IPv6 از طریق سرور VPN روی IPv4 همچنان به خروجی IPv6 نیاز دارد

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

نشانه: نشانی‌ای هست و مسیری نیست

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

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

بسته را پس از بیرون‌آوری از کپسوله دنبال کن

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

مکانیک کپسوله‌سازی IPv6 روی IPv4 در RFC 4213 توصیف شده، و جزئیات مهم آنجا این است که دو سر همچنان به اتصال واقعی IPv6 در آن سوی تونل نیاز دارند. پیچیدن یک سرآیند، بالادست از هیچ نمی‌سازد.

دو لایهٔ تونل، دو بررسی مستقل

هر لایه را جداگانه بررسی کن، چون تونل بیرونی سالم، تونل درونی خراب را پنهان می‌کند. مسیر بیرونی را با پینگ IPv4 از کلاینت به سرور بررسی کن و پورتی را که استفاده می‌کنی تأیید کن. سپس مسیر درونی را روی سرور بررسی کن، جایی که ip -6 route باید یک مسیر پیش‌فرض یا مسیری مشخص را نشان دهد که از یک بالادست واقعی آموخته شده، و ip -6 addr باید پیشوند مبدأیی را نشان دهد که بالادست می‌پذیرد. هر چیزی کمتر از این، تزی روی رابط است.

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

همین در کلاینت هم صادق است: ip -6 route get 2001:4860:4860::8888 باید دستگاه تونل را نام ببرد، و اگر دستگاه فیزیکی را نام می‌برد، کلاینت اصلاً از VPN برای IPv6 استفاده نمی‌کند.

پیشوند مبدأ، اندازه و ICMPv6

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

برای کپسوله‌سازی اضافه‌ای که پشته‌ات واقعاً استفاده می‌کند بودجه بگذار، و ICMPv6 را کارا نگه دار، از جمله Packet Too Big. سرآیند دوم بار مفید قابل استفاده را کوچک می‌کند، پس مسیری که به پینگ‌های کوچک پاسخ می‌دهد می‌تواند در انتقال فایل هم شکست بخورد، و دیوار آتشی که همهٔ ICMPv6 را می‌ریزد، مشکل اندازه‌ای قابل جبران را به سیاهچاله تبدیل می‌کند. پیش از اعلام سرویس، یک انتقال بزرگ را آزمایش کن.

چه چیزی مسئله‌ای کاملاً دیگر است

رسیدن به برنامه‌ای که فقط IPv4 است از کلاینتی که فقط IPv6 است، ترجمه است نه تونل‌سازی، و به چیزی مانند یک چیدمان NAT64 که آگاهانه مستقر شده نیاز دارد. مقصد فقط به این دلیل که یک سرآیند تونل اضافه کرده‌ای، آن را نمی‌فهمد. سرویس‌های گذار تاریخی همان مراقبت را می‌طلبند: RFC 7526 مدل رلهٔ anycast 6to4 را منسوخ کرد، پس راهنمایی که حول آن نوشته شده چیزی را توصیف می‌کند که دیگر رلهٔ عمومی نگهداری‌شده ندارد.

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