I-ruta ang IPv6 sa pagitan ng dalawang site sa umiiral na VPN

Kapag nagdagdag ka ng IPv6 prefix sa isang site-to-site tunnel, hindi bumibiyahe ang packet ayon sa iminumungkahi ng diagram. Kinukuha ng lokal na gateway ang buong IPv6 packet, ine-encrypt ito, at naglalagay sa harap ng panlabas na IP header na ang address family ay pinagpasyahan ng mga address ng endpoint, hindi ng nasa loob. Tinatanggal ng malayong gateway ang panlabas na header na iyon at ipinapasa ang orihinal na packet sa LAN nito, kung saan ordinaryong IPv6 packet na naman ito. Panlabas na tunnel at panloob na trapiko ay dalawang magkahiwalay na usapan na nagbabahagi ng isang key, isang pares ng endpoint, at wala nang iba.

Dalawang header, dalawang address family

Sa IPsec tunnel mode, ang panloob na IPv6 packet ang nagiging payload sa likod ng ESP header. Ang panlabas na header na nagdadala ng ESP packet na iyon ay maaaring IPv4 o IPv6, at sinusunod nito ang local_addrs at remote_addrs. Gayundin ang ginagawa ng WireGuard nang mas kaunting seremonya: ang panloob na packet ang payload ng isang UDP datagram patungo sa endpoint ng peer. Kapwa hindi ginagalaw ang panloob na header, kaya naruruta ito ng kabilang panig pagkatapos ng decapsulation.

Ang landas sa pagitan ng mga site ay nakakakita lamang ng UDP 4500 kapag gumamit ang IPsec ng NAT traversal, o UDP 51820 para sa default na WireGuard listener. Maaaring IPv4 lamang ang bawat router doon at tumatawid pa rin ang IPv6 traffic, dahil hindi ito lumilitaw bilang IPv6 packet sa landas na iyon. Nagbibigay iyon ng malinis na unang paghahati: tcpdump -ni eth0 udp port 51820 ang nagpapakita ng naka-encrypt na landas, tcpdump -ni wg0 ip6 ang nagpapakita ng panloob na trapiko. Ang abalang panlabas na capture na may tahimik na panloob ay nangangahulugang hindi inilalagay ng kernel ang IPv6 sa tunnel; iyon ay routing o patakaran, hindi estado ng link.

Binabawasan din ng gateway ang panloob na Hop Limit habang nagpapasa, kaya binibilang ang mga endpoint bilang router sa IPv6 landas. Magkahiwalay na gumagalaw ang panlabas na hop count at panloob na Hop Limit, at ang packet na namatay sa malayong gateway ay namatay sa pagpapasa, hindi sa encryption.

Ang mga selector at AllowedIPs ang listahan ng pahintulot

Nakikipagnegosyo ang IKEv2 kung aling panloob na prefix ang maaaring dalhin ng child SA. Sa strongSwan 5.9 at mas bago, ganito ang hitsura ng pagsusulat ng mga ito sa 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
  }
}

Alisin ang local_ts at remote_ts at hinahango ito ng strongSwan mula sa mga subnet ng interface na pinipili nito. Sa dual-stack host, madalas na nagreresulta ang shortcut na iyon sa pares na IPv4 lamang: umaangat ang SA at tinatanggihan ang IPv6 bago pa ito makarating sa ESP code. Ang pagsusulat ng dalawang prefix ay nagpapaging-karapat-dapat sa SA na dalhin ang mga ito, at iniaangat ito ng start_action = trap sa unang tumutugmang packet.

Isang listahan lang ang WireGuard na gumagawa ng dalawang trabaho. Sa peer block, ang AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 ay kapwa ang rutang inilalagay sa pagpapadala at ang filter na inilalapat sa pagtanggap: ang na-decrypt na packet na ang panloob na pinagmulan ay nasa labas ng listahan ng peer na iyon ay tahimik na itinatapon. Nagdadagdag ang wg-quick ng ruta bawat entry, kaya hindi kailangan ng peer block sa ibaba ang hiwalay na ip -6 route command.

[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

Kailangang magkatapat ang dalawang listahan: tinatanggap ng site B ang prefix ng site A bilang malayong selector at irinuruta ito pabalik, at gumagana lamang ang tunnel kapag nagkasundo ang dalawang direksyon. Ang hindi pantay na listahan ay nagbibigay ng sintomas na pinakamaraming oras ang nasasayang — isang malusog na handshake, mga counter na gumagalaw sa isang panig, at isang ping mula A patungo B na nagtatagumpay habang walang mula B na nakakaabot sa A.

Pagpapasa, ruta, at ang prefix ng pagbabalik

Hindi nagpapasa ang Linux ng IPv6 hangga't hindi mo sinasabi, at ang setting ay per namespace hindi per interface:

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

Ang ikalawang linya ang nakakalimutan sa mga disenyong nakabatay sa ruta. Naglalagay ang IPsec na nakabatay sa patakaran ng XFRM policy na tumutugma sa mga prefix, ngunit ang pagsasaayos na nakabatay sa ruta na may vti6 o WireGuard ay nangangailangan ng tunay na IPv6 route na nakaturo sa device na iyon. Panatilihin ang sysctl sa ilalim ng /etc/sysctl.d/; kung hindi, tahimik na ibinabalik ng reboot ang pagpapasa sa off.

May side effect ang pagpapasa na dapat mong malaman: binabalewala ng kernel ang mga anunsyo ng router maliban kung net.ipv6.conf.<wan>.accept_ra ay 2, kaya ang gateway na ang WAN address ay dumarating sa SLAAC ay maaaring mawala ang rutang default sa sandaling i-enable mo ang pagpapasa. Itakda ang accept_ra = 2 sa interface na iyon sa parehong file at magpapatuloy ang ruta. Dapat ding matutunan ng core ng site B ang 2001:db8:aa::/48 mula sa tunnel gateway, sa pamamagitan ng static route o routing protocol sa tunnel, kung hindi mamamatay ang tugon sa loob ng sariling network ng B.

Isang apat na hakbang na pagsusuri na naglolokalisa ng pagkasira

Magtrabaho sa ayos na ito at huminto sa unang hakbang na nabigo, dahil ang bawat susunod na hakbang ay nakadepende sa mga nauna.

1. Mga selector: dapat ipakita ng swanctl --list-sas ang IPv6 prefix pair sa child SA, o ng wg show wg0 allowed-ips ang malayong prefix na may kamakailang latest-handshakes.
2. Ruta ng kernel: dapat sumagot ang ip -6 route get 2001:db8:bb::10 gamit ang tunnel device, hindi ang WAN interface.
3. Panloob na capture: tcpdump -ni wg0 ip6 habang nagpi-ping sa pagitan ng tunay na LAN host. Mga packet na lumalabas ngunit walang bumabalik ay tumuturo sa ruta o firewall ng B; walang packet man ay tumuturo pabalik sa hakbang 1 o 2.
4. Destinasyon: sa B host, kinukumpirma ng ss -6 -ltn na nakikinig ang serbisyo sa IPv6, at ipinapakita ng lokal na firewall counter kung tinanggap o itinapon ang packet.

Kasama ang MTU sa parehong pass. Hindi nagfragment ang mga IPv6 router, kaya itinatapon ang sobrang laking packet at bumabalik ang Packet Too Big sa nagpadala. Kung gumagana ang handshake at maliliit na ping ngunit natigil ang paglipat ng file, bawasan ang payload hanggang makapasa: ping -6 -s 1400 -c 3 2001:db8:bb::10. Default na 1420 bytes MTU ang WireGuard interface at mas malaki ang binabawas ng IPsec sa IPv4, kaya mas mabuti ang itakda ang panloob na MTU kaysa umasa sa pagtuklas ng MTU ng landas sa firewall na nagtatapon ng ICMPv6.

Mga failure mode na mukhang problema sa firewall

Ang pinakakaraniwan ay hindi firewall: nagbibigkis ang serbisyo sa 0.0.0.0 sa halip na ::, umiiral ang AAAA record, at nakakatanggap ang client ng mabilis na pagtanggi sa IPv6 na itinatago ng dual-stack browser sa pamamagitan ng pagbabalik sa IPv4. Kung ilang application lang ang nabigo, suriin ang pamilyang nakikinig bago hawakan ang isang set ng patakaran.

Ang pangalawa ay ang pagsasala ng ICMPv6. Bahagi ng normal na operasyon ang Neighbor Discovery at Packet Too Big, hindi ng diagnostic, at ang patakaran na nagtatapon ng lahat ng ICMPv6 ay gumagawa ng tunnel na kumokonekta, nagpapatotoo, at pagkatapos ay natigil sa anumang mas malaki kaysa maliit na packet. Payagan ang mga type na nakadepende ang landas at iwanang nakabukas ang mga counter para makita ang pagtatapon.

Ang pangatlo ay isang prefix na idinagdag sa tunnel ngunit hindi kailanman sa address plan ng site na nagmamay-ari nito, kaya walang router ang nag-aanunsyo nito at walang host ang makakasagot mula rito. Magsimula sa isang prefix at isang pares ng host, patunayan ang dalawang direksyon sa apat na hakbang, pagkatapos idagdag ang iba pa; ang sirang prefix ay nananatiling isang linya sa configuration sa halip na isang redesign. Ang tanging opisyal na sanggunian na sulit panatilihing bukas ay RFC 8200, na nagtatakda ng header na dinadala ng tunnel.