Načrtovanje IPv6 za WireGuard zvezdišče z dvema lokacijama: predpona, partnerji, poti
Prehodite zasebno zvezdišče IPv6 za dve LAN: izberite predpono, rezervirajte naslove tunela in nato dovolite AllowedIPs, da izrazi, kateri partner ima katero podomrežje.
Dve LAN, eno WireGuard zvezdišče in načrt naslovov IPv6, ki mora odgovoriti na tri ločena vprašanja: katera predpona, kateri naslov pripada vsakemu usmerjevalniku in kateri partner ima katero podomrežje. En napačen odgovor ustvari tunel, ki opravi rokovanje in ničesar ne usmeri. Načrt spodaj v tem vrstnem redu prehodi zasebno zasnovo z dvema lokacijama. Namenoma ne zagotavlja dostopa do interneta prek IPv6.
Odločite, čemu je predpona namenjena
Edinstvena lokalna predpona iz fd00::/8 je naravna izbira, ko je cilj zasebna dosegljivost med lokacijami. Ostane stabilna ne glede na to, kateri ponudnik oskrbuje vsako lokacijo, in ni oglaševana v globalni usmerjevalni tabeli, zato ne more izteči vašega notranjega številčenja v internet.
Ista lastnost je omejitev. ULA ne daje nobene javne povratne poti, ker noben nadrejeni ponudnik ne ve, da bi jo moral usmeriti na vaša vrata. Če zahteva vključuje izhod v internet prek IPv6, potrebujete dodelitev ponudnika, ki jo usmeri k vam, in to je ločena oblikovalska odločitev z lastno velikostjo predpone.
Ne predpostavljajte, da vsaka namestitev potrebuje /48. RFC 6177 se je oddaljil od ene obvezne velikosti končne lokacije, pravilna velikost pa izhaja iz števila omrežij, ki jih boste upravljali. Ustvarite ULA s postopkom RFC 4193, namesto da bi izumili predpono, ki bi jo lahko uporabila tudi druga organizacija. Rezultat zapišite v načrt naslovov, preden je konfigurirana katera koli naprava, kajti predpona, ki je nihče ni zabeležil, je predpona, ki jo bo nekdo znova uporabil.
Razdelite predpono na vloge
Spodnji primer uporablja fd7c:2e91:4a00::/48, tabela pa je urejena po tem, kam se zapiše vsak blok, ne po lokaciji. Vrednosti obravnavajte kot vzorec in pred uvajanjem česarkoli ustvarite svoje.
| 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 |
Bloki LAN so /64, ker običajni SLAAC pričakuje 64-bitni identifikator vmesnika. Delitev LAN na manjši blok poruši to predpostavko na večini gostiteljev, operativni stroški pa niso vredni prihranka naslovov v zasebnem načrtu. Oba bloka LAN izvirata iz sredine /48, nizko območje pa ostane prosto za poznejše lokacije.
Naslovi tunela so upravna zaloga, ne omrežje na povezavi. Vsak vmesnik iz nje dobi en /128, zato noben gostitelj ne predpostavlja skupnega podomrežja na tunelu in odkrivanje sosedov ne teče tam, kjer ni potrebno. Vloge naj bodo ločene in jih zabeležite v načrtu naslovov organizacije, da poznejša lokacija ne uporabi bloka znova.
Vsakemu usmerjevalniku dajte en naslov tunela
Dodeli en /128 na usmerjevalnik in ohranite obstoječe ključe in končne točke delujočega zvezdišča. Tri spodnje vrednosti se razlikujejo le v delu gostitelja.
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
Ta /128 opisuje edini naslov, dodeljen temu vmesniku. Ne pove ničesar o tem, na koliko ciljev lahko partner usmerja, ker se dosegljivost izraža v AllowedIPs in ne v predponi vmesnika.
Vsak usmerjevalnik lokacije potrebuje tudi naslov v svojem bloku LAN in način za njegovo razširjanje, običajno objave usmerjevalnika za SLAAC. WireGuard teh objav ne pošilja namesto vas in ne poveže obeh LAN. Usmerjevalnik lokacije je usmerjevalnik v obe smeri.
Lastništvo podomrežja postavite v AllowedIPs
Vnos partnerja v zvezdišču za Lokacijo A ima naslov tunela A in LAN A, ta par pa je celotna izjava o lastništvu. Nič drugega v tem razdelku partnerja ni treba opisovati lokacije.
AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64
Vnos partnerja za Lokacijo B ima ustrezni par, simetrija pa je tu pomembnejša od jedrnatosti. Preberite obe vrstici skupaj in delitev lastništva postane vidna na prvi pogled.
AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64
To sta dva ločena razdelka partnerja, ne dva seznama, ki tekmujeta za enega partnerja. WireGuard uporablja AllowedIPs v obeh smereh: izbere partnerja za odhodni cilj in zavrne dohodni paket, katerega vir se ne ujema z obsegom, dodeljenim partnerju, ki ga je dešifriral. Če bi obema partnerjema dodelili celoten /48, bi se ta druga preveritev izklopila in zabrisalo bi se, katera lokacija ima kateri blok. Prav ta razlika naredi napačen izvorni naslov viden, namesto tiho sprejet.
Vsaka lokacija potrebuje le cilje, dosegljive prek njenega partnerja v zvezdišču: Lokacija A navaja naslov zvezdišča, naslov tunela Lokacije B in LAN B, Lokacija B pa navaja obratno množico. Seznami so namerno asimetrični, ker vsak usmerjevalnik vidi drugo stran topologije. Oba zapišite iz načrta naslovov in ne iz konfiguracije druge lokacije, kajti tako zastarel obseg preživi preštevilčenje.
Z wg-quick ti obsegi ustvarijo tudi poti. S systemd-networkd ali ročno nastavitvijo enakovredne poti dodajte sami; sicer tunel prenaša pakete, ki jih jedro nikoli ne pošlje vanj.
Dokončajte posredovanje in preizkusite obe smeri
Omogočite posredovanje IPv6 v zvezdišču in na obeh usmerjevalnikih lokacij ter v politiki posredovanja dovolite potrebne storitve med lokacijami. Vzdržujte sporočila ICMPv6 Packet Too Big uporabna, ker njihovo zavrženje pokvari odkrivanje MTU poti in povzroči zastoje velikih prenosov, ki so videti kot napake aplikacije. Zvezdišče, ki posreduje brez dovoljenja požarnega zidu, paket zavrže med usmerjanjem in tunelom. Ta način odpovedi je vreden poznavanja, ker tunel ostane aktiven in umre le nekaj tokov.
sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1
Preizkusite z gostitelja na Lokaciji A na gostitelja na Lokaciji B in nato v nasprotni smeri. Ping na naslov tunela zvezdišča preizkusi le prvi skok in bo uspel tudi, ko so poti LAN napačne. Tok od gostitelja do gostitelja je tisti, ki dokaže načrt.
Zunanja povezava WireGuard lahko teče prek IPv4, medtem ko je notranji promet IPv6, in ta neodvisnost je koristna med selitvijo. Če se pozneje doda globalni izhod IPv6, ponovno preglejte dodelitev ponudnika, izbiro izvornega naslova in povratno usmerjanje kot nov korak zasnove; zasebni načrt zgoraj ostane veljaven za promet med lokacijami.