تقسیم /64 شما IPv6 را به کلاینت‌های VPN مسیریابی نمی‌کند

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

افسانه: بخشی از /64 شما از قبل قابل دسترسی است

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

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

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

تحویل روی لینک واقعاً چه می‌خواهد

وقتی شبکه بالادست کل /64 را روی لینک فیزیکی می‌داند، هر آدرس مقصد را با کشف همسایه حل می‌کند. یک درخواست روی آن لینک می‌فرستد و انتظار دارد مالک آدرس پاسخ دهد. کلاینت VPN پشت تونل روی آن لینک نیست و نمی‌تواند پاسخ دهد، بنابراین درخواست بی‌پاسخ می‌ماند و بسته دور انداخته می‌شود.

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

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

تحویل مسیریابی‌شده چه می‌خواهد

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

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

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

دو مسیر مستقل که باید درست شوند

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

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

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

ترافیک کنترلی که IPv6 به آن وابسته است را تحت هر سیاستی که اعمال می‌کنید فعال نگه دارید. پیام‌های Packet Too Big قربانی کلاسیک فایروالی هستند که فقط TCP و UDP را مجاز می‌کند، و دور انداختن آن‌ها اتصالاتی تولید می‌کند که برقرار می‌شوند و سپس در انتقال‌های بزرگ‌تر گیر می‌کنند.

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

طراحی را ثبت کنید تا بازسازی آن را بازتولید کند

سه شیء را جداگانه بنویسید: تخصیص کلاینت، مسیر مقصد کلاینت و روش تحویل تخصیص از سوی شبکه بالادست. خواننده‌ای که هر سه را دارد می‌تواند استقرار را بازسازی کند؛ خواننده‌ای که فقط تنظیم استخر را دارد باگ اصلی را بازتولید خواهد کرد.

سپس جهت برگشت را صراحتاً آزمایش کنید، با بسته‌ای که باید از بیرون برگردد. راهنمای openvpn(8) گزینه‌های server-ipv6 و redirect را پوشش می‌دهد، و تأیید مسیریابی ارائه‌دهنده شما نیمی را پوشش می‌دهد که راهنما نمی‌تواند.