قطع خروجی IPv6 پس از راه‌اندازی مجدد OpenVPN: مالکیت پیشوند را بررسی کنید
IPv6 پس از بازسازی تونل از کار می‌افتد. پیش از راه‌اندازی مجدد هر چیزی، مشخص کنید پیشوند تفویض‌شده، آدرس‌های کلاینت و مسیر بازگشت متعلق به کیست.
IPv6 درست در لحظه‌ای که OpenVPN راه‌اندازی مجدد می‌شود، دیگر ترافیک را عبور نمی‌دهد و IPv4 همچنان کار می‌کند. رابط تونل دوباره ساخته شد، و چیز دیگری که وضعیت IPv6 آن را مدیریت می‌کرد یا آدرس را از دست داد یا مسیری را از دست داد که پیشوند را قابل دسترس می‌کند. سه بخش جداگانه از وضعیت درگیر است و هر یک مالک متفاوتی دارد: پیشوند تفویض‌شدهٔ ارائه‌دهنده و عمر آن، آدرس‌هایی که به کلاینت‌های VPN داده می‌شود، و مسیر بالادستی که آن پیشوند کلاینت را به سرور بازمی‌گرداند. مالک هر یک را پیش از دست زدن به هیچ daemon مشخص کنید، زیرا راه‌اندازی مجدد daemon اشتباه مشکل را یک روز پنهان می‌کند و در اتصال بعدی بازمی‌گرداند.
سه بخش از وضعیت IPv6، سه مالک
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
یک آدرس با دامنهٔ جهانی درون تونل به‌تنهایی کافی نیست. روترهای بالادست همچنان باید آن پیشوند را به سمت سرور VPN بازگردانند، و این کار را به صرف این که سرور تصادفاً آدرسی از آن دارد انجام نمی‌دهند.
به همین دلیل کپی کردن یک /64 عمومی در استخر تونل نیز پرخطر است. پیشوندی که به سرور مسیریابی می‌شود با پیشوندی که بالادست آن را on-link می‌داند یکسان نیست، و کشف همسایه این شکاف را پر نمی‌کند.
پیش از تغییر هر چیزی وضعیت سرور را بخوانید
وضعیت را دو بار ثبت کنید، یک بار وقتی IPv6 کار می‌کند و یک بار پس از راه‌اندازی مجدد، سپس مقایسه کنید. نماهای فقط‌خواندنی کافی است و در پنجرهٔ نگهداری هیچ هزینه‌ای ندارد:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingبه دنبال سه تفاوت مشخص باشید: مسیری که ناپدید شده، آدرسی که به عمر منسوخ یا نامعتبر منتقل شده، و پیشوندی که پس از تفویض دوباره تغییر کرده در حالی که پیکربندی VPN هنوز پیشوند قدیمی را اعلام می‌کند.
اگر آدرس ناپدید شده اما پیشوند تغییر نکرده باشد، daemon که آن را تخصیص می‌دهد مدیریت رابط را متوقف کرده است. اگر پیشوند تغییر کرده اما آدرس‌ها نه، پیکربندی کلاینت کهنه است. این دو خرابی از دید مرورگر یکسان به نظر می‌رسند و هیچ وجه اشتراکی ندارند.
تصمیم بگیرید که آیا dhcpcd باید تونل را مدیریت کند
dhcpcd می‌تواند رابط‌ها را کشف کند و بخش‌هایی از پیشوند DHCPv6 را به رابط‌های پایین‌دست تفویض کند، و پیکربندی آن می‌تواند اهداف تفویض را صریحاً نام ببرد. بدون هدف صریح، رفتار مستند آن می‌تواند رابط‌های دیگر را درگیر کند، و این‌گونه است که تونل با آدرسی مواجه می‌شود که هیچ‌کس برنامه‌ریزی نکرده بود.
دو شرط باید شما را به این سمت سوق دهد که آدرس‌دهی ایستای تونل را به OpenVPN بسپارید: سرور در پیکربندی خود آدرس‌های ثابت را هل می‌دهد، و نام تونل در اتصال دوباره تغییر می‌کند. اگر هر دو برقرار باشد، تونل را عامدانه از daemon تفویض خارج کنید، با توضیحی که دلیل را می‌گوید.
اگر در عوض تفویض به تونل عامدانه است، مدیریت تغییر پیشوند را پیاده‌سازی کنید. این یعنی واکنش نشان دادن وقتی پیشوند تفویض‌شده یا عمر آن تغییر می‌کند، به‌روزرسانی پیشوند کلاینت اعلام‌شده از سوی سرور، و افزودن دوبارهٔ مسیر. حذف رابط در آن طراحی تنها مؤلفه‌ای را که از پیشوند جدید خبر دارد برمی‌دارد.
راه‌اندازی مجدد dhcpcd ممکن است ظاهراً مشکلات را حل کند چون وضعیت را از نو می‌سازد، اما پیکربندی رابط‌هایی را هم تازه یا لغو می‌کند که به آن فکر نمی‌کردید. آن بازیابی آن را به الزامی پس از هر راه‌اندازی مجدد VPN تبدیل نمی‌کند. شمارنده‌هایی را هم که به‌عنوان مدرک استفاده می‌کردید صفر می‌کند. بارگذاری مجدد هدفمند همان رابطی را که واقعاً تغییر دادید ترجیح دهید.
IPv6 را جدا از NAT مربوط به IPv4 اعتبارسنجی کنید
تأیید کنید که ارسال به جلو فعال است و مسیر بالادست به پیشوند واقعی کلاینت اشاره می‌کند، سپس یک اتصال IPv6 مجاز تازه برقرار کنید. جدول مسیریابی IPv6 خود کلاینت را هم بررسی کنید، چون کلاینتی که آدرس عمومی نشان می‌دهد ثابت نمی‌کند درخواستش از تونل استفاده کرده است.
پوشش IPv4 مشکلی متفاوت را حل می‌کند: مسیر بازگشت برای منابع خصوصی. برای پیشوند IPv6 پس‌گرفته‌شده هیچ کاری نمی‌کند و افزودن آن IPv6 را بازنمی‌گرداند.
با سابقهٔ مالکیت ببندید: کدام مؤلفه پیشوند را تفویض می‌کند، کدام آدرس‌های کلاینت را تخصیص می‌دهد، کدام مسیر بازگشت را نگه می‌دارد، و در اتصال دوباره برای هر یک چه رخ می‌دهد. چهار خط در یک runbook نفر بعدی را از راه‌اندازی مجدد سه daemon برای یافتن آن یکی که مهم بود نجات می‌دهد.