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

نقطه بررسی یک: اتصالی که از قبل کار می‌کند

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

مخزن، توپولوژی و مسیرهای فشرده‌شده‌ای را که از قبل به آن‌ها تکیه دارید یادداشت کنید. کار IPv6 آن پیکربندی را گسترش می‌دهد؛ جایگزینش نمی‌شود.

نقطه بررسی دو: پیشوندهای درونی را انتخاب کنید

یک ULA /48 برای سایت انتخاب کنید و دو /64 از آن ببرید: یکی برای کلاینت‌های تونل، یکی برای بخش LAN که بار کاری IPv6 را در خود دارد. شناسه جهانی 40 بیتی را تولید کنید، نه اینکه یک پیشوند نمونه را کپی کنید، و هر دو زیرشبکه را با هر شبکه‌ای که سایت از قبل مسیریابی می‌کند بسنجید:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

دو /64 مستقل مانع می‌شوند که مخزن کلاینت از بخش LAN بریده شود، و این بعداً هنگام نوشتن مسیر بازگشت مهم است. مقادیر بالا یک نمونه کارشده است، نه پیشوندی برای استفاده دوباره.

نقطه بررسی سه: کمک‌کننده و فشار مسیر را بیفزایید

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

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

اولی کمک‌کننده‌ای راحت است که رابط و مخزن کلاینت را تنظیم می‌کند. دومی مقصد LAN را که کلاینت باید به آن برسد نام می‌برد. دادن نشانی IPv6 به کلاینت نمی‌گوید چه شبکه‌هایی پشت سرور هست، پس هر دو خط لازم است.

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

نقطه بررسی چهار: ارسال رو به جلو و مسیر پاسخ

ارسال رو به جلو IPv6 را روی سرور از طریق مالک پیکربندی خود سیستم روشن کنید، نه با یک نوشتن یک‌باره در زمان اجرا که فراموش خواهید کرد. شکل زمان اجرا برای آزمون سریع سودمند است. پیکربندی پایدار جای خود را در فایل drop-in دارد که مالک شبکه توزیع می‌خواند:

sysctl -w net.ipv6.conf.all.forwarding=1

ارسال رو به جلو رفتار IPv6 میزبان را فراتر از مسیریابی بسته‌ها تغییر می‌دهد. میزبانی که به‌عنوان کلاینت آگهی‌های مسیریاب را می‌پذیرفت، به همان شکل که ارسال رو به جلو را آغاز کند از آن دست می‌کشد. پس ماشینی که پیوند IPv6 آن به RA وابسته است به طرحی صریح برای آن پیوند نیاز دارد.

سپس به LAN مسیری بازگشتی به مخزن تونل بدهید. دروازه IPv6 بار کاری، مسیریاب LAN است نه سرور VPN، پس مسیر روی همان مسیریاب است و به نشانی LAN سرور اشاره می‌کند:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

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

نقطه بررسی پنج: کلاینت را بخوانید، سپس بیازمایید

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

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

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

خود برنامه را به نوبت روی هر خانواده بیازمایید، سپس پس از اتصال دوباره و پس از راه‌اندازی دوباره میزبان تکرار کنید. مسیر یا sysctl که فقط تا راه‌اندازی دوباره دوام می‌آورد آزمون است، نه طراحی.

رکورد AAAA را تنها زمانی منتشر کنید که مسیر IPv6 سرتاسر پاسخ دهد. DNS که از طریق IPv4 پرسیده شود باز هم می‌تواند نشانی IPv6 برگرداند، پس نام قابل‌حل شاهدی بر شنیدن چیزی نیست. راهنمای RFC 4193 برای ULA تولید شناسه جهانی را پوشش می‌دهد که این پیشوندها را مال شما می‌کند نه یک کپی.

مقالات مرتبط