پیشوند شاخهٔ IPv6: iroute-ipv6 یا route-ipv6 روی سرور؟

دو دستور با نامی تقریباً یکسان در هر نمونهٔ کارآمد دیده می‌شوند، و کپی کردن یکی بدون دیگری تونلی می‌سازد که درست به نظر می‌رسد و پیشوند شاخه را بی‌صدا دور می‌ریزد. آن‌ها در دو سوی یک مرز کارهای متفاوتی انجام می‌دهند: یکی به هستهٔ سرور می‌آموزد که پیشوند کجا زندگی می‌کند، و دیگری به OpenVPN می‌آموزد که کدام مشتری احرازشده آن را حمل می‌کند. اگر هر دو درست باشند، پیشوند جاری می‌شود؛ اگر یکی درست باشد، بسته‌ها مسیر دارند اما صاحب ندارند.

دو دستور، دو کار متفاوت

route-ipv6 یک نصب مسیر معمولی است: سرور یک مسیر هسته اضافه می‌کند که پیشوند را به واسط تونل خود اشاره می‌دهد. iroute-ipv6 به بافتی مخصوص مشتری تعلق دارد و مالکیت داخلی را اعلام می‌کند، تا دیمن بداند ترافیک آن پیشوند باید به مشتری مشخصی فرستاده شود، نه به همتایی که یک مسیر هسته تصادفاً نام می‌برد.

یکی دربارهٔ جدول ارسال هسته است و دیگری دربارهٔ مدل مسیریابی داخلی دیمن. جدا نگه داشتن آن‌ها توضیح می‌دهد چرا پیکربندی‌ای که کامل به نظر می‌رسد باز هم می‌تواند پیشوند را دور بریزد. همچنین توضیح می‌دهد چرا همان شبکه در هر نمونهٔ کارآمد دو بار ظاهر می‌شود. هیچ‌کدام از دو خط زائد نیست.

در چیدمان سنتی userspace هر دو لازم‌اند و یکدیگر را کامل می‌کنند. مسیر هسته به‌تنهایی دیمن را از انتخاب همتا ناتوان می‌گذارد. iroute به‌تنهایی هسته را بدون راهی به تونل می‌گذارد. بیشتر سردرگمی دربارهٔ فایل‌های هر مشتری هم از همین‌جا می‌آید: فایل یک ورودی جدول مسیر نیست، و ورودی مسیر اعلامیهٔ مالکیت نیست.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

هر کدام کجا تعلق دارد

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

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

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

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

مشتری دیگر به چه چیزی نیاز دارد

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

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

فرستادن آن به همه انتخابی با پیامد است: آن‌گاه هر مشتری باور می‌کند که شاخه از طریق تونل در دسترس است، از جمله مشتریانی که هرگز نمی‌خواستید این دسترسی را به آن‌ها بدهید. اعلام در عمل تصمیمی دربارهٔ دسترسی است، هرچند دستور شبیه لوله‌کشی به نظر می‌رسد. مرجع گزینه‌های سرور مستند می‌کند iroute-ipv6 را به‌عنوان مالکیت مخصوص مشتری، و همین تمایز است که ارزش نگه داشتن دارد.

مسیر بازگشت روی دستگاه شاخه

مالکیت تنها وقتی کمک می‌کند که شاخه بسته‌ها را ارسال کند و LAN آن بداند چگونه پاسخ دهد. ارسال IPv6 را روی دستگاه شاخه فعال کنید و تأیید کنید که میزبان‌های LAN آن ترافیک استخر VPN را به سمت شاخه بازمی‌گردانند نه به سمت مسیر پیش‌فرضی که استخر را نمی‌شناسد.

آن مسیر بازگشت معادل IPv6 همان مشکل مسیر گمشده است که مردم با IPv4 به آن برمی‌خورند.

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

وقتی این جفت هنوز کافی نیست

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

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

و در پایان، دامنهٔ نشانی‌ها را به یاد داشته باشید: پیشوند محلی یکتایی مانند fd00:7a::/64 از نظر طراحی خصوصی است و چیزی دربارهٔ دسترس‌پذیری عمومی IPv6 نمی‌گوید. با آن مانند دسترسی داخلی رفتار کنید، و خروج به اینترنت را پرسشی جداگانه با سیاست خودش نگه دارید.