IPv6 prefiksų delegavimas per svetainių tarpusavio VPN: kontrolinis sąrašas

Tunelio pakėlimas yra lengvesnė pusė. Mačiau svetainių tarpusavio ryšį, kuris dienomis išlikdavo užmegztas, nors kiekvienas tolimo LAN hostas gaudavo tik tylą, nes deleguotasis prefiksas už to šliuzo buvo sukonfigūruotas sąsajoje, bet niekada nebuvo maršrutizuotas į tunelį. Tunelio adresai visą laiką atsakydavo į ping, ir būtent todėl niekas nežiūrėjo į prefiksą. Štai tvarka, kurią tikrinu, kai deleguotasis IPv6 prefiksas turi kirsti svetainės VPN: prefiksų žemėlapis, srauto selektoriai, persiuntimas ir ugniasienė, o paskui grįžtamasis kelias.

Užrašyk prefiksų žemėlapį, prieš liesdamas tunelį

Prefiksų delegavimas atiduoda bloką tam maršrutizatoriui, kuris jo paprašė. Jis neįdiegia maršruto gretimame mazge, neišplečia to bloko on-link ir nepasako tolimajam šliuzui, kas yra už prašančiojo maršrutizatoriaus. Šiuos tris dalykus turite sukonfigūruoti patys, ir jie priklauso adresų planui, kol nepasikeitė nė vienas konfigūracijos failas.

Kiekvienai svetainei užrašykite deleguotą prefiksą, LAN tinkle faktiškai naudojamą /64, tunelio adresus ir kiekvieno maršruto savininką. Tiekėjas deleguoja 2001:db8:a1::/56 svetainei A, kuri savo LAN tinkle aptarnauja 2001:db8:a1:10::/64; svetainė B išlaiko 2001:db8:b2::/64. Jei svetainė A aptarnauja tik tą vieną /64, abu galai turėtų nurodyti 2001:db8:a1:10::/64, o ne visą /56.

Dvi klaidos pasitaiko beveik visada. Viena – tolimą prefiksą laikyti on-link, jį tiltinti arba dėti į tunelio sąsają, kad šliuzas atsakytų į kaimynų užklausas dėl hostų, kurių nepasiekia. Kita – skelbti visą /56, kai sukonfigūruotas tik vienas /64: maršrutų lentelė teigia, kad blokas pasiekiamas, o dauguma adresų patenka į juodąją skylę.

Suderink abiejų galų srauto selektorius su maršrutais

IKEv2 ir WireGuard abu atmeta nesuderintą srautą, pakankamai tyliai, kad tunelis vis dar atrodytų sveikas.

strongSwan selektoriai yra aiškūs. Svetainėje 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

Svetainės B conn atspindi abu potinklius. Kai jie nesutampa, atsakantysis atmeta CHILD_SA su TS_UNACCEPTABLE, todėl child SA niekada neatsiranda, nors IKE_SA jau atsirado. Abiejose pusėse sukonfigūruotas potinklis turi sutapti su tuo, ką vietinis kernel maršrutizuoja link tunelio.

WireGuard tą pačią informaciją neša AllowedIPs, su vienu niuansu: AllowedIPs yra šaltinio filtras priimant ir maršrutas siunčiant. Jei svetainės B peer įrašas svetainei A praleidžia 2001:db8:a1:10::/64, paketai iš svetainės A atkeliauja su galiojančiu handshake ir yra išmetami kaip neleistini. Taip atsiranda pažįstamas modelis: handshake nuolat atnaujinamas, o atsakymas niekada neišeina. Palygink abu galus su wg show wg0 allowed-ips. Kaskart pasikeitus delegavimui iš naujo patikrink tą sąrašą; pasenęs /64 palaiko sesiją ir naują prefiksą daro nepasiekiamą.

Pirmiausia atmesk persiuntimą, ugniasienę ir MTU

Prieš skaitydami dar vieną žurnalo eilutę patvirtinkite, kad šliuzai apskritai persiunčia. sysctl net.ipv6.conf.all.forwarding abiejuose turi grąžinti 1, taikoma ir tunelio bei LAN sąsajoms. Yra ir vienas spąstas: įjungus persiuntimą, sąsaja su accept_ra=1 nustoja priimti tiekėjo maršrutizatoriaus skelbimus, todėl įrenginys gali prarasti viršutinį numatytąjį maršrutą, nors tunelio viduje maršrutizuoja nepriekaištingai. Nustatykite accept_ra=2 ten, kur tiekėjo RA dar reikalingas.

Tada ugniasienės taisyklės turi leisti prefiksą abiem kryptimis, o ICMPv6 turi išgyventi: kaimynų aptikimas, packet-too-big ir destination-unreachable nėra pasirinktini. Jei juos išmesite, kelio MTU aptikimas sugenda, ir gausite ryšius, kurie atsiveria, o paskui sustoja ties pirmu dideliu atsakymu. Minimali taisyklių pora atrodo taip:

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 yra už to. Tunelis sumažina naudojamą MTU žemiau 1500, o IPv6 reikalauja, kad kiekviena jungtis perneštų bent 1280. Maži ping praeina, SSH sesija sustingsta ties dideliu pliūpsniu, o /proc/net/snmp6 rodo packet-too-big pranešimus, kurie niekada negrįžta. Nustatyk tunelio MTU aiškiai arba apribok TCP MSS mangle lentelėje ir leisk ICMPv6, pranešančiam apie mažesnį MTU, grįžti.

Tikrink grįžtamąjį kelią, o ne tunelio adresą

Daugiausia laiko kainuojantis gedimas yra vienkryptis maršrutizavimas. Kiekvienas šliuzas maršrutizuoja tolimą prefiksą į tunelį, bet hostai atsako per savo numatytąjį šliuzą, nes ten gyvena jų /64. Paketą pristatyti iki tikslo yra pusė kelio.

Du komandos išsprendžia didžiąją dalį. Svetainėje A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 parodo, kurią sąsają naudotų atsakymas iš to šaltinio; atlik veidrodinę patikrą svetainėje B. Tada generuok srautą iš hosto, o ne iš šliuzo, ir palygink skaitiklius abiejuose galuose.

Jei kaimynų užklausa dėl tolimo prefikso pasirodo tunelyje, tas prefiksas kažkur yra on-link ten, kur jo neturėtų būti; sutvarkyk tai prieš koreguodami maršrutus. Proxy NDP apima atvejus, kai tiltinimas tikrai būtinas, o ne pakeičia maršrutą.

Planuok, kad prefiksas keisis po tavimi

Prefiksų delegavimas yra nuoma tarp deleguojančio ir prašančio maršrutizatoriaus, o atnaujinimas gali grąžinti kitą bloką: kitą /56 po tiekėjo migracijos arba trumpesnę nuomą, nei tunelis gyvuoja. Kiekviena vieta, nurodanti seną prefiksą, iš karto pasensta: maršrutai, selektoriai, AllowedIPs, ugniasienės taisyklės, DNS įrašai ir bet kokia stebėsena, kuri užkoduoja pažodinius adresus. Pranešimų srautas yra RFC 8415.

Kai tikimasi, kad prefiksas judės, palaikyk vidinį adresų planą, kuris nuo jo nepriklauso, ir versti pasienyje. NPTv6 yra bevaltis variantas ir išlaiko vidinę politiką perskaitomą, bet tai prefikso vertimas, o ne stebuklingas sluoksnis: /64 ribos turi sutapti, kontrolinės sumos koreguojamos, o programos, įterpiančios pažodinius adresus, vis tiek lūžta. Jei išlaikote tiekėjo adresus nuo galo iki galo, užrašykite nuomos elgseną ir keitimo procedūrą adresų plane.

Užbaik laiką atlaikančiu testu: leidžiamas hostas kiekviename LAN pasiekia paslaugą kitame LAN, atsakymas grįžta per tunelį, ir ta pati pora vis dar veikia po tunelio perkrovimo ir delegavimo atnaujinimo. Jei paskutinė dalis nepavyksta, projektas priklauso nuo būsenos, kuri neišgyvens savaitės.