IPv6 را برای رفع نشت VPN خاموش کنیم؟ بهتر است سیاست را تعیین کنید
نشانی link-local نشت نیست و مسیر سراسری IPv6 هم نشت نیست. نخست میان مسدود کردن، حمل کردن و رها کردن یکی را برگزینید.
نشانی‌ای از محدوده IPv6 در صفحه آزمایش دیده می‌شود، تونل آشکارا آن را حمل نمی‌کند، و رایج‌ترین توصیه اینترنت این است که IPv6 را همه‌جا خاموش کنید. آن فرمان واقعاً پنل را ساکت می‌کند. اما پروتکلی را هم حذف می‌کند که شبکه دسترسی ممکن است به آن وابسته باشد، و شما را بی‌آنکه بدانید نشانی نشت واقعی بوده، نشانی رابط link-local بوده یا یک resolver که کارش را می‌کند، رها می‌کند. سه شرط کنترل درست را تعیین می‌کند و تنها یکی از آن‌ها به مسدودسازی می‌رسد.
مشخص کنید ابزار واقعاً چه چیزی را اندازه گرفته است
شایع‌ترین هشدار نادرست نشانی link-local است که با fe80: آغاز می‌شود و روی هر رابط دارای توان IPv6 وجود دارد، بی‌آنکه مهم باشد ماشین از طریق IPv6 به اینترنت می‌رسد یا نه. در فهرست رابط‌ها و در برخی تشخیص‌های برنامه دیده می‌شود و هیچ چیزی درباره مسیر ترافیک شما نمی‌گوید.
هشدار نادرست دوم نشانی محلی یکتا در fc00::/7 است که محدوده‌ای خصوصی و درون شبکه است. ابزاری که هر نشانی میزبان را چاپ می‌کند آن را با خوشحالی کنار نشانی عمومی فهرست می‌کند. هر کس شتاب‌زده بخواند آن را نشت می‌نامد و بعد یک ساعت را صرف مشکلی می‌کند که وجود ندارد.
سومی اصلاً هشدار نادرست نیست. نشانی سراسری که بیرون از تونل به اینترنت می‌رسد همان نشت واقعی است و ارزش دارد پیش از هر تصمیمی اندازه‌گیری شود:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coاگر فرمان نخست نشانی سراسری چاپ کند و سومی نشانی IPv6 عمومی‌ای برگرداند که مال تونل نیست، مسیر واقعی بیرون از تونل دارید. اگر نخست چیزی جز ورودی‌های link-local چاپ نکند، هرگز نشتی برای رفع وجود نداشته است.
سه شرط کنترل را تعیین می‌کند
تصمیم «IPv6 خوب» یا «IPv6 بد» نیست. تصمیم این است که در کدام یک از سه وضعیت هستید، و هر یک پاسخ درست متفاوتی با هزینه متفاوت دارد اگر اشتباه کنید.
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
ردیف نخست همان چیزی است که مردم معمولاً منظورشان است و مشروع است. کارخواهی که خروجی‌اش پشتیبانی IPv6 ندارد نباید ترافیک بومی IPv6 میزبان را بی‌صدا بیرون بفرستد، چون همان نشت مستند پشته دوگانه است. نکته این است که آن را به‌عنوان سیاستی اعلام‌شده مسدود کنید، نه اینکه پروتکلی را در هسته خاموش کنید. نتیجه دیدنی یکسان است و فقط یکی از آن دو را می‌توان بعداً بازبینی کرد.
ردیف سوم جایی است که توصیه یک‌کلی فعالانه زیان‌بار می‌شود. اپراتورهای همراه و برخی اتصال‌های خانگی شبکه‌های IPv6-only را با ترجمه برای مقصدهای IPv4 اداره می‌کنند. IPv6 را آنجا بردارید و تنها حمل‌ونقلی را که شبکه عرضه می‌کند برمی‌دارید، که قطعی بسیار بدتر از آنچه عیب‌یابی می‌کردید پدید می‌آورد.
اگر خروجی IPv6 ندارد، عمداً مسدودش کنید
سازوکار خود کارخواه را ترجیح دهید، چون دقیقاً تا وقتی تونل بالاست اعمال می‌شود و با افتادن آن بازمی‌گردد. OpenVPN گزینه‌ای برای این دارد، و iptables قاعده‌ای هم‌ارز برای دیگر کارخواهان دارد:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableدستور به پروفایل تعلق دارد؛ قاعده به دیوار آتشی که می‌توانید بازبینی و حذفش کنید. هر دو بسته شکست می‌خورند، که همان چیزی است که می‌خواهید، و هر دو در تفاوت پیکربندی دیده می‌شوند، چیزی که sysctl هسته مدفون در اسکریپت راه‌اندازی نیست.
بنویسید چرا آنجاست. قاعده مسدودسازی بی‌توضیح را نفر بعدی که IPv6 را برای چیز نامرتبطی لازم دارد حذف می‌کند و بعد نشت بی‌صدا بازمی‌گردد.
اگر خروجی IPv6 را حمل می‌کند، مسیریابی‌اش کنید و هر دو خانواده را بیازمایید
حمل IPv6 پاسخ بهتر است وقتی سرور پشتیبانی می‌کند و چندان سخت‌تر نیست. شرط این است که رابط تونل نشانی‌ای در آن خانواده داشته باشد و مسیر پیش‌فرض آن به داخل تونل اشاره کند نه به بیرون رابط فیزیکی:
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.coجست‌وجوی مسیر آزمون قاطع است: اگر رابط تونل را نام ببرد، ترافیک IPv6 حمل می‌شود. سپس دو فراخوان curl تأیید می‌کنند هر خانواده چه می‌بیند، و مقایسه آن‌ها راه اثبات این است که هر دو مسیر اکنون از یک خروجی بیرون می‌روند.
روی یک اتصال موفق توقف نکنید. تونل را دوباره وصل کنید و باز بررسی کنید، چون مسیر IPv6 هل‌داده‌شده ممکن است در بازبرقراری از دست برود اگر سرور آن را فقط در پیکربندی آغازین بفرستد. سپس یک مقصد استثناشده را بررسی کنید، چون قواعد تونل تقسیم‌شده جایی است که دو خانواده بیشترین اختلاف را دارند.
اگر شبکه دسترسی فقط IPv6 است، رهایش کنید
برخی شبکه‌ها فقط IPv6 می‌دهند و انتظار دارند دستگاه از طریق سازوکار ترجمه در سمت اپراتور به سرویس‌های IPv4 برسد. خاموش کردن IPv6 روی چنین ماشینی بهبود امنیتی نیست؛ تنها مسیر به هر چیزی را حذف می‌کند. این قطعی‌ای است که خودتان به خاطر نتیجه آزمایشی که هیچ‌کس لازم نداشت بر خود تحمیل می‌کنید.
نشانه اشتباه کردن در اینجا ویژه و ناخوشایند است: تونل برقرار می‌شود، حل نام کار می‌کند و هیچ چیزی بارگذاری نمی‌شود. اگر این را پس از تغییر IPv6 دیدید، بی‌درنگ تنظیم را برگردانید و تشخیص را جای دیگری ادامه دهید.
هر چه برگزینید، تصمیم را در پروفایل یا دیوار آتش صریح نگه دارید، آن را به آنچه خروجی واقعاً پشتیبانی می‌کند ببندید و رفتار پشته دوگانه‌ای را که بحث پشته دوگانه RFC 7359 توصیف می‌کند یادداشت کنید. مسدودسازی اعلام‌شده سیاست است. پروتکل خاموش‌شده راه‌حلی موقت است که هیچ‌کس نمی‌تواند حسابرسی‌اش کند، و از صفحه آزمایش یکسان به نظر می‌رسند.