IPv6-prefiksi delegeerimine saidi ja saidi vahelise VPN-i kaudu: kontroll-loend

Tunneli püsti panek on lihtne pool. Olen näinud, kuidas saidi ja saidi vaheline link püsib päevade kaupa üleval, samal ajal kui iga kaugema LAN-i host saab vastuseks vaikuse, sest selle lüüsi taga olev delegeeritud prefiks oli liidesele konfigureeritud, kuid seda ei marsruuditud kunagi tunnelisse. Tunneli aadressid vastasid kogu aeg pingidele ja just seetõttu ei vaadanud keegi prefiksit. Siin on järjekord, mida kontrollin, kui delegeeritud IPv6-prefiks peab saidi VPN-i läbima: prefiksite kaart, liikluse selektorid, edasisaatmine ja tulemüür, seejärel tagasitee.

Kirjutage prefiksite kaart enne, kui tunnelit puudutate

Prefiksi delegeerimine annab ploki ruuterile, kes seda küsis. See ei paigalda marsruuti partnerile, ei laienda seda plokki lingile ega ütle kaugemale lüüsile, mis asub küsiva ruuteri taga. Need kolm asja konfigureerite teie ja need kuuluvad aadressiplaani enne, kui mõni konfiguratsioonifail muutub.

Iga saidi kohta kirjutage üles delegeeritud prefiks, LAN-is tegelikult kasutatav /64, tunneli aadressid ja iga marsruudi omanik. Teenusepakkuja delegeerib saidile A 2001:db8:a1::/56, mis teenindab oma LAN-is 2001:db8:a1:10::/64; sait B hoiab 2001:db8:b2::/64. Kui sait A teenindab ainult seda ühte /64, peaksid mõlemad otsad nimetama 2001:db8:a1:10::/64, mitte tervet /56.

Kaks viga ilmnevad peaaegu iga kord. Üks on kohelda kaugemat prefiksit lingil olevana, seda sillata või panna tunneli liidesele, et lüüs vastaks naabriküsimusele hostide kohta, kuhu ta ei ulatu. Teine on kuulutada tervet /56, kui on konfigureeritud ainult üks /64: marsruutitabel väidab, et plokk on kättesaadav, ja enamik aadresse kukub musta auku.

Viige mõlema otsa liikluse selektorid marsruutidega vastavusse

IKEv2 ja WireGuard keelduvad mõlemad sobimatust liiklusest, piisavalt vaikselt, et tunnel näeks endiselt terve välja.

strongSwanis on selektorid selgesõnalised. Saidis 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

Saiti B conn peegeldab kahte alamvõrku. Kui need ei ühti, lükkab vastaja CHILD_SA tagasi veaga TS_UNACCEPTABLE, nii et tütar-SA ei tule kunagi üles, kuigi IKE_SA tuli. Mõlemal poolel peab konfigureeritud alamvõrk võrduma sellega, mida kohalik kernel tunnelisse marsruudib.

WireGuard kannab sama teavet AllowedIPs-is, ühe nükega: AllowedIPs on vastuvõtmisel allikafilter ja saatmisel marsruut. Kui saidi B partnerikirje saidi A jaoks jätab 2001:db8:a1:10::/64 välja, saabuvad saidi A paketid kehtiva käepigistusega ja visatakse lubamatuna kõrvale. See tekitab tuttava mustri: käepigistus uueneb pidevalt, samal ajal kui ükski vastus ei lahku. Võrrelge mõlemat otsa käsuga wg show wg0 allowed-ips. Kontrollige seda loendit iga delegeerimise muutuse järel; aegunud /64 hoiab seansi üleval ja uue prefiksi kättesaamatuna.

Välistage kõigepealt edasisaatmine, tulemüür ja MTU

Enne kui loete veel üht logirida, kinnitage, et lüüsid üldse edasi saadavad. sysctl net.ipv6.conf.all.forwarding peab mõlemal tagastama 1, rakendatuna ka tunneli ja LAN-i liidestele. Kaasas on üks lõks: kui edasisaatmine on sees, lakkab liides, mille accept_ra=1, teenusepakkuja ruuteriteadetest vastu võtmast, nii et masin võib kaotada ülesvoolu vaikemarsruudi, samal ajal kui tunnelis marsruudib see laitmatult. Määrake accept_ra=2 seal, kus teenusepakkuja RA-d veel vaja on.

Seejärel peavad tulemüürireeglid lubama prefiksit mõlemas suunas ja ICMPv6 peab üle elama: naabrite avastamine, pakett-liiga-suur ja sihtkoht-kättesaamatu ei ole valikulised. Kui need ära visata, läheb tee MTU avastamine katki ja saate ühendused, mis avanevad ja jäävad siis esimese suure vastuse juures kinni. Minimaalne reeglipaar näeb välja selline:

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 on selle taga. Tunnel vähendab kasutatava MTU alla 1500 ja IPv6 nõuab, et iga lüli kannaks vähemalt 1280. Väikesed pingid lähevad läbi, SSH-seanss jäätub suure purske juures ja /proc/net/snmp6 näitab pakett-liiga-suuri teateid, mis ei tule kunagi tagasi. Seadke tunneli MTU selgesõnaliselt või klammerdage TCP MSS mangle-tabelis, ja laske väiksemast MTU-st teataval ICMPv6-l tagasi tulla.

Testige tagasiteed, mitte tunneli aadressi

Kõige rohkem aega maksma panev tõrge on ühesuunaline marsruutimine. Iga lüüs marsruudib kaugema prefiksi tunnelisse, kuid hostid vastavad oma vaikelüüsi kaudu, sest seal asub nende /64. Paketi sihtkohta viimine on vaid pool teest.

Kaks käsku lahendavad suurema osa. Saidis A näitab ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5, millist liidest kasutaks vastus sellest allikast; tehke peegelkontroll saidis B. Seejärel genereerige liiklust hostist, mitte lüüsist, ja võrrelge loendureid mõlemas otsas.

Kui kaugema prefiksi naabriküsimus ilmub tunnelisse, on see prefiks lingil kohas, kus seda olla ei tohiks; parandage see enne marsruutide kohandamist. Proxy NDP katab juhtumid, kus sillastamine on tõesti vajalik, mitte marsruudi asendus.

Planeerige, et prefiks muutub teie all

Prefiksi delegeerimine on rendisuhe delegeeriva ja küsiva ruuteri vahel ning uuendus võib tagastada teistsuguse ploki: teistsuguse /56 pärast teenusepakkuja migratsiooni või lühema rendi, kui tunnel on olnud üleval. Iga koht, mis nimetab vana prefiksit, aegub korraga: marsruudid, selektorid, AllowedIPs, tulemüürireeglid, DNS-kirjed ja igasugune monitooring, mis kõvakodeerib literaalseid aadresse. Sõnumivoog on RFC 8415.

Kus prefiksi liikumist oodatakse, hoidke sisemist aadressiplaani, mis sellest ei sõltu, ja tõlkige piiril. NPTv6 on olekuta valik ja hoiab sisemise poliitika loetavana, kuid see on prefiksi tõlge, mitte maagiline kiht: /64 piirid peavad kattuma, kontrollsummasid kohandatakse ja rakendused, mis põimivad literaalseid aadresse, lähevad ikka katki. Kui hoiate teenusepakkuja aadresse algusest lõpuni, kirjutage rendikäitumine ja muudatusprotseduur aadressiplaani.

Lõpetage testiga, mis peab ajale vastu: iga LAN-i lubatud host jõuab teise LAN-i teenuseni, vastus tuleb tunnelist tagasi ja sama paar töötab endiselt pärast tunneli taaskäivitust ja delegeerimise uuendust. Kui viimane osa ebaõnnestub, sõltub disain olekust, mis nädalat üle ei ela.