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

از همان‌جا که کلاینت هست شروع کنید

پیش از دست زدن به سرور، به کلاینت نگاه کنید. ip -6 addr باید نشانی تونل از استخر را نشان دهد و ip -6 route باید پیشوند هل داده‌شده را نشان دهد که به دستگاه تونل اشاره می‌کند. وقتی نشانی هست ولی مسیر نیست، هل دادن غایب است یا کلاینت آن را نادیده گرفته. وقتی هیچ‌کدام نیست، سرور اصلاً چیزی تخصیص نداده است.

سپس بررسی کنید کلاینت درباره جهان بیرون چه فکر می‌کند. مسیر پیش‌فرض روی تونل همه ترافیک IPv6 را ادعا می‌کند، در حالی که مسیر برای 2000::/3 فقط یونیکست جهانی را ادعا می‌کند. هر دو می‌توانند درست باشند و به پرسش‌های متفاوتی درباره نشت پاسخ می‌دهند.

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

استخری را بررسی کنید که سرور واقعاً می‌تواند مسیریابی کند

سرور فقط می‌تواند از پیشوندی تخصیص دهد که واقعاً آن را کنترل می‌کند. اگر ISP یک /56 واگذار می‌کند، یک /64 را برای تونل رزرو کنید و بقیه را برای LAN بگذارید. جایی که ISP روی WAN فقط یک /64 تحویل می‌دهد و بیشتر مسیریابی نمی‌کند، پیشوند LAN را رها کنید و به تونل یک محدوده محلی یکتا بدهید و بپذیرید که کلاینت‌ها خروجی جهانی نخواهند داشت.

استخر و هل دادن به هم مربوط‌اند. server-ipv6 2001:db8:80:10::/64 نشانی‌ها را تخصیص می‌دهد و push "route-ipv6 2000::/3" به کلاینت‌ها می‌گوید چه چیزی را به تونل بفرستند. هل دادن 2000::/3 یونیکست جهانی را پوشش می‌دهد و محدوده‌های link-local و multicast را بیرون از تونل نگه می‌دارد.

پیشوند انتخاب‌شده را در سابقه استقرار بنویسید. کسی که دفعه بعد تحویل ISP را تغییر می‌دهد باید بداند تونل کدام /64 را اشغال کرده است.

فورواردینگ را برای خانواده دوم روشن کنید

فورواردینگ IPv4 به معنای فورواردینگ IPv6 نیست. net.ipv6.conf.all.forwarding=1 را تنظیم کنید و هر چیزی را که سیاست FORWARD مربوط به IPv4 از قبل اجازه می‌دهد بازتاب دهید. روی روتری که زنجیره FORWARD آن به‌طور پیش‌فرض دور می‌ریزد، مجموعه قواعد غایب دقیقاً مثل تونل مرده به نظر می‌رسد.

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

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

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

وقتی بالادست مسیریابی نمی‌کند به کشف همسایه پاسخ دهید

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

OpenVPN نشانی تخصیص‌یافته را به قلاب client-connect عرضه می‌کند، بنابراین ورودی‌ها می‌توانند به جای فهرستی که دستی نگه داشته می‌شود از استخر واقعی پیروی کنند. قلاب ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 را اضافه می‌کند و قلاب client-disconnect متناظر آن را حذف می‌کند. بدون حذف، جدول پروکسی کهنه می‌شود و کلاینت بعدی می‌تواند ورودی‌ای برای نشانی به ارث ببرد که هرگز نگرفته است. وضعیت را با ip -6 neigh show proxy تأیید کنید.

پروکسی را یک راه‌حل موقت بدانید. مسیر ایستا برای /64 تونل که به روتر نشانه رفته باشد از تغییر کلاینت‌ها جان سالم به در می‌برد و اصلاً به قلاب پوسته با دسترسی ویژه نیاز ندارد.

مسیر را به بیرون دنبال کنید، جهش به جهش

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

MTU تونل را زیر نظر داشته باشید، چون روترهای IPv6 در مسیر به جای شما قطعه‌بندی نمی‌کنند. MTU بیش از حد بزرگ به صورت خطای packet-too-big و TLS متوقف ظاهر می‌شود نه شکست تمیز. آن را صریح تنظیم کنید و با باری نزدیک به حد آزمون کنید.

مقالات مرتبط