آیا ترافیک IPv6 باید از VPN عبور کند یا مستقیم؟
تصمیم بگیرید آیا ::/0 به داخل تونل تعلق دارد، با سه شرط: پشتیبانی خروجی، دسترسی‌پذیری نقطه پایانی و شبکه‌های فقط محلی.
ماه گذشته دو نفر از من نتایج متضاد خواستند: یکی می‌خواست IPv6 زیر پوشش VPN باشد، دیگری می‌خواست چاپگر دفتر به کار ادامه دهد. یک مسیر واحد ::/0 نمی‌تواند هر دو را به‌تنهایی فراهم کند. اینکه آن مسیر به داخل تونل تعلق دارد یا نه به سه شرط بستگی دارد، و شرط اول آن را برای بیشتر خروجی‌های تجاری کنار می‌گذارد. اگر خروجی IPv6 را حمل نکند، مسیریابی مسیر پیش‌فرض به داخل آن ترافیک شما را در تونلی پنهان میکند که جایی برای فرستادن آن ندارد.
سه شرط پاسخ را تعیین می‌کنند
مسیر پیش‌فرض یک خط است، ::/0، و با هر مقصد IPv6 که مسیر دقیق‌تری ندارد مطابقت دارد (RFC 4291). نصب آن آسان است. تصمیم درباره اینکه باید این کار را بکنید یا نه به سه شرط برمی‌گردد.
شرط اول: خروجی‌ای که به آن وصل می‌شوید IPv6 فعال دارد و آماده است آن را هدایت کند. شرط دوم: کلاینت شما می‌تواند مسیری تا نقطه پایانی تونل نگه دارد، که معمولاً داخل محدوده‌ای است که می‌خواهید مسیریابی کنید. شرط سوم: می‌توانید مقصدهای IPv6 محلی را که باید بیرون از تونل بمانند نام ببرید.
هر شرط به روش خودش شکست می‌خورد، و به همین دلیل حدس زدن یک شب کامل هزینه دارد. شرط اولِ شکست‌خورده سکوت و جدول مسیریابی به شما می‌دهد که درست به نظر می‌رسد. شرط دومِ شکست‌خورده دست‌دادن را چند ثانیه پس از شروع می‌کشد. شرط سومِ شکست‌خورده یک تونل فعال و همکاری ناراضی کنار چاپگر باقی می‌گذارد.
| What you see | Decision |
|---|---|
| Exit answers IPv6 probes, no local IPv6 devices to protect | Route ::/0 into the tunnel |
| Exit answers IPv6 probes, printer or NAS reachable by a global address | Route ::/0, then give those prefixes a route of their own |
| Exit is IPv4-only inside the tunnel | Do not route ::/0; block IPv6 on the client |
Endpoint is reached over IPv6 and sits inside ::/0 | Install a host route for the endpoint first |
آیا خروجی واقعاً IPv6 را حمل میکند؟
یک رابط تونل با نشانی IPv6 هیچ چیزی درباره طرف دیگر ثابت نمی‌کند. بسیاری از پروفایل‌های تجاری در داخل فقط IPv4 هستند: سرور به شما نشانی v4 می‌دهد و بقیه را دور می‌ریزد. یک مسیر پیش‌فرض از AllowedIPs روی آن نصب کنید و هسته با خوشحالی IPv6 را به رابطی می‌فرستد که همتای آن هرگز آن را نمی‌بیند.
از کلاینت آزمایش کنید در حالی که تونل فعال است. ping -6 -c 3 2001:4860:4860::8888 و ip -6 route get 2001:4860:4860::8888 به پرسش‌های متفاوتی پاسخ می‌دهند: اینکه پاسخ برمی‌گردد یا نه، و اینکه هسته کدام دستگاه را انتخاب کرده است. وقتی دومی تونل شما را نام می‌برد و اولی چیزی برنمی‌گرداند، مشکل در خروجی است نه در مسیر.
اگر خودتان خروجی را اداره می‌کنید، آزمایش کلاینت می‌تواند بگذرد و مسیر باز هم به بن‌بست برسد. تأیید کنید که net.ipv6.conf.all.forwarding=1 روی دروازه تنظیم است و فایروال آن بسته‌های هدایت‌شده از تونل را می‌پذیرد. بسته‌ای که به‌درستی به خروجی‌ای مسیریابی شده باشد که از بازپخش امتناع میکند، از سمت کلاینت دقیقاً مانند یک باگ مسیریابی به نظر می‌رسد.
آیا کلاینت می‌تواند مسیر خود تا نقطه پایانی را نگه دارد؟
این همان موردی است که مرا روی لپ‌تاپی با نقطه پایانی WireGuard که فقط IPv6 دارد گیر انداخت. نشانی نقطه پایانی یک نشانی جهانی معمولی است، پس داخل ::/0 قرار می‌گیرد. کل پیشوند را به رابط مسیریابی کنید و بسته‌های دست‌دادن خودشان را به داخل تونلی می‌رانند که هنوز در تلاش برای ساختن آن هستند. تونل هرگز بالا نمی‌آید، و هیچ چیز در خروجی کلاینت نمی‌گوید چرا.
wg-quick روی لینوکس این را مدیریت میکند. از AllowedIPs مسیرها را استخراج میکند، آن‌ها را در جدول خودش نصب میکند و یک قاعده سیاست اضافه میکند تا ترافیک به نقطه پایانی ابتدا از جدول اصلی حل شود: قاعده suppress_prefixlength 0 که در ip -6 rule پیدا می‌کنید. به همین دلیل wg-quick up موفق می‌شود جایی که ip -6 route add default dev wg0 دست‌نویس شما را قطع میکند.
هر دو حالت را با ip -6 route get <endpoint-v6> بررسی کنید، پیش و پس از بالا آوردن تونل. اگر پاسخ به دستگاه تونل شما تغییر کند، مسیری را که تونل لازم دارد حذف کرده‌اید. وقتی مسیرها را خودتان می‌نویسید، یک مسیر میزبان برای نقطه پایانی از طریق دروازه اصلی اضافه کنید، یا از طریق IPv4 به نقطه پایانی وصل شوید و IPv6 را به بار واگذار کنید.
چه چیزی باید بیرون از تونل بماند؟
مسیرهای دقیق‌تر بر پیش‌فرض پیروز می‌شوند، پس یک پیشوند روی پیوند یا محدوده ULA با مسیر خودش بدون تلاش اضافی به کار ادامه می‌دهد. این دلیل خاموشی است که بسیاری از پیکربندی‌های IPv4 با تونل کامل زنده می‌مانند: پیشوندهای LAN از پیش‌فرض دقیق‌ترند و هرگز به تونل وارد نمی‌شوند.
این می‌شکند وقتی یک دستگاه محلی از طریق نشانی جهانی در دسترس است، که برای چاپگری که همان روتر پیشوند عمومی به آن داده، یک NAS یا یک تلویزیون طبیعی است. آن نشانی‌ها با ::/0 مطابقت دارند و با هیچ چیز دیگر، پس همراه با بقیه به تونل منتقل می‌شوند و ناپدید می‌گردند.
بر اساس مقصد تصمیم بگیرید، نه بر اساس پروتکل. اگر دو یا سه میزبان محلی مهم‌اند، به پیشوندهایشان مسیری از رابط فیزیکی به بیرون بدهید، یا آن‌ها را از مجموعه مذاکره‌شده حذف کنید. اگر فهرست همچنان رشد میکند، پاسخ صادقانه تونل‌سازی تقسیمی برای IPv6 با فهرست استثنای نوشته‌شده است، نه یک پیش‌فرض که مدام وصله می‌زنید.
اگر پاسخ نه است، مسدودش کنید
بی‌مسیر گذاشتن IPv6 همان رها کردن آن نیست. میزبانی که پیش‌فرض IPv6 فعال دارد همچنان از آن استفاده میکند در حالی که تونل IPv4 را حمل میکند، پس ترافیک کنار VPN خارج می‌شود و هر سرویسی که IPv6 را ترجیح می‌دهد نشانی واقعی شما را می‌بیند. این یک نشت است، نه تونل تقسیمی.
یکی را انتخاب کنید و بنویسید کدام را انتخاب کردید. مسیر پیش‌فرض را مسیریابی کنید و بده‌بستان‌های بالا را بپذیرید، یا IPv6 را برای مدت تونل غیرفعال کنید. حذف پیشوند از AllowedIPs به‌تنهایی کافی نیست، چون سیستم‌عامل پیش‌فرض خودش را نگه می‌دارد. روی لینوکس نسخه خام sysctl -w net.ipv6.conf.all.disable_ipv6=1 است؛ نسخه دقیق‌تر IPv6 را با یک قاعده فایروال بیرون از تونل می‌اندازد. کلاینت‌های تلفن یک کلید صریح مسدودسازی IPv6 دارند که همین کار را میکند.
آن را مانند یک نشت بررسی کنید
تونل را بالا بیاورید و وضعیت را بخوانید، نه اینکه به کلید اعتماد کنید. ip -6 route show default باید یک پیش‌فرض نشان دهد، و ip -6 route get برای مقصدی بیرون از LAN شما باید دستگاه تونل را نام ببرد. هر دو را پس از قطع اتصال تکرار کنید: پیش‌فرضی که از تونل جان سالم به در می‌برد همان باگی است که دنبالش بودید.
سپس جهت دیگر را آزمایش کنید. از میزبانی در شبکه محلی، از طریق نشانی IPv6 محلی‌اش به کلاینت برسید. اگر این از کار بیفتد، شرط سوم هرگز برآورده نشده بود، هرچه جدول مسیریابی آن زمان ادعا می‌کرد.
نتیجه را جایی بنویسید که نفر بعدی پیدایش کند: کدام پیشوندها محلی می‌مانند، چرا، و کلاینت پس از قطع اتصال چه میکند. دو خط در یک runbook مهندس بعدی را از کشف دوباره حلقه نقطه پایانی در نیمه‌شب نجات می‌دهد.