کلید قطع فقط IPv4 را مسدود می‌کند: چرا IPv6 همچنان خارج می‌شود

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

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

دو مجموعه قاعده، دو پیش‌فرض

در لینوکس، iptables و ip6tables دو جدول جدا با سیاست‌های جدا هستند. قرار دادن زنجیره‌های INPUT و OUTPUT جدول IPv4 روی DROP هیچ چیزی را در جدول IPv6 تغییر نمی‌دهد، جایی که پیش‌فرض معمولاً ACCEPT است. همین تقسیم در nftables هم وجود دارد، جایی که می‌توانید یک خانواده را بررسی کنید و ببینید فقط یکی از آن‌ها قواعد شما را حمل می‌کند. این عدم تقارن طبیعی است، و کل مسئله همین است.

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

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

پیکربندی رابط چه چیزی به شما می‌گوید

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

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

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

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

چرا یک جست‌وجو تمام ماجرا نیست

یک نام می‌تواند هم رکورد A و هم رکورد AAAA برگرداند، و برنامه‌ها همه به یک شکل انتخاب نمی‌کنند. ممکن است مرورگر وقتی شبکه IPv6 را ارائه می‌دهد آن را ترجیح دهد و در صورت شکست عقب‌نشینی کند، در حالی که یک همگام‌سازی پس‌زمینه یا برنامهٔ به‌روزرسانی از حل‌کننده و ترجیح خودش استفاده می‌کند. بنابراین یک آزمون موفق روی IPv4 یک مسیر را اثبات می‌کند، نه سیاست را.

گذارهای شبکه هم پاسخ را تغییر می‌دهند. پیوستن به یک شبکهٔ Wi-Fi دیگر، بیدار شدن از خواب یا تغییر به شبکهٔ موبایل می‌تواند پیشوند IPv6 جدیدی به دستگاه بدهد، و سیاستی که در LAN دفتر کافی به نظر می‌رسید ممکن است آن را پوشش ندهد.

حالتی را آزمایش کنید که تونل قطع است

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

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

هر دو خانواده باید بسته شکست بخورند. اگر درخواست IPv4 از مهلت بگذرد و درخواست IPv6 کد وضعیت برگرداند، سیاست ناقص است، و هر اندازه دوباره آزمایش کردن تونل آن را تغییر نخواهد داد.

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