WireGuard-peer-grupper på huben: kildeeierskap pluss policy

En hub som kjører WireGuard kan holde peer-grupper atskilt uten et eget grensesnitt eller rutingtabell per gruppe. To mekanismer gjør arbeidet, og å blande dem er den vanlige grunnen til at en policy ser riktig ut og ikke gjør noe. Ett lag avgjør hvem som kan kreve en kildeadresse. Det andre avgjør hvor den pakken har lov til å gå.

To oppgaver, holdt atskilt

Tunnellaget svarer på et smalt spørsmål: autoriserte nøkkelen til denne peer-en denne indre kildeadressen. Videresendingslaget svarer på et bredere: har denne pakken lov til å gå ut mot den destinasjonen. Ingen av dem svarer på den andres spørsmål, og ingen av dem er alene en fullstendig tilgangspolicy.

Den delingen er grunnen til at en peer kan være autentisert, riktig adressert og likevel ikke nå en vert den ikke burde nå. Det forklarer også det motsatte: en brannmurregel som tillater alt, beviser ingenting om hvem som kan kreve hvilken adresse.

Design de to lagene sammen, og test deretter begge. En konfigurasjon som er riktig i ett lag og utestet i det andre, feiler åpent eller lukket avhengig av standardverdien.

Gi hver peer bare sin egen adresse

Peers med flere verter frister deg til å gi hele gruppeområdet på serversiden. Den tillatelsen er et krav på en kildeadresse, så en kompromittert eller feilkonfigurert klient kan presentere hvilken som helst adresse i området, og tunnelen godtar den. Tildel en /32 per peer for dens egen indre adresse. Sett gruppeområder bare på klientene, der de beskriver hvilke destinasjoner den klienten kan nå i stedet for hvilke kilder den kan bruke.

Brannmuren matcher da en kilde den kan stole på. En regel skrevet for gruppeområdet er fortsatt en nyttig gruppering, og den blir først meningsfull når ingen enkelt peer kan kreve en adresse som tilhører et annet medlem.

Skriv videresendingspolicyen som skiller grupper

Den interessante trafikken går inn og ut gjennom det samme tunnelgrensesnittet her, så den krysser videresendingsveien og ikke vertens inngangsvei. Regler hører hjemme i den eksisterende videresendingskjeden til den brannmurbehandleren som eier verten, og de er fragmenter, ikke et komplett regelsett.

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 reglene tillater trafikk innenfor hver gruppe. Den siste blokkerer alt annet som krysser det grensesnittet, og det er det som skaper isolasjon mellom gruppene. Legg til eksplisitte regler for den andre adressefamilien hvis du trenger dem, for en drop skrevet for IPv4 verken autoriserer eller beskriver IPv6-atferd.

Rekkefølgen avgjør om policyen gjelder

Regelrekkefølgen betyr mer enn selve fragmentet. En generisk regel som godtar etablerte forbindelser og står før disse oppføringene, lar en gammel flyt mellom grupper fortsette, så isolasjonen gjelder bare nye forbindelser. Bestem deg for hvilket av de to utfallene du vil ha før du laster inn på nytt.

En akseptavgjørelse er heller ikke alltid endelig på tvers av kjeder ved samme hook. Hvis en annen basiskjede kjører senere, er den effektive policyen kombinasjonen, så undersøk tellerne i stedet for filen du redigerte. Tellerne er det billigste beviset som finnes. En regel uten pakketelling matcher ikke, og en regel som matcher mens en senere kjede godtar, forteller deg at dropen står på feil sted.

Test matrisen, ikke filantallet

Bygg en liten matrise med forventede resultater og kontroller hver celle. Gruppe A til gruppe A skal virke, gruppe B til gruppe B skal virke, og A til B skal ikke, i begge retninger og for begge adressefamilier hvis du stø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 hva som er konfigurert. Ping fra et medlem av feil gruppe viser hva som faktisk skjer. conntrack-listen viser om en eldre flyt fortsatt godtas, og det er slik en isolasjonsendring stille ikke trer i kraft.

Vertstjenester på huben og tilgang til et LAN bak den er separate veier med separat policy. Noter hvilke av dem matrisen dekker, for en test som bare kontrollerer peer-til-peer-trafikk sier ingenting om noen av dem.