IPv6:n suunnittelu kahden toimipisteen WireGuard-keskukselle: etuliite, vertaiset, reitit
Käy läpi yksityinen IPv6-keskus kahdelle LAN-verkolle: valitse etuliite, varaa tunneliosoitteet ja anna sitten AllowedIPsin ilmaista, mikä vertainen omistaa minkä aliverkon.
Kaksi LAN-verkkoa, yksi WireGuard-keskus ja IPv6-osoitesuunnitelma, jonka on vastattava kolmeen erilliseen kysymykseen: mikä etuliite, mikä osoite kuuluu millekin reitittimelle ja mikä vertainen omistaa minkä aliverkon. Yhdenkin virhe tuottaa tunnelin, joka tekee kättelyn eikä reititä mitään. Alla oleva suunnitelma käy läpi yksityisen kahden toimipisteen mallin tässä järjestyksessä. Se ei tarkoituksella tarjoa IPv6-internetyhteyttä.
Päätä, mihin etuliitettä käytetään
Ainutlaatuinen paikallinen etuliite fd00::/8-avaruudesta on luonnollinen valinta, kun tavoitteena on yksityinen tavoitettavuus toimipisteiden välillä. Se pysyy vakaana riippumatta siitä, mikä operaattori palvelee kutakin sijaintia, eikä sitä mainosteta globaalissa reititystaulussa, joten se ei voi vuotaa sisäistä numerointiasi internetiin.
Sama ominaisuus on rajoitus. ULA ei anna julkista paluureittiä, koska mikään ylävirta ei tiedä reitittää sitä yhdyskäytävällesi. Jos vaatimus sisältää IPv6-internetlähdön, tarvitset osoituksen palveluntarjoajalta, joka reitittää sen sinulle, ja se on erillinen suunnittelupäätös omalla etuliitekoollaan.
Älä oleta, että jokainen käyttöönotto tarvitsee /48:n. RFC 6177 luopui yhdestä pakollisesta loppusijainnin koosta, ja oikea koko seuraa niiden verkkojen määrää, joita tulet ylläpitämään. Luo ULA RFC 4193 -menettelyllä sen sijaan, että keksisit etuliitteen, jota toinenkin organisaatio voisi käyttää. Kirjoita tulos osoitesuunnitelmaan ennen kuin mitään laitetta määritetään, sillä etuliite, jota kukaan ei kirjannut, on etuliite, jonka joku käyttää uudelleen.
Jaa etuliite rooleihin
Alla oleva esimerkki käyttää etuliitettä fd7c:2e91:4a00::/48, ja taulukko on järjestetty sen mukaan, mihin kukin lohko kirjoitetaan, ei toimipisteen mukaan. Käsittele arvoja näytteenä ja luo omasi ennen minkään käyttöönottoa.
| Where it is written | What appears there | Block used | What it establishes |
|---|---|---|---|
| Hub wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::1/128 | The hub's own tunnel identity |
| Hub wg0.conf, Site A peer | Two ranges in one AllowedIPs line | ::2/128 and :10::/64 | That A owns its tunnel address and its LAN |
| Hub wg0.conf, Site B peer | Two ranges in one AllowedIPs line | ::3/128 and :20::/64 | That B owns its tunnel address and its LAN |
| Site A wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::2/128 | A's identity as the hub sees it |
| Site B wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::3/128 | B's identity as the hub sees it |
LAN-lohkot ovat /64, koska tavallinen SLAAC odottaa 64-bittistä liitäntätunnistetta. LAN-verkon jakaminen pienempään lohkoon rikkoo tämän oletuksen useimmilla isäntäkoneilla, eikä käyttökustannus ole osoitesäästön arvoinen yksityisessä suunnitelmassa. Molemmat LAN-lohkot tulevat /48:n keskeltä, jättäen matalan alueen vapaaksi myöhemmille toimipisteille.
Tunneliosoitteet ovat hallinnollinen varanto, eivät linkin verkko. Jokainen liitäntä saa siitä yhden /128:n, joten mikään isäntä ei oleta jaettua aliverkkoa tunnelissa eikä naapureiden etsintää ajeta siellä, missä sitä ei tarvita. Pidä roolit erillään ja kirjaa ne organisaation osoitesuunnitelmaan, jotta myöhempi toimipiste ei käytä lohkoa uudelleen.
Anna jokaiselle reitittimelle yksi tunneliosoite
Anna yksi /128 reititintä kohden ja säilytä toimivan keskuksen nykyiset avaimet ja päätepisteet. Kolme alla olevaa arvoa eroavat vain isäntäosassa.
Hub: Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128
Tämä /128 kuvaa kyseiselle liitännälle annettua yhtä osoitetta. Se ei kerro, kuinka moneen kohteeseen vertainen saa reitittää, koska tavoitettavuus ilmaistaan AllowedIPsissä, ei liitännän etuliitteessä.
Jokainen toimipisteen reititin tarvitsee myös osoitteen omassa LAN-lohkossaan ja tavan jakaa se, yleensä reititinmainoksia SLAACia varten. WireGuard ei lähetä näitä mainoksia puolestasi eikä siltaa kahta LAN-verkkoa. Toimipisteen reititin on reititin molempiin suuntiin.
Laita aliverkon omistus AllowedIPsiin
Keskuksen vertaismerkintä toimipisteelle A omistaa A:n tunneliosoitteen ja A:n LAN-verkon, ja tämä pari on koko omistuslauseke. Mikään muu kyseisessä vertaisosassa ei tarvitse kuvailla toimipistettä.
AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64
Toimipisteen B vertaismerkintä omistaa vastaavan parin, ja symmetria on tässä tärkeämpää kuin lyhyys. Lue kaksi riviä yhdessä, niin omistuksen jako näkyy yhdellä silmäyksellä.
AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64
Nämä ovat kaksi erillistä vertaisosaa, eivät kaksi listaa, jotka kilpailevat yhdestä vertaisesta. WireGuard käyttää AllowedIPsiä molempiin suuntiin: se valitsee vertaisen lähtevälle kohteelle ja hylkää saapuvan paketin, jonka lähde ei vastaa sen vertaisen aluetta, joka sen purki. Koko /48:n antaminen molemmille vertaisille poistaisi tämän toisen tarkistuksen käytöstä ja hämärtäisi, mikä toimipiste omistaa minkä lohkon. Juuri tämä ero tekee väärästä lähdeosoitteesta näkyvän sen sijaan, että se hyväksyttäisiin hiljaa.
Kukin toimipiste tarvitsee vain kohteet, jotka ovat tavoitettavissa sen keskusvertaisen kautta: toimipiste A luettelee keskuksen osoitteen, toimipisteen B tunneliosoitteen ja B:n LAN-verkon, ja toimipiste B luettelee vastakkaisen joukon. Listat ovat tarkoituksella epäsymmetrisiä, koska jokainen reititin näkee topologiasta eri puolen. Kirjoita molemmat osoitesuunnitelmasta, ei toisen toimipisteen kokoonpanosta, sillä niin vanhentunut alue selviää uudelleennumeroinnista.
wg-quickin kanssa nämä alueet luovat myös reittejä. systemd-networkdin tai manuaalisen asennuksen kanssa lisää vastaavat reitit itse; muuten tunneli kuljettaa paketteja, joita ydin ei koskaan lähetä siihen.
Viimeistele edelleenlähetys ja testaa molemmat suunnat
Ota IPv6-edelleenlähetys käyttöön keskuksessa ja molemmissa toimipisteen reitittimissä ja salli tarvittavat toimipisteiden väliset palvelut edelleenlähetyskäytännössä. Pidä ICMPv6 Packet Too Big -viestit käyttökelpoisina, sillä niiden pudottaminen rikkoo polun MTU:n löydön ja aiheuttaa suurten siirtojen pysähdyksiä, jotka näyttävät sovellusvirheiltä. Keskus, joka välittää ilman palomuurin lupaa, pudottaa paketin reitityksen ja tunnelin välissä. Tämä vikatila kannattaa tuntea, sillä tunneli pysyy pystyssä ja vain osa virroista kuolee.
sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1
Testaa toimipisteen A isännästä toimipisteen B isäntään ja sitten vastakkaiseen suuntaan. Ping keskuksen tunneliosoitteeseen harjoittaa vain ensimmäistä hyppyä ja onnistuu, vaikka LAN-reitit olisivat väärin. Isännästä isäntään -virta on se, joka todistaa suunnitelman.
Ulompi WireGuard-yhteys voi kulkea IPv4:n yli, kun sisäinen liikenne on IPv6, ja tämä riippumattomuus on hyödyllistä migraation aikana. Jos globaali IPv6-lähtö lisätään myöhemmin, tarkastele palveluntarjoajan osoitusta, lähdeosoitteen valintaa ja paluureititystä uutena suunnitteluvaiheena; yllä oleva yksityinen suunnitelma pysyy kelvollisena toimipisteiden väliselle liikenteelle.