Planlegging av IPv6 for et WireGuard-hub med to lokasjoner: prefiks, peere, ruter

To LAN, ett WireGuard-hub og en IPv6-adresseplan som må svare på tre separate spørsmål: hvilket prefiks, hvilken adresse som hører til hver ruter, og hvilken peer som eier hvilket subnett. Ett feil svar gir en tunnel som gjør håndtrykk og ikke ruter noe. Planen nedenfor går gjennom et privat design med to lokasjoner i den rekkefølgen. Den gir bevisst ikke internettilgang via IPv6.

Bestem hva prefikset skal brukes til

Et unikt lokalt prefiks fra fd00::/8 er det naturlige valget når målet er privat nåbarhet mellom lokasjoner. Det holder seg stabilt uansett hvilken leverandør som betjener hver lokasjon, og det annonseres ikke i den globale rutetabellen, så det kan ikke lekke den interne nummereringen din til internett.

Den samme egenskapen er begrensningen. En ULA gir ingen offentlig returvei, fordi ingen oppstrømsleverandør vet at den skal rutes til gatewayen din. Hvis kravet inkluderer internettutgang via IPv6, trenger du en tildeling fra en leverandør som ruter den til deg, og det er en egen designbeslutning med sin egen prefiksstørrelse.

Ikke anta at hver utrulling trenger et /48. RFC 6177 beveget seg bort fra én obligatorisk størrelse for endesonen, og riktig størrelse følger antallet nettverk du skal drifte. Generer ULA-en med RFC 4193-prosedyren i stedet for å finne opp et prefiks som en annen organisasjon også kan bruke. Skriv resultatet inn i adresseplanen før noen enhet konfigureres, for et prefiks som ingen har notert er et prefiks noen vil gjenbruke.

Del prefikset inn i roller

Eksempelet nedenfor bruker fd7c:2e91:4a00::/48, og tabellen er organisert etter hvor hver blokk skrives, ikke etter lokasjon. Behandle verdiene som et eksempel og generer dine egne før du ruller ut noe.

LAN-blokkene er /64 fordi vanlig SLAAC forventer en 64-bits grensesnittidentifikator. Å dele et LAN i en mindre blokk bryter den forutsetningen på de fleste verter, og driftskostnaden er ikke adressebesparelsen verdt i en privat plan. Begge LAN-blokkene kommer fra midten av /48 og lar det lave området være fritt for senere lokasjoner.

Tunneladressene er et administrativt forråd, ikke et nettverk på lenken. Hvert grensesnitt får én enkelt /128 fra det, så ingen vert antar et delt subnett på tunnelen, og nabo-oppdagelse kjører ikke der det ikke trengs. Hold rollene adskilt og registrer dem i organisasjonens adresseplan, så en senere lokasjon ikke gjenbruker en blokk.

Gi hver ruter én tunneladresse

Tildel én /128 per ruter og behold de eksisterende nøklene og endepunktene til huben som virker. De tre verdiene nedenfor skiller seg bare 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 beskriver den eneste adressen som er tildelt det grensesnittet. Den sier ingenting om hvor mange destinasjoner peeren kan rute, fordi nåbarhet uttrykkes i AllowedIPs og ikke i grensesnittprefikset.

Hver lokasjonsruter trenger også en adresse i sin LAN-blokk og en måte å distribuere den på, vanligvis ruterannonseringer for SLAAC. WireGuard sender ikke disse annonseringene for deg, og det broer ikke de to LAN-ene. Lokasjonsruteren er en ruter i begge retninger.

Legg subnett-eierskapet i AllowedIPs

Peer-oppføringen til huben for Lokasjon A eier tunneladressen til A og LAN-et til A, og det paret er hele eierskapserklæringen. Ingenting annet i den peer-delen trenger å beskrive lokasjonen.

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

Peer-oppføringen for Lokasjon B eier det tilsvarende paret, og symmetri betyr mer her enn korthet. Les de to linjene sammen, så blir eierskapsfordelingen synlig med ett blikk.

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

Dette er to separate peer-deler, ikke to lister som konkurrerer om én peer. WireGuard bruker AllowedIPs i begge retninger: det velger peeren for en utgående destinasjon, og det avviser en innkommende pakke hvis kilde ikke samsvarer med området som er tildelt peeren som dekrypterte den. Å gi hele /48 til begge peerne ville slå av den andre kontrollen og gjøre det uklart hvilken lokasjon som eier hvilken blokk. Nettopp den forskjellen gjør en feil kildeadresse synlig i stedet for stille akseptert.

Hver lokasjon trenger bare destinasjonene som er nåbare gjennom hub-peeren: Lokasjon A lister hub-adressen, tunneladressen til Lokasjon B og LAN-et til B, og Lokasjon B lister det motsatte settet. Listene er asymmetriske med vilje, fordi hver ruter ser en annen side av topologien. Skriv begge fra adresseplanen og ikke fra konfigurasjonen til den andre lokasjonen, for det er slik et utdatert område overlever en omnummerering.

Med wg-quick lager disse områdene også ruter. Med systemd-networkd eller manuelt oppsett må du legge til de tilsvarende rutene selv; ellers bærer tunnelen pakker som kjernen aldri sender inn i den.

Fullfør videresendingen og test begge retninger

Aktiver IPv6-videresending på huben og på begge lokasjonsruterne, og tillat de nødvendige tjenestene mellom lokasjonene i videresendingspolicyen. Hold ICMPv6 Packet Too Big-meldinger brukbare, fordi å droppe dem bryter path-MTU-oppdagelsen og gir store overføringsstopp som ser ut som applikasjonsfeil. Et hub som videresender uten brannmur-tillatelsen, dropper pakken mellom ruting og tunnel. Den feilmodusen er verdt å kjenne, fordi tunnelen holder seg oppe og bare noen få flyter dør.

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

Test fra en vert på Lokasjon A til en vert på Lokasjon B og deretter i motsatt retning. En ping til hubens tunneladresse øver bare det første hoppet og vil lykkes selv når LAN-rutene er feil. Vert-til-vert-flyten er den som beviser planen.

Den ytre WireGuard-forbindelsen kan kjøre over IPv4 mens den indre trafikken er IPv6, og den uavhengigheten er nyttig under migrering. Hvis global IPv6-utgang legges til senere, må leverandørtildelingen, valg av kildeadresse og returruting vurderes på nytt som et nytt designtrinn; den private planen ovenfor forblir gyldig for trafikk mellom lokasjoner.