IPv6-planning foar in WireGuard-hub mei twa lokaasjes: prefiks, peers, rûtes
Wurkje in privee IPv6-hub foar twa LAN's troch: kies in prefiks, reservearje tunneladressen en lit AllowedIPs dan útdrukke hokker peer hokker subnet besit.
Twa LAN's, ien WireGuard-hub en in IPv6-adresplan dat trije aparte fragen beantwurdzje moat: hokker prefiks, hokker adres by elke router heart en hokker peer hokker subnet besit. Ien ferkeard antwurd jout in tunnel dy't in hânskud docht en neat rûtet. It plan hjirûnder rint in privee ûntwerp mei twa lokaasjes yn dy folchoarder troch. It jout mei opsetsin gjin IPv6-ynternettagong.
Beslis wêr't it prefiks foar is
In unyk lokaal prefiks út fd00::/8 is de natuerlike kar as it doel privee berikberens tusken lokaasjes is. It bliuwt stabyl, hokker provider ek elke lokaasje betsjinnet, en it wurdt net oankundige yn 'e globale rûtingstabel, sadat it jo ynterne nûmering net nei it ynternet lekke kin.
Deselde eigenskip is de beheining. In ULA jout gjin iepenbiere weromweis, om't gjin upstream wit dat er it nei jo gateway rûtsje moat. As de eask IPv6-ynternetútgong omfettet, hawwe jo nedich in tawizing fan in provider dy't it nei jo rûtet, en dat is in aparte ûntwerpbeslissing mei syn eigen prefiksgrutte.
Tink net dat elke útrulling in /48 nedich hat. RFC 6177 gyng fuort fan ien ferplichte einlokaasjegrutte, en de juste grutte folget it oantal netwurken dat jo betsjinje sille. Generearje de ULA mei de RFC 4193-proseduere ynstee fan in prefiks te betinken dat in oare organisaasje ek brûke kin. Skriuw it resultaat yn it adresplan foardat ien apparaat konfigurearre wurdt, want in prefiks dat nimmen fêstlein hat is in prefiks dat immen wer brûke sil.
Diel it prefiks yn rollen op
It foarbyld hjirûnder brûkt fd7c:2e91:4a00::/48, en de tabel is oardere nei wêr't elk blok skreaun wurdt, net nei lokaasje. Behannelje de wearden as in foarbyld en generearje jo eigen foardat jo eat útrôlje.
| 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 |
De LAN-blokken binne /64 om't gewoane SLAAC in 64-bits ynterface-identifikaasje ferwachtet. In LAN yn in lytser blok opdiele brekt dy oanname op 'e measte hosts, en de operasjonele kosten binne de adresbesparring yn in privee plan net wurdich. Beide LAN-blokken komme út 'e midden fan 'e /48, wêrtroch it lege berik frij bliuwt foar lettere lokaasjes.
De tunneladressen binne in bestjoerlike foarried, gjin netwurk op 'e keppeling. Elk ynterface krijt dêr ien /128 fan, sadat gjin host in dield subnet op 'e tunnel oannimt en buorlju-ûntdekking net rint wêr't it net nedich is. Hâld de rollen skieden en registrearje se yn it adresplan fan 'e organisaasje, sadat in lettere lokaasje gjin blok wer brûkt.
Jou elke router ien tunneladres
Tawize ien /128 per router en behâld de besteande kaaien en einpunten fan 'e wurkjende hub. De trije wearden hjirûnder ferskille allinnich yn it hostdiel.
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/128Dit /128 beskriuwt it iene adres dat oan dat ynterface tawiisd is. It seit neat oer hoefolle bestimmingen de peer rûtsje mei, om't berikberens yn AllowedIPs útdrukt wurdt en net yn it ynterfaceprefiks.
Elke lokaasjerouter hat ek in adres yn syn LAN-blok nedich en in manier om it te fersprieden, meast routerankundigings foar SLAAC. WireGuard stjoert dy ankundigings net foar jo en brêget de twa LAN's net. De lokaasjerouter is in router yn beide rjochtingen.
Set it eigendom fan it subnet yn AllowedIPs
De peer-yngong fan 'e hub foar Lokaasje A besit it tunneladres fan A en it LAN fan A, en dat pear is de hiele eigendomsferklearring. Neat oars yn dat peer-seksje hoecht de lokaasje te beskriuwen.
AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64De peer-yngong foar Lokaasje B besit it byhearrende pear, en symmetry is hjir wichtiger as koartens. Lês de twa rigels byinoar en de eigendomsferdieling wurdt yn ien eachopslach sichtber.
AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64Dit binne twa aparte peer-seksjes, net twa listen dy't om ien peer stride. WireGuard brûkt AllowedIPs yn beide rjochtingen: it kiest de peer foar in útgongbestimming en it wiist in ynkommend pakket ôf wêrfan't de boarne net oerienkomt mei it berik dat tawiisd is oan 'e peer dy't it ûntsifere hat. It hiele /48 oan beide peers jaan soe dy twadde kontrôle útsette en ferdizelje hokker lokaasje hokker blok besit. Krekt dat ûnderskie makket in ferkeard boarstadres sichtber ynstee fan stilwei akseptearre.
Elke lokaasje hat allinnich de bestimmingen nedich dy't fia syn hub-peer berikber binne: Lokaasje A listet it hubadres, it tunneladres fan Lokaasje B en it LAN fan B, en Lokaasje B listet de omkearde set. De listen binne mei opsetsin asymmetrysk, om't elke router in oare kant fan 'e topology sjocht. Skriuw beide út it adresplan en net út 'e konfiguraasje fan 'e oare lokaasje, want sa oerlibbet in ferâldere berik in wernûmering.
Mei wg-quick meitsje dizze berikken ek rûtes. Mei systemd-networkd of in hânmjittige opset moatte jo de lykweardige rûtes sels tafoegje; oars draacht de tunnel pakketten dy't de kernel der nea yn stjoert.
Foltôgje it trochstjoeren en test beide rjochtingen
Skeakel IPv6-trochstjoeren yn op 'e hub en op beide lokaasjerouters, en stean de nedige tsjinsten tusken lokaasjes ta yn it trochstjoerbelied. Hâld ICMPv6 Packet Too Big-berjochten brûkber, want se fuortsmite brekt it ûntdekken fan it paad-MTU en soarget foar stilstân by grutte oerdrachten dy't op applikaasjeflaters lykje. In hub dy't trochstjoert sûnder de firewalltastimming smyt it pakket tusken rûting en de tunnel fuort. Dy flatemodus is de muoite wurdich te kennen, want de tunnel bliuwt oerein en allinnich guon streamen stjerre.
sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1Test fan in host yn Lokaasje A nei in host yn Lokaasje B en dan yn 'e tsjinoerstelde rjochting. In ping nei it tunneladres fan 'e hub oefenet allinnich de earste hop en sil slagje sels as de LAN-rûtes ferkeard binne. De stream fan host nei host is dejinge dy't it plan bewissiget.
De bûtenste WireGuard-ferbining kin oer IPv4 rinne wylst it binnenste ferkear IPv6 is, en dy ûnôfhinklikheid is nuttich by migraasje. As letter globale IPv6-útgong tafoege wurdt, besjoch dan de tawizing fan 'e provider, de kar fan boarstadres en de weromrûting as in nije ûntwerpstap; it privee plan hjirboppe bliuwt jildich foar ferkear tusken lokaasjes.