IPv6-előtagdelegálás helyek közötti VPN-en át: ellenőrzőlista

A búra felállítása a könnyebbik fele. Láttam már napokig fennálló helyek közötti kapcsolatot úgy, hogy a túlsó LAN minden gazdagépe csendet kapott vissza, mert az átjáró mögötti delegált előtag egy interfészen be volt állítva, de soha nem került be az alagútba. Az alagút címei egész idő alatt válaszoltak a pingekre, és épp ezért senki nem nézte az előtagot. Íme a sorrend, amit ellenőrzök, amikor egy delegált IPv6-előtagnak át kell jutnia egy helyek közötti VPN-en: az előtagtérkép, a forgalomválasztók, a továbbítás és a tűzfal, majd a visszaút.

Írd meg az előtagtérképet, mielőtt az alagúthoz nyúlsz

Az előtagdelegálás egy blokkot ad annak az útválasztónak, amelyik kérte. Nem telepít útvonalat a társra, nem terjeszti ki a blokkot on-link módon, és nem mondja meg a távoli átjárónak, mi van a kérő útválasztó mögött. Ezt a hármat neked kell beállítanod, és a címtervbe tartozik, mielőtt bármelyik konfigfájl megváltozik.

Minden helynél rögzítsd a delegált előtagot, a LAN-on ténylegesen használt /64-et, az alagút címeit és minden útvonal tulajdonosát. A szolgáltató a 2001:db8:a1::/56-ot delegálja az A helynek, amely a LAN-ján a 2001:db8:a1:10::/64-et szolgálja ki; a B hely megtartja a 2001:db8:b2::/64-et. Ha az A hely csak ezt az egy /64-et szolgálja ki, mindkét végnek a 2001:db8:a1:10::/64-et kell megneveznie, nem a teljes /56-ot.

Két hiba szinte mindig előjön. Az egyik, hogy a távoli előtagot on-linkként kezelik, áthidalják, vagy az alagút interfészre teszik, így az átjáró szomszédkeresést válaszol meg olyan gazdagépekre, amelyeket nem ér el. A másik, hogy a teljes /56-ot hirdetik, amikor csak egy /64 van beállítva: az útvonaltábla szerint a blokk elérhető, és a címek nagy része fekete lyukba esik.

A két vég forgalomválasztóit igazítsd az útvonalakhoz

Az IKEv2 és a WireGuard egyaránt elutasítja a nem egyező forgalmat, elég halkan ahhoz, hogy az alagút továbbra is egészségesnek tűnjön.

A strongSwanban a választók explicit módon szerepelnek. Az A helyen:

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

A B hely conn bejegyzése tükrözi a két alhálózatot. Ha nem egyeznek, a válaszadó a CHILD_SA-t TS_UNACCEPTABLE értékkel utasítja el, így a gyermek SA soha nem jön létre, bár az IKE_SA igen. Mindkét oldalon a beállított alhálózatnak meg kell egyeznie azzal, amit a helyi kernel az alagút felé irányít.

A WireGuard ugyanezt az információt az AllowedIPs mezőben hordozza, egy csavarral: az AllowedIPs forrás-szűrő a fogadásnál és útvonal a küldésnél. Ha a B helynek az A helyre vonatkozó peer bejegyzése kihagyja a 2001:db8:a1:10::/64-et, az A helyről érkező csomagok érvényes kézfogás mellett érkeznek, és nem engedélyezettként eldobódnak. Ebből lesz az ismerős minta: a kézfogás újra és újra megújul, miközben válasz soha nem indul el. Hasonlítsd össze mindkét végét a wg show wg0 allowed-ips paranccsal. Ellenőrizd újra a listát, valahányszor a delegálás változik; egy elavult /64 életben tartja a munkamenetet, és elérhetetlenné teszi az új előtagot.

Először a továbbítást, a tűzfalat és az MTU-t zárd ki

Mielőtt újabb naplósort olvasnál, győződj meg róla, hogy az átjárók egyáltalán továbbítanak. A sysctl net.ipv6.conf.all.forwarding parancsnak mindkettőn 1-et kell visszaadnia, az alagút és a LAN interfészekre is alkalmazva. Ehhez egy csapda is tartozik: amint a továbbítás be van kapcsolva, az accept_ra=1 beállítású interfész leáll a szolgáltató útválasztó-hirdetéseinek fogadásával, így a gép elveszítheti a felső szintű alapértelmezett útvonalát, miközben az alagúton belül hibátlanul irányít. Ott állítsd accept_ra=2-re, ahol még szükség van a szolgáltató hirdetésére.

A tűzfalszabályoknak ezután mindkét irányban engedélyezniük kell az előtagot, és az ICMPv6-nak is túl kell élnie: a szomszédkeresés, a packet-too-big és a destination-unreachable nem opcionális. Ha eldobod őket, a path MTU felderítés elromlik, és olyan kapcsolatokat kapsz, amelyek megnyílnak, majd az első nagy válasznál elakadnak. Egy minimális szabálypár így néz ki:

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

Az MTU e mögött van. Az alagút 1500 alá csökkenti a használható MTU-t, az IPv6 pedig megköveteli, hogy minden kapcsolat legalább 1280-at vigyen. A kis pingek átmennek, az SSH-munkamenet egy nagy sorozatnál megfagy, és a /proc/net/snmp6 olyan packet-too-big üzeneteket mutat, amelyek soha nem jönnek vissza. Állítsd be kifejezetten az alagút MTU-ját, vagy korlátozd a TCP MSS-t a mangle táblában, és engedd visszatérni az ICMPv6-ot, amely a kisebb MTU-t jelenti.

A visszautat teszteld, ne az alagút címét

A legtöbb időt felemésztő hiba az egyirányú irányítás. Minden átjáró a távoli előtagot az alagútba irányítja, de a gazdagépek a saját alapértelmezett átjárójukon keresztül válaszolnak, mert ott lakik a /64-ük. Egy csomagot a célhoz eljuttatni fél útvonal.

Két parancs elintézi a legtöbbet. Az A helyen a ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 megmutatja, melyik interfészt használná az adott forrásból jövő válasz; futtasd a tükrözött ellenőrzést a B helyen. Ezután gazdagépről generálj forgalmat, ne az átjáróról, és hasonlítsd össze a számlálókat mindkét végén.

Ha a távoli előtagra vonatkozó szomszédkeresés az alagúton jelenik meg, az az előtag valahol on-link, ahol nem kellene; ezt javítsd ki az útvonalak módosítása előtt. A proxy NDP azokat az eseteket fedi le, ahol az áthidalás valóban szükséges, nem az útvonal helyettesítője.

Tervezz azzal, hogy az előtag alattad változik meg

Az előtagdelegálás bérlet a delegáló és a kérelmező útválasztó között, és a megújítás más blokkot adhat vissza: egy másik /56-ot szolgáltatóváltás után, vagy rövidebb bérletet annál, mint ameddig az alagút fennáll. Minden hely, ahol a régi előtag szerepel, egyszerre elavul: útvonalak, választók, AllowedIPs, tűzfalszabályok, DNS-rekordok és minden olyan megfigyelés, amely szó szerinti címeket kódol. Az üzenetfolyam az RFC 8415 dokumentumban van.

Ahol az előtag várhatóan mozogni fog, tartson fenn egy belső címzési tervet, amely nem függ tőle, és a határon fordítson. Az NPTv6 az állapotmentes lehetőség, és olvashatóvá teszi a belső szabályzatot, de ez előtagfordítás, nem varázsréteg: a /64 határoknak illeszkedniük kell, az ellenőrzőösszegek módosulnak, és a szó szerinti címeket beágyazó alkalmazások továbbra is elromlanak. Ha végponttól végpontig megtartja a szolgáltató címeit, rögzítse a bérlet viselkedését és a változtatási eljárást a címzési tervben.

Fejezze be egy időtálló teszttel: minden LAN egy engedélyezett gazdagépe elér egy szolgáltatást a másik LAN-on, a válasz az alagúton keresztül tér vissza, és ugyanez a pár egy alagút-újraindítás és egy delegálás-megújítás után is működik. Ha az utolsó rész elbukik, a tervezés olyan állapottól függ, amely nem éli túl a hetet.