To LAN, éin WireGuard-hub og ein IPv6-adresseplan som må svare på tre separate spørsmål: kva prefiks, kva adresse som høyrer til kvar ruter, og kva peer som eig kva subnett. Eitt feil svar gjev ein tunnel som gjer handtrykk og ikkje rutar noko. Planen nedanfor går gjennom eit privat design med to lokasjonar i den rekkjefølgja. Han gjev medvite ikkje internettilgang via IPv6.

Avgjer kva prefikset skal brukast til

Eit unikt lokalt prefiks frå fd00::/8 er det naturlege valet når målet er privat nåbarheit mellom lokasjonar. Det held seg stabilt uansett kva leverandør som betener kvar lokasjon, og det vert ikkje annonsert i den globale rutetabellen, så det kan ikkje lekkje den interne nummereringa di til internett.

Den same eigenskapen er avgrensinga. Ein ULA gjev ingen offentleg returveg, fordi ingen oppstraumsleverandør veit at han skal rutast til gatewayen din. Viss kravet omfattar internettutgang via IPv6, treng du ei tildeling frå ein leverandør som rutar han til deg, og det er ei eiga designavgjerd med sin eigen prefiksstorleik.

Ikkje gå ut frå at kvar utrulling treng eit /48. RFC 6177 flytta seg bort frå éin obligatorisk storleik for endesona, og rett storleik følgjer talet på nettverk du skal drifte. Generer ULA-en med RFC 4193-prosedyren i staden for å finne opp eit prefiks som ein annan organisasjon òg kan bruke. Skriv resultatet inn i adresseplanen før noko eining vert konfigurert, for eit prefiks som ingen har notert er eit prefiks nokon vil bruke om att.

Del prefikset inn i rollar

Dømet nedanfor brukar fd7c:2e91:4a00::/48, og tabellen er organisert etter kvar kvar blokk vert skriven, ikkje etter lokasjon. Behandle verdiane som eit døme og generer dine eigne før du rullar ut noko.

Where it is writtenWhat appears thereBlock usedWhat it establishes
Hub wg0.conf, interface addressA single host address on the tunnelfd7c:2e91:4a00:ff00::1/128The hub's own tunnel identity
Hub wg0.conf, Site A peerTwo ranges in one AllowedIPs line::2/128 and :10::/64That A owns its tunnel address and its LAN
Hub wg0.conf, Site B peerTwo ranges in one AllowedIPs line::3/128 and :20::/64That B owns its tunnel address and its LAN
Site A wg0.conf, interface addressA single host address on the tunnelfd7c:2e91:4a00:ff00::2/128A's identity as the hub sees it
Site B wg0.conf, interface addressA single host address on the tunnelfd7c:2e91:4a00:ff00::3/128B's identity as the hub sees it

LAN-blokkene er /64 fordi vanleg SLAAC ventar ein 64-bits grensesnittidentifikator. Å dele eit LAN i ei mindre blokk bryt den føresetnaden på dei fleste vertar, og driftskostnaden er ikkje adresseinnsparinga verd i ein privat plan. Båe LAN-blokkene kjem frå midten av /48 og lèt det låge området vere fritt for seinare lokasjonar.

Tunneladressene er eit administrativt forråd, ikkje eit nettverk på lenkja. Kvart grensesnitt får éin einaste /128 frå det, så ingen vert går ut frå eit delt subnett på tunnelen, og nabo-oppdaging køyrer ikkje der ho ikkje trengst. Hald rollane åtskilde og registrer dei i adresseplanen til organisasjonen, så ein seinare lokasjon ikkje brukar om att ei blokk.

Gje kvar ruter éi tunneladresse

Tildel éin /128 per ruter og hald på dei eksisterande nøklane og endepunkta til huben som verkar. Dei tre verdiane nedanfor skil seg berre i vertsdelen.

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

Denne /128 skildrar den einaste adressa som er tildelt det grensesnittet. Ho seier ingenting om kor mange mål peeren kan rute, fordi nåbarheit vert uttrykt i AllowedIPs og ikkje i grensesnittprefikset.

Kvar lokasjonsruter treng òg ei adresse i LAN-blokka si og ein måte å distribuere ho på, vanlegvis ruterannonseringar for SLAAC. WireGuard sender ikkje desse annonseringane for deg, og det bruar ikkje dei to LAN-a. Lokasjonsruteren er ein ruter i båe retningar.

Legg subnett-eigarskapet i AllowedIPs

Peer-oppføringa til huben for Lokasjon A eig tunneladressa til A og LAN-et til A, og det paret er heile eigarskapserklæringa. Ingenting anna i den peer-delen treng å skildre lokasjonen.

AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64

Peer-oppføringa for Lokasjon B eig det tilsvarande paret, og symmetri tyder meir her enn stuttheit. Les dei to linjene saman, så vert eigarskapsfordelinga synleg med eitt blikk.

AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64

Dette er to separate peer-delar, ikkje to lister som kappast om éin peer. WireGuard brukar AllowedIPs i båe retningar: det vel peeren for ein utgåande destinasjon, og det avviser ein innkomande pakke der kjelda ikkje samsvarar med området som er tildelt peeren som dekrypterte han. Å gje heile /48 til båe peerane ville slå av den andre kontrollen og gjere det uklart kven lokasjon som eig kva blokk. Nettopp den skilnaden gjer ei feil kjeldeadresse synleg i staden for stille godteken.

Kvar lokasjon treng berre destinasjonane som er nåbare gjennom hub-peeren: Lokasjon A listar hub-adressa, tunneladressa til Lokasjon B og LAN-et til B, og Lokasjon B listar det motsette settet. Listene er asymmetriske med vilje, fordi kvar ruter ser ei anna side av topologien. Skriv båe frå adresseplanen og ikkje frå konfigurasjonen til den andre lokasjonen, for det er slik eit utdatert område overlever ei omnummerering.

Med wg-quick lagar desse områda òg ruter. Med systemd-networkd eller manuelt oppsett må du leggje til dei tilsvarande rutene sjølv; elles ber tunnelen pakkar som kjernen aldri sender inn i han.

Fullfør videresendinga og test båe retningar

Aktiver IPv6-videresending på huben og på båe lokasjonsruterane, og tillat dei naudsynte tenestene mellom lokasjonane i videresendingspolicyen. Hald ICMPv6 Packet Too Big-meldingar brukbare, fordi å droppe dei bryt path-MTU-oppdaginga og gjev store overføringsstopp som ser ut som applikasjonsfeil. Ein hub som videresender utan brannmur-tillatinga, droppar pakken mellom ruting og tunnel. Den feilmodusen er verd å kjenne, fordi tunnelen held seg oppe og berre nokre få flytar døyr.

sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1

Test frå ein vert på Lokasjon A til ein vert på Lokasjon B og deretter i motsett retning. Ein ping til tunneladressa til huben øver berre det første hoppet og vil lukkast sjølv når LAN-rutene er feil. Vert-til-vert-flyten er den som provar planen.

Den ytre WireGuard-tilkoplinga kan køyre over IPv4 medan den indre trafikken er IPv6, og den sjølvstendet er nyttig under migrering. Viss global IPv6-utgang vert lagd til seinare, må leverandørtildelinga, valet av kjeldeadresse og returrutinga vurderast på nytt som eit nytt designtrinn; den private planen ovanfor held fram med å gjelde for trafikk mellom lokasjonar.

Relaterte artiklar