DS-Lite میزبانی ورودی IPv4 را مسدود می‌کند، نه VPN خروجی را

DS-Lite راهی است برای دادن اتصال IPv4 به مشتری از طریق شبکهٔ دسترسی که فقط IPv6 حمل می‌کند. روتر خانه آدرس IPv4 عمومی اختصاصی خودش را ندارد، و همین یک واقعیت مردم را قانع می‌کند که VPN روی IPv4 نمی‌تواند از آن اتصال کار کند. در جهت خروجی معمولاً خوب کار می‌کند. ارائه‌دهنده اتصال را ترجمه می‌کند و طرف دور یک کلاینت عادی IPv4 می‌بیند. آنچه می‌شکند جهت مخالف است: میزبانی چیزی که انتظار IPv4 ورودیِ ناخواسته دارد. تفاوت در این است که کدام سمت گفتگو را آغاز می‌کند.

کدام سمت اتصال را آغاز می‌کند

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

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

یک درخواست خروجی را دنبال کنید

معماری در RFC 6333 هر دو سر را نام می‌برد. عنصر سمت مشتری B4 است که IPv4 را در IPv6 کپسوله می‌کند. عنصر سمت ارائه‌دهنده AFTR است که ترجمهٔ نشانی را انجام می‌دهد و بسته را به‌صورت IPv4 هدایت می‌کند.

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

سرور VPN یک اتصال عادی IPv4 از نشانی ترجمه‌شدهٔ ارائه‌دهنده دریافت می‌کند. به حالت DS-Lite، پورت ویژه یا هیچ آگاهی از این‌که شبکهٔ دسترسی مشتری فقط IPv6 است نیاز ندارد. این همان بخشی است که مردم از دست می‌دهند: طرف دور نمی‌تواند تشخیص دهد.

پیکربندی خود کلاینت هم به همان اندازه عادی است. به یک مسیر IPv4 سالم تا سرور نیاز دارد که B4 و AFTR فراهم می‌کنند، و به این نیاز دارد که نام میزبان سرور به یک نشانی IPv4 تبدیل شود.

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

اجرای سرور VPN روی IPv4 در خانه همان طرحی است که با نشانی‌دهی مشترک ارائه‌دهنده برخورد می‌کند. مترجم ارائه‌دهنده مالک نشانی عمومی و جدول نگاشت است و دلیلی ندارد برای یک مشترک نگاشت ورودی دائمی بسازد.

قاعدهٔ هدایت پورت روی روتر خانه نمی‌تواند AFTR را پیکربندی کند. این قاعده روی دستگاه محلی واقعی و درست است و هیچ چیز را در بالادست تغییر نمی‌دهد، به همین دلیل نشانه شبیه مشکلی در فایروال به نظر می‌رسد که از بین نمی‌رود.

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

پیش از تغییر طرح دسترسی، تشخیص بدهید

ابتدا حالت تأمین‌شده را تأیید کنید. پشتهٔ دوگانهٔ بومی، DS-Lite و شبکه‌ای فقط IPv6 که از سازوکار ترجمهٔ دیگری استفاده می‌کند سه آرایش متفاوت‌اند، و نام‌های بازاریابی ارائه‌دهنده همیشه با نام فنی مطابقت ندارند.

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

آن چهار پاسخ به فیلتر کردن، به پایان مهلت وضعیت ترجمه، به نقطهٔ پایانی نادرست یا به مدیریت اندازهٔ بسته اشاره می‌کنند. هیچ‌کدام با دیدن DS-Lite در صفحهٔ حساب روشن نمی‌شود.

تغییرات ارائه‌دهنده را دقیق بخوانید

یک تغییر حساب می‌تواند با اتصالی سالم هم‌زمان شود و در همان حال چند ویژگی را یک‌جا تغییر دهد. ثبت کنید کدام ویژگی تغییر کرده است، چون نام بستهٔ جدید توضیح فنی نیست.

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

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