WireGuard-peer-grupper på hubben: kildeejerskab plus politik

En hub, der kører WireGuard, kan holde peer-grupper adskilt uden en separat grænseflade eller routingtabel pr. gruppe. To mekanismer udfører arbejdet, og forveksling af dem er den sædvanlige grund til, at en politik ser korrekt ud og ikke gør noget. Det ene lag afgør, hvem der må kræve en kildeadresse. Det andet afgør, hvor pakken må hen.

To opgaver, holdt adskilt

Tunnellaget svarer på et snævert spørgsmål: autoriserede denne peers nøgle denne indre kildeadresse. Videresendelseslaget svarer på et bredere: må denne pakke forlade mod den destination. Ingen af dem besvarer den andens spørgsmål, og ingen af dem er alene en fuldstændig adgangspolitik.

Den opdeling er grunden til, at en peer kan være autentificeret, korrekt adresseret og alligevel ikke kunne nå en vært, den ikke bør nå. Det forklarer også det modsatte: en firewallregel, der tillader alt, beviser intet om, hvem der må kræve hvilken adresse.

Design de to lag sammen, og test derefter begge. En konfiguration, der er korrekt i det ene lag og utestet i det andet, fejler åbent eller lukket afhængigt af standarden.

Giv hver peer kun sin egen adresse

Peers med flere værter frister dig til at tildele hele gruppeområdet på serversiden. Den tilladelse er et krav på en kildeadresse, så en kompromitteret eller fejlkonfigureret klient kan fremvise enhver adresse i området, og tunnelen accepterer den. Tildel en /32 pr. peer til dens egen indre adresse. Sæt gruppeområder kun på klienterne, hvor de beskriver hvilke destinationer den klient må nå i stedet for hvilke kilder den må bruge.

Firewallen matcher derefter en kilde, den kan stole på. En regel skrevet til gruppens område er stadig en nyttig gruppering, og den bliver først meningsfuld, når ingen enkelt peer kan kræve en adresse, der tilhører et andet medlem.

Skriv videresendelsespolitikken, der adskiller grupperne

Den interessante trafik her går ind og ud gennem den samme tunnelgrænseflade, så den krydser videresendelsesvejen i stedet for værtens indgangsvej. Regler hører til i den eksisterende videresendelseskæde hos den firewall-manager, der ejer værten, og de er fragmenter, ikke et komplet regelsæt.

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

De to første regler tillader trafik inden for hver gruppe. Den sidste blokerer alt andet, der krydser den grænseflade, og det er det, der skaber isolering mellem grupperne. Tilføj eksplicitte regler for den anden adressefamilie, hvis du har brug for dem, for et drop skrevet til IPv4 tillader eller beskriver ikke IPv6-adfærd.

Rækkefølgen afgør, om politikken gælder

Regelrækkefølgen betyder mere end selve fragmentet. En generisk regel, der accepterer etablerede forbindelser og står før disse poster, lader en gammel krydsgruppe-flow fortsætte, så isoleringen gælder kun nye forbindelser. Beslut, hvilket af de to udfald du vil have, før du genindlæser.

En accept-afgørelse er heller ikke altid endelig på tværs af kæder ved samme hook. Hvis en anden basiskæde kører senere, er den effektive politik kombinationen, så undersøg tællerne i stedet for den fil, du redigerede. Tællerne er det billigste tilgængelige bevis. En regel uden pakketælling matcher ikke, og en regel, der matcher, mens en senere kæde accepterer, fortæller dig, at droppet er det forkerte sted.

Test matricen, ikke filantallet

Byg en lille matrix af forventede resultater, og kontroller hver celle. Gruppe A til gruppe A bør virke, gruppe B til gruppe B bør virke, og A til B bør ikke, i begge retninger og for begge adressefamilier, hvis du understøtter dem.

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

De to første viser, hvad der er konfigureret. Pinget fra et medlem af den forkerte gruppe viser, hvad der faktisk sker. conntrack-listen viser, om en ældre flow stadig accepteres, og det er sådan en isoleringsændring stille undlader at træde i kraft.

Værtstjenester på hubben og adgang til et LAN bag den er separate veje med separat politik. Noter, hvilke af dem matricen dækker, for en test, der kun kontrollerer peer-til-peer-trafik, siger intet om nogen af dem.