شبکه‌ای که فقط IPv6 دارد، VPN را پیش از شروع تونل می‌شکند

لپ‌تاپ به Wi-Fi یک همایش وصل می‌شود که فقط IPv6 توزیع می‌کند، کلاینت VPN می‌چرخد و شکست می‌خورد، و همان پروفایل یک ساعت پیش در هتلی کار می‌کرد. چیزی در اعتبارنامه‌ها تغییر نکرده است. آنچه تغییر کرده این است که کلاینت اکنون باید از میان شبکه‌ای که فقط IPv6 حمل می‌کند به مقصد IPv4 برسد، و هر کلاینتی نمی‌داند چگونه این کار را بکند.

همان پنج گامی را که بسته‌ها می‌پیمایند، بپیمایید.

گام 1: جست‌وجوی نام را ببینید

اگر پروفایل از نام میزبان استفاده می‌کند، نخستین پرسش این است که resolver چه برمی‌گرداند. dig AAAA vpn.example.com در شبکه‌ای که فقط IPv6 دارد یا یک رکورد واقعی AAAA برمی‌گرداند، یا رکوردی ساختگی از DNS64، یا هیچ. پاسخ ساختگی مقصد IPv4 را درون یک پیشوند ترجمه رمزگذاری می‌کند و تنها آنگاه کلاینتی که مقصد IPv6 ندارد می‌تواند به آن برسد. پروفایلی با نشانی IPv4 سخت‌کدشده هرگز تا اینجا نمی‌رسد، چون نامی برای ساختن وجود ندارد.

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

گام 2: ببینید کلاینت کدام خانواده را صدا زد

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

خانوادهٔ نشانی در جدول سوکت همان واقعیت است. نوار پیشرفت خلاصه‌ای است که شخص دیگری نوشته.

گام 3: ترجمه را از تونل جدا کنید

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

شکست ترجمه شبیه هرگز وصل نشدن است. شکست پوشش درونی شبیه وصل شدن و به هیچ جا نرسیدن است.

گام 4: همان پروفایل را در شبکه‌ای دیگر بیازمایید

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

گزارشی که می‌گوید VPN خراب است قابل اقدام نیست. گزارشی که می‌گوید فقط در دسترسی با فقط IPv6 شکست می‌خورد، گزارش باگ است.

گام 5: مسیر را درست کنید، نه تنظیمات امنیتی را

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

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