IPv6-prefiksin delegointi sivustojen välisen VPN:n yli: tarkistuslista

Tunnelin nostaminen on se helppo puolisko. Olen nähnyt sivustojen välisen linkin pysyvän pystyssä päiväkausia, kun jokainen kaukolanin isäntä sai vastaukseksi hiljaisuutta, koska sen yhdyskäytävän takana oleva delegoitu prefiksi oli määritetty rajapinnalle mutta sitä ei koskaan reititetty tunneliin. Tunnelin osoitteet vastasivat pingiin koko ajan, ja juuri siksi kukaan ei katsonut prefiksiä. Tässä on järjestys, jonka tarkistan, kun delegoidun IPv6-prefiksin on ylitettävä sivuston VPN: prefiksikartta, liikenteen valitsimet, edelleenlähetys ja palomuuri, sitten paluupolku.

Kirjoita prefiksikartta ennen kuin kosket tunneliin

Prefiksin delegointi antaa lohkon reitittimelle, joka sitä pyysi. Se ei asenna reittiä vastapuolelle, ei laajenna lohkoa linkille eikä kerro kaukokäytävälle, mitä pyytävän reitittimen takana on. Ne kolme asiaa määrität itse, ja ne kuuluvat osoitesuunnitelmaan ennen kuin yksikään asetustiedosto muuttuu.

Kirjaa jokaisesta sivustosta delegoitu prefiksi, LANissa tosiasiassa käytössä oleva /64, tunnelin osoitteet ja jokaisen reitin omistaja. Palveluntarjoaja delegoi sivustolle A osoitteen 2001:db8:a1::/56, joka palvelee LANissaan osoitetta 2001:db8:a1:10::/64; sivusto B pitää osoitteen 2001:db8:b2::/64. Jos sivusto A palvelee vain tuota yhtä /64:ää, molempien päiden pitäisi nimetä 2001:db8:a1:10::/64 eikä koko /56:ta.

Kaksi virhettä näkyy lähes joka kerta. Toinen on kohdella kaukaista prefiksiä linkin paikallisena, sillata se tai laittaa se tunnelin rajapinnalle, jotta yhdyskäytävä vastaa naapurikyselyyn isännistä, joihin se ei pääse. Toinen on mainostaa koko /56:ta, kun vain yksi /64 on määritetty: reititystaulu väittää lohkon olevan tavoitettavissa ja suurin osa osoitteista putoaa mustaan aukkoon.

Sovita molempien päiden liikenteen valitsimet reitteihin

IKEv2 ja WireGuard hylkäävät molemmat yhteensopimattoman liikenteen, tarpeeksi hiljaa, jotta tunneli näyttää yhä terveeltä.

strongSwanissa valitsimet ovat eksplisiittisiä. Sivustolla 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

Sivuston B conn peilaa kahta aliverkkoa. Kun ne eivät täsmää, vastaaja hylkää CHILD_SA:n virheellä TS_UNACCEPTABLE, joten lapsi-SA ei nouse koskaan, vaikka IKE_SA nousi. Molemmilla puolilla määritetyn aliverkon on oltava sama kuin mihin paikallinen ydin reitittää tunneliin.

WireGuard kantaa saman tiedon AllowedIPs-kentässä, yhdellä kierteellä: AllowedIPs on lähdesuodatin vastaanotossa ja samalla reitti lähetyksessä. Jos sivuston B vertaismerkintä sivustolle A jättää pois osoitteen 2001:db8:a1:10::/64, sivuston A paketit saapuvat kelvollisella kättelyllä ja pudotetaan ei-sallittuina. Syntyy tuttu kuvio: kättely uusiutuu jatkuvasti, mutta vastausta ei koskaan lähde. Vertaa molemmat päät komennolla wg show wg0 allowed-ips. Tarkista lista uudelleen aina, kun delegointi muuttuu; vanhentunut /64 pitää istunnon pystyssä ja uuden prefiksin tavoittamattomana.

Sulje ensin pois edelleenlähetys, palomuuri ja MTU

Ennen kuin luet seuraavaa lokiriviä, varmista että yhdyskäytävät ylipäätään lähettävät edelleen. sysctl net.ipv6.conf.all.forwarding täytyy palauttaa 1 molemmilla, ja sitä on sovellettava myös tunnelin ja LANin rajapintoihin. Mukana tulee yksi ansa: kun edelleenlähetys on päällä, rajapinta, jonka accept_ra=1, lakkaa hyväksymästä palveluntarjoajan reititinilmoituksia, joten laite voi menettää ylävirran oletusreittinsä samalla kun se reitittää moitteettomasti tunnelin sisällä. Aseta accept_ra=2 sinne, missä palveluntarjoajan RA:ta yhä tarvitaan.

Sen jälkeen palomuurisääntöjen on sallittava prefiksi molempiin suuntiin, ja ICMPv6:n on selvittävä: naapurien löytäminen, paketti-liian-suuri ja kohde tavoittamattomissa eivät ole valinnaisia. Jos ne pudottaa, polun MTU:n löytäminen hajoaa ja saat yhteyksiä, jotka avautuvat ja pysähtyvät ensimmäiseen suureen vastaukseen. Minimaalinen sääntöpari näyttää tältä:

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 tuon takana. Tunneli pienentää käyttökelpoisen MTU:n alle 1500:n, ja IPv6 vaatii jokaisen linkin kantavan vähintään 1280. Pienet pingit menevät läpi, SSH-istunto jähmettyy suurella purskeella, ja /proc/net/snmp6 näyttää paketti-liian-suuri-viestejä, jotka eivät koskaan palaa. Aseta tunnelin MTU eksplisiittisesti tai rajaa TCP MSS mangle-taulussa ja päästä pienemmästä MTU:sta kertova ICMPv6 palaamaan.

Testaa paluupolku, ei tunnelin osoite

Eniten aikaa maksava vika on yksisuuntainen reititys. Jokainen yhdyskäytävä reitittää kaukaisen prefiksin tunneliin, mutta isännät vastaavat oman oletusyhdyskäytävänsä kautta, koska siellä niiden /64 asuu. Paketin saaminen kohteeseen on vain puoli matkaa.

Kaksi komentoa ratkaisee suurimman osan. Sivustolla A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 näyttää, mitä rajapintaa vastaus tuosta lähteestä käyttäisi; tee peilaus tarkistus sivustolla B. Luo sitten liikennettä isännästä eikä yhdyskäytävästä ja vertaa laskureita molemmissa päissä.

Jos kaukaisen prefiksin naapurikysely ilmestyy tunneliin, se prefiksi on linkin paikallisena jossakin, missä sen ei pitäisi olla; korjaa se ennen reittien säätämistä. Proxy NDP kattaa tapaukset, joissa sillaus on todella tarpeen, eikä se korvaa reittiä.

Suunnittele prefiksin vaihtuminen altasi

Prefiksin delegointi on vuokrasopimus delegoivan ja pyytävän reitittimen välillä, ja uusiminen voi palauttaa eri lohkon: eri /56 palveluntarjoajan migraation jälkeen tai lyhyemmän vuokran kuin tunnelin ylhäälläoloaika. Jokainen paikka, joka nimeää vanhan prefiksin, vanhenee kerralla: reitit, valitsimet, AllowedIPs, palomuurisäännöt, DNS-tietueet ja mikä tahansa valvonta, joka kovakoodaa kirjaimellisia osoitteita. Viestinkulku on kohdassa RFC 8415.

Missä prefiksin odotetaan liikkuvan, pidä sisäinen osoitesuunnitelma, joka ei riipu siitä, ja käännä rajalla. NPTv6 on tilaton vaihtoehto ja pitää sisäisen käytännön luettavana, mutta se on prefiksin käännös, ei taikakerros: /64:n rajojen on kohdattava, tarkistussummat säädetään, ja sovellukset, jotka upottavat kirjaimellisia osoitteita, hajoavat yhä. Jos pidät palveluntarjoajan osoitteet päästä päähän, kirjaa vuokrakäyttäytyminen ja muutosmenettely osoitesuunnitelmaan.

Lopeta testillä, joka kestää aikaa: sallittu isäntä kummassakin LANissa tavoittaa palvelun toisessa LANissa, vastaus palaa tunnelin kautta, ja sama pari toimii yhä tunnelin uudelleenkäynnistyksen ja delegoinnin uusimisen jälkeen. Jos viimeinen osa epäonnistuu, suunnittelu riippuu tilasta, joka ei kestä viikkoa.