Delegasyon ng Prefix ng IPv6 sa isang Site-to-Site na VPN: Checklist

Ang pagpataas ng tunnel ang madaling kalahati. May nakita akong site-to-site na link na nanatiling naka-establish nang ilang araw habang bawat host sa malayong LAN ay tahimik na sagot ang natatanggap, dahil ang delegadong prefix sa likod ng gateway na iyon ay naka-configure sa isang interface pero hindi kailanman na-route papasok sa tunnel. Sumasagot sa ping ang mga address ng tunnel sa buong panahon, at iyon mismo ang dahilan kung bakit walang tumitingin sa prefix. Ito ang pagkakasunod-sunod na sinusuri ko kapag ang delegadong prefix ng IPv6 ay kailangang tumawid sa site VPN: ang mapa ng prefix, ang mga tagapili ng trapiko, ang pagpapasa at firewall, at pagkatapos ang daan pabalik.

Isulat ang mapa ng prefix bago hawakan ang tunnel

Ang delegasyon ng prefix ay nagbibigay ng block sa router na humiling nito. Hindi ito naglalagay ng ruta sa peer, hindi nito pinalalawak ang block na iyon bilang on-link, at hindi nito sinasabi sa malayong gateway kung ano ang nasa likod ng humihiling na router. Ang tatlong ito ang kailangan mong i-configure mismo, at nabibilang sila sa isang plano ng address bago magbago ang anumang configuration file.

Para sa bawat site, itala ang delegadong prefix, ang /64 na aktwal na ginagamit sa LAN, ang mga address ng tunnel at ang may-ari ng bawat ruta. Idinidelegado ng provider ang 2001:db8:a1::/56 sa site A, na naghahain ng 2001:db8:a1:10::/64 sa LAN nito; pinapanatili ng site B ang 2001:db8:b2::/64. Kung ang site A ay naghahain lamang ng nag-iisang /64 na iyon, dapat tukuyin ng dalawang dulo ang 2001:db8:a1:10::/64 sa halip na ang buong /56.

Halos palagi ay lumilitaw ang dalawang pagkakamali. Ang isa ay ituring na on-link ang malayong prefix, i-bridge ito o ilagay sa interface ng tunnel para sumagot ang gateway sa neighbor solicitation para sa mga host na hindi nito maabot. Ang isa pa ay i-anunsyo ang buong /56 kapag isang /64 lang ang naka-configure: sinasabi ng routing table na maabot ang block at karamihan ng address ay napupunta sa itim na butas.

Itugma ang mga tagapili ng trapiko ng dalawang dulo sa mga ruta

Parehong tinatanggihan ng IKEv2 at WireGuard ang trapikong hindi tugma, sapat na tahimik para magmukhang malusog pa rin ang tunnel.

Sa strongSwan, hayag ang mga tagapili. Sa site 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=start

Ang conn ng site B ay sumasalamin sa dalawang subnet. Kapag hindi sila nagtutugma, tinatanggihan ng responder ang CHILD_SA gamit ang TS_UNACCEPTABLE, kaya hindi kailanman bumabangon ang child SA kahit bumangon ang IKE_SA. Sa magkabilang panig, ang naka-configure na subnet ay dapat katumbas ng niroruta ng lokal na kernel patungo sa tunnel.

Dinadala ng WireGuard ang parehong impormasyon sa AllowedIPs, na may isang pag-twist: ang AllowedIPs ay filter ng pinagmulan sa pagtanggap at ruta sa pagpapadala. Kung ang peer entry ng site B para sa site A ay laktawan ang 2001:db8:a1:10::/64, dumarating ang mga packet mula sa site A sa isang valid na handshake at itinatapon bilang hindi pinapayagan. Nagbubunga iyon ng pamilyar na pattern ng handshake na paulit-ulit na nagre-renew habang walang sagot na lumalabas. Ihambing ang dalawang dulo gamit ang wg show wg0 allowed-ips. Suriin muli ang listahang iyon sa tuwing magbabago ang delegasyon; ang lumang /64 ay nagpapanatiling buhay ng session at hindi maabot ang bagong prefix.

Unahing ibukod ang pagpapasa, firewall at MTU

Bago magbasa ng isa pang linya ng log, tiyakin na talagang nagpapasa ang mga gateway. Kailangang magbalik ng 1 ang sysctl net.ipv6.conf.all.forwarding sa pareho, na inilalapat din sa mga interface ng tunnel at LAN. May kasamang isang bitag: kapag naka-on ang pagpapasa, tumitigil sa pagtanggap ng router advertisement mula sa provider ang isang interface na may accept_ra=1, kaya maaaring mawala ng makina ang upstream default route kahit perpektong nag-route sa loob ng tunnel. Itakda ang accept_ra=2 kung saan kailangan pa rin ang RA ng provider.

Pagkatapos, kailangang payagan ng mga patakaran ng firewall ang prefix sa dalawang direksyon, at kailangang mabuhay ang ICMPv6: ang neighbor discovery, packet-too-big at destination-unreachable ay hindi opsyonal. Kung itatapon mo ang mga ito, masisira ang path MTU discovery, at makakakuha ka ng mga koneksyong bumubukas at pagkatapos ay tumitigil sa unang malaking sagot. Ganito ang hitsura ng pinakamaliit na pares ng patakaran:

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 } accept

Nasa likod nito ang MTU. Pinaliit ng tunnel ang magagamit na MTU sa ilalim ng 1500, at inaatas ng IPv6 na magdala ang bawat link ng hindi bababa sa 1280. Nakakapasok ang maliliit na ping, nagyeyelo ang SSH session sa malaking burst, at nagpapakita ang /proc/net/snmp6 ng packet-too-big na mensaheng hindi na bumabalik. Itakda nang tahasan ang MTU ng tunnel, o i-clamp ang TCP MSS sa mangle table, at hayaang makabalik ang ICMPv6 na nag-uulat ng mas maliit na MTU.

Subukan ang daan pabalik, hindi ang address ng tunnel

Ang kabiguan na pinakamaraming oras ay ang one-way routing. Niroruta ng bawat gateway ang malayong prefix papasok sa tunnel, pero sumasagot ang mga host sa pamamagitan ng sarili nilang default gateway dahil doon nakatira ang kanilang /64. Ang maihatid ang packet sa destinasyon ay kalahati lang ng daan.

Dalawang utos ang lumulutas sa karamihan. Sa site A, ipinapakita ng ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 kung aling interface ang gagamitin ng sagot mula sa pinagmulang iyon; isagawa ang salamin na pagsusuri sa site B. Pagkatapos ay gumawa ng trapiko mula sa host at hindi sa gateway, at ihambing ang mga counter sa dalawang dulo.

Kung lumitaw sa tunnel ang neighbor solicitation para sa malayong prefix, on-link ang prefix na iyon sa isang lugar na hindi dapat; ayusin iyon bago i-adjust ang mga ruta. Sinasaklaw ng proxy NDP ang mga kaso kung tunay na kailangan ang bridging, hindi kapalit ng ruta.

Planuhin ang pagbabago ng prefix sa ilalim mo

Ang delegasyon ng prefix ay isang lease sa pagitan ng delegating at humihiling na router, at ang renewal ay maaaring magbalik ng ibang block: ibang /56 pagkatapos ng migrasyon ng provider, o mas maikling lease kaysa tagal ng pagkakataas ng tunnel. Bawat lugar na nagpangalan ng lumang prefix ay luma nang sabay: mga ruta, tagapili, AllowedIPs, patakaran ng firewall, DNS record at anumang monitoring na nagha-hardcode ng literal na address. Nasa RFC 8415 ang daloy ng mensahe.

Kung saan inaasahang gumagalaw ang prefix, panatilihin ang panloob na plano ng address na hindi umaasa rito at isalin sa hangganan. Ang NPTv6 ay ang stateless na opsyon at pinapanatiling nababasa ang panloob na patakaran, pero ito ay pagsasalin ng prefix, hindi isang mahiwagang layer: kailangang pantay ang mga hangganan ng /64, inaayos ang checksum, at nasisira pa rin ang mga aplikasyong naglalagay ng literal na address. Kung pinapanatili mo ang mga address ng provider mula dulo hanggang dulo, itala ang pag-uugali ng lease at pamamaraan ng pagbabago sa plano ng address.

Tapusin sa isang pagsubok na tumatagal sa panahon: naaabot ng pinapayagang host sa bawat LAN ang isang serbisyo sa kabilang LAN, bumabalik ang sagot sa tunnel, at gumagana pa rin ang parehong pares pagkatapos ng restart ng tunnel at renewal ng delegasyon. Kung mabibigo ang huling bahagi, umaasa ang disenyo sa estado na hindi tatagal ng isang linggo.