مسیریابی IPv6 بین دو سایت از طریق VPN موجود

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

وقتی پیشوند IPv6 را به تونلی میان دو سایت اضافه می‌کنید، بسته آن‌گونه که نمودار القا می‌کند حرکت نمی‌کند۔ دروازه محلی کل بسته IPv6 را برمی‌دارد، رمزگذاری می‌کند و یک سرآیند IP بیرونی جلوی آن می‌گذارد که خانواده آدرسش را آدرس‌های دو سر تعیین می‌کند، نه محتوای درون۔ دروازه دور آن سرآیند بیرونی را برمی‌دارد و بسته اصلی را به LAN خود ارسال می‌کند، جایی که دوباره بسته IPv6 معمولی است۔ تونل بیرونی و ترافیک درونی دو گفت‌وگوی جداگانه‌اند که یک کلید، یک جفت سر و چیز دیگری شریک دارند۔

دو سرآیند، دو خانواده آدرس

در حالت تونل IPsec، بسته IPv6 درونی به محموله پشت سرآیند ESP تبدیل می‌شود۔ سرآیند بیرونی که آن بسته ESP را حمل می‌کند می‌تواند IPv4 یا IPv6 باشد و از local_addrs و remote_addrs پیروی می‌کند۔ WireGuard همین کار را با تشریفات کمتر می‌کند: بسته درونی محموله یک دیتاگرام UDP به سر طرف مقابل است۔ هر دو سرآیند درونی را دست‌نخورده می‌گذارند، از همین رو طرف دور می‌تواند آن را پس از بسته‌گشایی مسیریابی کند۔

مسیر میان سایت‌ها فقط UDP 4500 را می‌بیند وقتی IPsec از عبور NAT استفاده می‌کند، یا UDP 51820 برای شنونده پیش‌فرض WireGuard۔ هر مسیریابی روی مسیر می‌تواند فقط IPv4 باشد و ترافیک IPv6 همچنان عبور می‌کند، چون هرگز روی آن مسیر به شکل بسته IPv6 ظاهر نمی‌شود۔ این یک جدایی اولیه پاک می‌دهد: tcpdump -ni eth0 udp port 51820 مسیر رمزگذاری‌شده را نشان می‌دهد، tcpdump -ni wg0 ip6 ترافیک درونی را۔ ضبط بیرونی شلوغ با ضبط درونی ساکت یعنی هسته IPv6 را در تونل نمی‌گذارد؛ این مسیریابی یا سیاست است، نه وضعیت پیوند۔

دروازه همچنین هنگام ارسال، حد پرش درونی را کاهش می‌دهد، پس دو سر روی مسیر IPv6 به‌عنوان مسیریاب شمرده می‌شوند۔ شمار پرش بیرونی و حد پرش درونی مستقل حرکت می‌کنند، و بسته‌ای که در دروازه دور می‌میرد در ارسال مرده است، نه در رمزگذاری۔

سلکتورها و AllowedIPs فهرست اجازه‌اند

IKEv2 بر سر این مذاکره می‌کند که child SA کدام پیشوندهای درونی را می‌تواند حمل کند۔ در strongSwan 5.9 و جدیدتر، نوشتن آن‌ها در swanctl.conf چنین است:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

اگر local_ts و remote_ts را حذف کنید، strongSwan آن‌ها را از زیرشبکه‌های رابطی که برمی‌گزیند استخراج می‌کند۔ روی میزبان دواستک، آن میانبر غالباً جفتی فقط IPv4 می‌دهد: SA بالا می‌آید و IPv6 پیش از رسیدن به کد ESP رد می‌شود۔ نوشتن هر دو پیشوند SA را شایسته حمل آن‌ها می‌کند، و start_action = trap آن را در نخستین بسته منطبق بالا می‌آورد۔

WireGuard یک فهرست دارد که دو کار می‌کند۔ در بلوک همتا، AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 هم مسیری است که هنگام ارسال نصب می‌شود و هم پالایه‌ای که هنگام دریافت اعمال می‌شود: بسته رمزگشایی‌شده‌ای که منبع درونی‌اش بیرون از فهرست آن همتا می‌افتد بی‌صدا دور ریخته می‌شود۔ wg-quick برای هر ورودی یک مسیر می‌افزاید، پس بلوک همتای پایین به فرمان جداگانه ip -6 route نیاز ندارد۔

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

هر دو فهرست باید آینه‌ای باشند: سایت B پیشوند سایت A را به‌عنوان سلکتور دور می‌پذیرد و آن را بازمی‌گرداند، و تونل تنها وقتی کار می‌کند که دو جهت هم‌سو باشند۔ فهرست نامتقارن نشانه‌ای می‌دهد که بیشترین وقت را می‌گیرد — دست‌دادن سالم، شمارنده‌هایی که در یک سمت حرکت می‌کنند، و یک ping از A به B که موفق می‌شود در حالی که چیزی از B به A نمی‌رسد۔

ارسال، مسیرها و پیشوند بازگشت

لینوکس IPv6 را تا نگویید ارسال نمی‌کند، و تنظیم به‌ازای فضای نام است نه به‌ازای رابط:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

سطر دوم همان است که مردم در طراحی‌های مبتنی بر مسیر فراموش می‌کنند۔ IPsec مبتنی بر سیاست، سیاست XFRM منطبق با پیشوندها نصب می‌کند، اما پیکربندی مبتنی بر مسیر با vti6 یا WireGuard به مسیر واقعی IPv6 نیاز دارد که به آن دستگاه اشاره کند۔ sysctl را زیر /etc/sysctl.d/ ماندگار کنید؛ وگرنه راه‌اندازی دوباره ارسال را بی‌صدا به خاموش برمی‌گرداند۔

ارسال یک اثر جانبی دارد که دانستنش می‌ارزد: هسته آن‌گاه اعلان‌های مسیریاب را نادیده می‌گیرد مگر آنکه net.ipv6.conf.<wan>.accept_ra برابر 2 باشد، پس دروازه‌ای که آدرس WANش از SLAAC می‌آید ممکن است همان لحظه‌ای که ارسال را فعال می‌کنید مسیر پیش‌فرضش را از دست بدهد۔ accept_ra = 2 را روی همان رابط در همان فایل تنظیم کنید تا مسیر بماند۔ هسته سایت B هم باید 2001:db8:aa::/48 را از دروازه تونل بیاموزد، با مسیر ایستا یا پروتکل مسیریابی روی تونل، وگرنه پاسخ درون شبکه خود B می‌میرد۔

بازرسی چهارمرحله‌ای که محل شکست را پیدا می‌کند

به همین ترتیب کار کنید و در نخستین مرحله‌ای که شکست می‌خورد بایستید، چون هر مرحله بعد به قبلی‌ها وابسته است۔

  1. سلکتورها: swanctl --list-sas باید جفت پیشوند IPv6 را روی child SA نشان دهد، یا wg show wg0 allowed-ips پیشوند دور را با latest-handshakes تازه۔
  2. مسیر هسته: ip -6 route get 2001:db8:bb::10 باید با دستگاه تونل پاسخ دهد، نه با رابط WAN۔
  3. ضبط درونی: tcpdump -ni wg0 ip6 هنگام ping میان میزبان‌های واقعی LAN۔ بسته‌هایی که بیرون می‌روند اما هیچ‌یک برنمی‌گردند به مسیر یا دیوار آتش B اشاره دارند؛ نبود کامل بسته به مرحله 1 یا 2 اشاره می‌کند۔
  4. مقصد: روی میزبان B، ss -6 -ltn تأیید می‌کند که سرویس روی IPv6 گوش می‌دهد، و شمارنده‌های دیوار آتش محلی نشان می‌دهند بسته پذیرفته یا دور ریخته شد۔

MTU در همان گذر می‌آید۔ مسیریاب‌های IPv6 تکه‌تکه نمی‌کنند، پس بسته بیش‌ازحد بزرگ دور ریخته می‌شود و Packet Too Big به فرستنده بازمی‌گردد۔ اگر دست‌دادن‌ها و ping‌های کوچک کار می‌کنند اما انتقال پرونده می‌ایستد، محموله را کوچک کنید تا بگذرد: ping -6 -s 1400 -c 3 2001:db8:bb::10۔ رابط‌های WireGuard به‌طور پیش‌فرض MTU 1420 بایت دارند و IPsec روی IPv4 بیشتر کم می‌کند، پس تنظیم MTU درونی بهتر از امید به کشف MTU مسیر از میان دیوار آتشی است که ICMPv6 را دور می‌ریزد۔

حالت‌های شکستی که شبیه مشکلات دیوار آتش‌اند

شایع‌ترین اصلاً دیوار آتش نیست: سرویس به 0.0.0.0 به‌جای :: می‌بندد، رکورد AAAA وجود دارد، و کلاینت رد سریع از طریق IPv6 می‌گیرد که مرورگر دواستک با بازگشت به IPv4 پنهانش می‌کند۔ اگر فقط بعضی برنامه‌ها شکست می‌خورند، پیش از دست‌زدن به مجموعه قواعد، خانواده گوش‌دادن را بررسی کنید۔

دومی پالایش ICMPv6 است۔ Neighbor Discovery و Packet Too Big بخشی از کار عادی‌اند نه عیب‌یابی، و سیاستی که همه ICMPv6 را دور می‌ریزد تونلی می‌سازد که وصل می‌شود، احراز هویت می‌کند و سپس روی هر چیزی بزرگ‌تر از بسته کوچک می‌ایستد۔ انواعی را که مسیر به آن‌ها وابسته است اجازه دهید و شمارنده‌ها را روشن بگذارید تا دورریختن دیده شود۔

سومی پیشوندی است که به تونل افزوده می‌شود اما هرگز به نقشه آدرس سایتی که مالک آن است افزوده نمی‌شود، پس هیچ مسیریابی آن را اعلام نمی‌کند و هیچ میزبانی نمی‌تواند از آن پاسخ دهد۔ با یک پیشوند و یک جفت میزبان شروع کنید، دو جهت را با چهار مرحله اثبات کنید و سپس بقیه را اضافه کنید؛ پیشوند خراب به‌جای بازطراحی، یک خط در پیکربندی می‌ماند۔ تنها مرجع رسمی که می‌ارزد باز بماند RFC 8200 است، که سرآیندی را تعریف می‌کند که تونل حمل می‌کند۔

مقالات مرتبط