تفویض پیشوند IPv6 از طریق VPN سایت‌به‌سایت: فهرست بررسی
بررسی‌هایی برای مسیریابی پیشوند IPv6 تفویض‌شده از طریق VPN سایت‌به‌سایت: نقشه پیشوندها، انتخابگرهای ترافیک، ارسال، MTU، مسیر بازگشت و شماره‌گذاری مجدد.
بالا آوردن تونل نیمهٔ آسان ماجراست. دیده‌ام پیوندی میان دو سایت روزها برقرار می‌ماند ولی هر میزبان در LAN دور فقط سکوت می‌گرفت، چون پیشوند تفویض‌شده پشت آن دروازه روی یک واسط پیکربندی شده بود اما هرگز به داخل تونل مسیریابی نشده بود. نشانی‌های تونل در تمام این مدت به پینگ پاسخ می‌دادند و دقیقاً همین باعث شد کسی به پیشوند نگاه نکند. این ترتیبی است که وقتی یک پیشوند IPv6 تفویض‌شده باید از VPN سایت عبور کند بررسی می‌کنم: نقشهٔ پیشوندها، انتخابگرهای ترافیک، ارسال و دیوار آتش، و سپس مسیر بازگشت.
پیش از دست زدن به تونل، نقشهٔ پیشوندها را بنویسید
تفویض پیشوند یک بلوک را به مسیریابی می‌دهد که آن را درخواست کرده است. این کار مسیری روی همتا نصب نمی‌کند، آن بلوک را روی پیوند گسترش نمی‌دهد و به دروازهٔ دور نمی‌گوید چه چیزی پشت مسیریاب درخواست‌کننده است. این سه کار با شماست و جایشان در یک طرح نشانی پیش از تغییر هر فایل پیکربندی است.
برای هر سایت پیشوند تفویض‌شده، /64ای که واقعاً در LAN استفاده می‌شود، نشانی‌های تونل و مالک هر مسیر را ثبت کنید. ارائه‌دهنده 2001:db8:a1::/56 را به سایت A تفویض می‌کند که 2001:db8:a1:10::/64 را در LAN خود سرو می‌کند؛ سایت B هم 2001:db8:b2::/64 را نگه می‌دارد. اگر سایت A فقط همان یک /64 را سرو می‌کند، هر دو سر باید 2001:db8:a1:10::/64 را نام ببرند نه کل /56 را.
دو اشتباه تقریباً هر بار ظاهر می‌شوند. یکی اینکه پیشوند دور را روی پیوند فرض کنیم، آن را پل بزنیم یا روی واسط تونل بگذاریم تا دروازه به درخواست همسایه برای میزبان‌هایی پاسخ دهد که به آن‌ها نمی‌رسد. دیگری اینکه کل /56 را اعلام کنیم در حالی که فقط یک /64 پیکربندی شده است: جدول مسیریابی ادعا می‌کند بلوک در دسترس است و بیشتر نشانی‌ها در سیاه‌چاله می‌افتند.
انتخابگرهای ترافیک دو سر را با مسیرها هم‌خوان کنید
IKEv2 و WireGuard هر دو ترافیک ناسازگار را رد می‌کنند، آن‌قدر بی‌صدا که تونل هنوز سالم به نظر می‌رسد.
در strongSwan انتخابگرها صریح‌اند. در سایت A:
conn a-to-b
left=2001:db8:ff::1
leftsubnet=2001:db8:a1:10::/64
right=2001:db8:ff::2
rightsubnet=2001:db8:b2::/64
auto=startconn سایت B دو زیرشبکه را آینه می‌کند. وقتی ناسازگار باشند، پاسخ‌دهنده CHILD_SA را با TS_UNACCEPTABLE رد می‌کند، پس SA فرزند هرگز بالا نمی‌آید هرچند IKE_SA بالا آمده باشد. در هر دو سو زیرشبکهٔ پیکربندی‌شده باید برابر چیزی باشد که هستهٔ محلی به سمت تونل مسیریابی می‌کند.
WireGuard همان اطلاعات را در AllowedIPs حمل می‌کند، با یک پیچ: AllowedIPs هم فیلتر مبدأ در دریافت است و هم مسیر در ارسال. اگر مدخل همتای سایت B برای سایت A نشانی 2001:db8:a1:10::/64 را جا بیندازد، بسته‌های سایت A با دست‌دهی معتبر می‌رسند و به‌عنوان غیرمجاز دور ریخته می‌شوند. این الگوی آشنا را می‌سازد: دست‌دهی مدام تازه می‌شود ولی هیچ پاسخی بیرون نمی‌رود. دو سر را با wg show wg0 allowed-ips مقایسه کنید. هر بار تفویض تغییر کرد این فهرست را دوباره بررسی کنید؛ یک /64 کهنه نشست را بالا نگه می‌دارد و پیشوند جدید را دسترس‌ناپذیر.
اول ارسال، دیوار آتش و MTU را کنار بگذارید
پیش از خواندن یک خط گزارش دیگر، تأیید کنید دروازه‌ها اصلاً ارسال می‌کنند. sysctl net.ipv6.conf.all.forwarding باید روی هر دو 1 برگرداند، و روی واسط‌های تونل و LAN هم اعمال شود. یک تله همراه آن است: وقتی ارسال روشن شد، واسطی با accept_ra=1 دیگر اعلان‌های مسیریاب ارائه‌دهنده را نمی‌پذیرد، پس دستگاه ممکن است مسیر پیش‌فرض بالادست را از دست بدهد در حالی که داخل تونل بی‌نقص مسیریابی می‌کند. جایی که هنوز به RA ارائه‌دهنده نیاز است accept_ra=2 بگذارید.
سپس قواعد دیوار آتش باید پیشوند را در هر دو جهت اجازه دهند و ICMPv6 باید زنده بماند: کشف همسایه، بستهٔ بسیار بزرگ و مقصد دسترس‌ناپذیر اختیاری نیستند. اگر دورشان بیندازید، کشف MTU مسیر می‌شکند و اتصال‌هایی می‌گیرید که باز می‌شوند و بعد در نخستین پاسخ بزرگ گیر می‌کنند. حداقلی از دو قاعده چنین است:
nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } acceptMTU پشت این است. تونل MTU قابل استفاده را زیر 1500 کوچک می‌کند و IPv6 می‌خواهد هر پیوند دست‌کم 1280 را حمل کند. پینگ‌های کوچک عبور می‌کنند، نشست SSH روی یک انفجار بزرگ منجمد می‌شود، و /proc/net/snmp6 پیام‌های بستهٔ بسیار بزرگ را نشان می‌دهد که هرگز برنمی‌گردند. MTU تونل را صریح تنظیم کنید یا MSS پروتکل TCP را در جدول mangle محدود کنید و بگذارید ICMPv6ای که MTU کوچک‌تر را گزارش می‌کند برگردد.
مسیر بازگشت را بیازمایید، نه نشانی تونل را
شکستی که بیشترین زمان را می‌بلعد مسیریابی یک‌طرفه است. هر دروازه پیشوند دور را به تونل مسیریابی می‌کند، اما میزبان‌ها از دروازهٔ پیش‌فرض خودشان پاسخ می‌دهند چون /64شان همان‌جاست. رساندن بسته به مقصد فقط نیمی از راه است.
| What you see | Likely cause | First check |
|---|---|---|
| Tunnel up, every host silent | remote prefix not routed into the tunnel | ip -6 route get on both gateways |
| Handshake renews, no replies | source prefix missing from selectors or AllowedIPs | ipsec statusall, wg show allowed-ips |
| Small pings pass, transfers stall | MTU or ICMPv6 packet-too-big filtered | /proc/net/snmp6 counters |
| Old prefix still works | stale /64 left in routes or selectors | delegation lease and route table |
دو فرمان بیشتر آن را روشن می‌کند. در سایت A، ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 نشان می‌دهد پاسخی از آن مبدأ کدام واسط را به کار می‌برد؛ بررسی آینه‌ای را در سایت B انجام دهید. سپس ترافیک را از یک میزبان تولید کنید نه از دروازه و شمارنده‌ها را در دو سر مقایسه کنید.
اگر درخواست همسایه برای پیشوند دور روی تونل ظاهر شود، آن پیشوند جایی روی پیوند است که نباید باشد؛ این را پیش از دست‌کاری مسیرها درست کنید. Proxy NDP مواردی را پوشش می‌دهد که پل‌زدن واقعاً لازم است، و جایگزین مسیر نیست.
برای تغییر پیشوند زیر پای خود برنامه داشته باشید
تفویض پیشوند یک اجاره میان مسیریاب تفویض‌دهنده و درخواست‌کننده است و تمدید می‌تواند بلوک دیگری برگرداند: /56 متفاوت پس از مهاجرت ارائه‌دهنده، یا اجاره‌ای کوتاه‌تر از مدت بالا بودن تونل. هر جایی که پیشوند قدیم را نام می‌برد یک‌جا کهنه می‌شود: مسیرها، انتخابگرها، AllowedIPs، قواعد دیوار آتش، رکوردهای DNS و هر پایشی که نشانی‌های عینی را سخت‌کد کرده باشد. جریان پیام در RFC 8415.
جایی که انتظار می‌رود پیشوند جابه‌جا شود، طرح نشانی درونی‌ای نگه دارید که به آن وابسته نباشد و در مرز ترجمه کنید. NPTv6 گزینهٔ بی‌حالت است و سیاست درونی را خوانا نگه می‌دارد، اما این ترجمهٔ پیشوند است نه لایهٔ جادویی: مرزهای /64 باید هم‌تراز شوند، جمع‌های کنترلی اصلاح می‌شوند و برنامه‌هایی که نشانی‌های عینی را جاسازی می‌کنند هنوز می‌شکنند. اگر نشانی‌های ارائه‌دهنده را سرتاسر نگه می‌دارید، رفتار اجاره و رویهٔ تغییر را در طرح نشانی ثبت کنید.
با آزمونی تمام کنید که در برابر زمان دوام بیاورد: میزبانی مجاز در هر LAN به سرویسی در LAN دیگر می‌رسد، پاسخ از تونل برمی‌گردد و همان جفت پس از راه‌اندازی دوبارهٔ تونل و تمدید تفویض هم کار می‌کند. اگر بخش آخر شکست بخورد، طراحی به حالتی وابسته است که یک هفته دوام نمی‌آورد.