IPv6 prefiksu deleģēšana starp vietnēm VPN: kontrolsaraksts

Deleģētā IPv6 prefiksa maršrutēšanas pārbaudes starp vietnēm VPN: prefiksu karte, trafika selektori, pārsūtīšana, MTU, atgriešanās ceļš un pārnumurēšana.

Tuneļa pacelšana ir vieglākā puse. Esmu redzējis starp vietnēm savienojumu, kas dienām palika izveidots, kamēr katrs tālā LAN saimnieks saņēma tikai klusumu, jo deleģētais prefikss aiz šīs vārtejas bija konfigurēts saskarnē, bet nekad netika maršrutēts tunelī. Tuneļa adreses visu laiku atbildēja uz ping, un tieši tāpēc neviens neskatījās uz prefiksu. Lūk, kārtība, ko pārbaudu, kad deleģētajam IPv6 prefiksam jāšķērso vietnes VPN: prefiksu karte, trafika selektori, pārsūtīšana un ugunsmūris, un tad atgriešanās ceļš.

Uzraksti prefiksu karti, pirms aiztiec tuneli

Prefiksu deleģēšana nodod bloku tam maršrutētājam, kurš to pieprasīja. Tā neinstalē maršrutu partnerī, nepaplašina šo bloku on-link un nepasaka tālajai vārtejai, kas atrodas aiz pieprasītāja maršrutētāja. Šīs trīs lietas jākonfigurē pašam, un tās pieder adrešu plānam, pirms mainās jebkurš konfigurācijas fails.

Katrai vietnei pieraksti deleģēto prefiksu, LAN faktiski izmantoto /64, tuneļa adreses un katra maršruta īpašnieku. Pakalpojumu sniedzējs deleģē 2001:db8:a1::/56 vietnei A, kas savā LAN apkalpo 2001:db8:a1:10::/64; vietne B saglabā 2001:db8:b2::/64. Ja vietne A apkalpo tikai šo vienu /64, abiem galiem jānorāda 2001:db8:a1:10::/64, nevis viss /56.

Gandrīz vienmēr parādās divas kļūdas. Viena ir tālo prefiksu uzskatīt par on-link, to tiltot vai ievietojot tuneļa saskarnē, lai vārteja atbildētu uz kaimiņu pieprasījumiem par saimniekiem, kurus tā nevar sasniegt. Otra ir izsludināt visu /56, kad konfigurēts tikai viens /64: maršrutu tabula apgalvo, ka bloks ir sasniedzams, un lielākā daļa adrešu iekrīt melnajā caurumā.

Saskaņo abu galu trafika selektorus ar maršrutiem

IKEv2 un WireGuard abi atsaka neatbilstošu trafiku, pietiekami klusi, lai tunelis joprojām izskatītos vesels.

strongSwan selektori ir skaidri. Vietnē 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

Vietnes B conn atspoguļo abus apakštīklus. Kad tie nesakrīt, atbildētājs noraida CHILD_SA ar TS_UNACCEPTABLE, tāpēc child SA nekad nepaceļas, lai gan IKE_SA jau pacēlās. Abās pusēs konfigurētajam apakštīklam jābūt vienādam ar to, ko vietējais kodols maršrutē tuneļa virzienā.

WireGuard to pašu informāciju nes AllowedIPs, ar vienu īpatnību: AllowedIPs ir avota filtrs saņemšanā un maršruts sūtīšanā. Ja vietnes B peer ieraksts vietnei A izlaiž 2001:db8:a1:10::/64, paketes no vietnes A ierodas ar derīgu handshake un tiek izmestas kā neatļautas. Tā rodas pazīstamais modelis: handshake nepārtraukti atjaunojas, bet atbilde nekad neiziet. Salīdzini abus galus ar wg show wg0 allowed-ips. Ik reizi, kad deleģēšana mainās, pārbaudi šo sarakstu vēlreiz; novecojis /64 uztur sesiju dzīvu un jauno prefiksu padara nesasniedzamu.

Vispirms izslēdz pārsūtīšanu, ugunsmūri un MTU

Pirms lasi vēl vienu žurnāla rindu, pārliecinies, ka vārtejas vispār pārsūta. sysctl net.ipv6.conf.all.forwarding abās jāatgriež 1, attiecināts arī uz tuneļa un LAN saskarnēm. Klāt nāk viens slazds: kad pārsūtīšana ir ieslēgta, saskarne ar accept_ra=1 pārstāj pieņemt pakalpojumu sniedzēja maršrutētāja reklāmas, tāpēc iekārta var zaudēt augšupējo noklusējuma maršrutu, lai gan tunelī maršrutē nevainojami. Iestati accept_ra=2 tur, kur pakalpojumu sniedzēja RA vēl joprojām vajadzīga.

Tad ugunsmūra noteikumiem jāatļauj prefikss abos virzienos, un ICMPv6 jāizdzīvo: kaimiņu atklāšana, packet-too-big un destination-unreachable nav izvēles. Ja tos izmet, ceļa MTU atklāšana salūzt, un iegūsti savienojumus, kas atveras un pēc tam apstājas pie pirmās lielās atbildes. Minimālais noteikumu pāris izskatās šādi:

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

MTU ir aiz tā. Tunelis samazina lietojamo MTU zem 1500, un IPv6 prasa, lai katrs posms pārvadātu vismaz 1280. Mazie ping iziet, SSH sesija sastingst pie liela uzplūduma, un /proc/net/snmp6 rāda packet-too-big ziņojumus, kas nekad neatgriežas. Iestati tuneļa MTU skaidri vai ierobežo TCP MSS mangle tabulā un ļauj ICMPv6, kas ziņo par mazāku MTU, atgriezties.

Pārbaudi atgriešanās ceļu, nevis tuneļa adresi

Visvairāk laika izmaksājošais bojājums ir vienvirziena maršrutēšana. Katra vārteja maršrutē tālo prefiksu tunelī, bet saimnieki atbild caur savu noklusējuma vārteju, jo tur dzīvo viņu /64. Paketes nogādāšana līdz galamērķim ir puse ceļa.

What you seeLikely causeFirst check
Tunnel up, every host silentremote prefix not routed into the tunnelip -6 route get on both gateways
Handshake renews, no repliessource prefix missing from selectors or AllowedIPsipsec statusall, wg show allowed-ips
Small pings pass, transfers stallMTU or ICMPv6 packet-too-big filtered/proc/net/snmp6 counters
Old prefix still worksstale /64 left in routes or selectorsdelegation lease and route table

Divas komandas atrisina lielāko daļu. Vietnē A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 parāda, kuru saskarni izmantotu atbilde no šī avota; veic spoguļa pārbaudi vietnē B. Pēc tam ģenerē trafiku no saimnieka, nevis no vārtejas, un salīdzini skaitītājus abos galos.

Ja tuneļa virsū parādās kaimiņu pieprasījums tālajam prefiksam, šis prefikss kaut kur ir on-link, kur tam nevajadzētu būt; izlabo to pirms maršrutu pielāgošanas. Proxy NDP aptver gadījumus, kad tiltēšana patiešām ir nepieciešama, nevis aizstāj maršrutu.

Plāno, ka prefikss mainīsies zem tevis

Prefiksu deleģēšana ir noma starp deleģējošo un pieprasītāju maršrutētāju, un atjaunošana var atgriezt citu bloku: citu /56 pēc pakalpojumu sniedzēja migrācijas vai īsāku nomu, nekā tunelis darbojas. Katra vieta, kas nosauc veco prefiksu, uzreiz noveco: maršruti, selektori, AllowedIPs, ugunsmūra noteikumi, DNS ieraksti un jebkurš monitorings, kas iekodē burtiskas adreses. Ziņojumu plūsma ir RFC 8415.

Kur prefikss, visticamāk, pārvietosies, uzturi iekšēju adrešu plānu, kas no tā nav atkarīgs, un pārtulko uz robežas. NPTv6 ir bezstāvokļa variants un saglabā iekšējo politiku lasāmu, bet tā ir prefiksa tulkošana, nevis maģisks slānis: /64 robežām jāsakrīt, kontrolsummas tiek pielāgotas, un lietotnes, kas iestrādā burtiskas adreses, joprojām salūzt. Ja saglabā pakalpojumu sniedzēja adreses no gala līdz galam, pieraksti nomas uzvedību un izmaiņu procedūru adrešu plānā.

Pabeidz ar testu, kas pārdzīvo laiku: atļauts saimnieks katrā LAN sasniedz pakalpojumu otrā LAN, atbilde atgriežas pa tuneli, un tas pats pāris joprojām strādā pēc tuneļa restartēšanas un deleģēšanas atjaunošanas. Ja pēdējā daļa neizdodas, dizains ir atkarīgs no stāvokļa, kas nepārdzīvos nedēļu.

Saistītie raksti