WireGuard-peergroepen op de hub: bronbezit plus beleid

Een hub waarop WireGuard draait, kan peergroepen gescheiden houden zonder een aparte interface of routingtabel per groep. Twee mechanismen doen het werk, en ze door elkaar halen is de gebruikelijke reden dat een beleid correct lijkt en niets doet. De ene laag bepaalt wie een bronadres mag claimen. De andere bepaalt waar dat pakket mag heen gaan.

Twee taken, gescheiden gehouden

De tunnellaag beantwoordt een smalle vraag: heeft de sleutel van deze peer dit interne bronadres geautoriseerd. De doorstuurlaag beantwoordt een bredere: mag dit pakket richting die bestemming vertrekken. Geen van beide beantwoordt de vraag van de ander, en geen van beide is op zichzelf een volledig toegangsbeleid.

Die splitsing is de reden dat een peer geauthenticeerd en correct geadresseerd kan zijn en toch een host niet kan bereiken die hij niet zou moeten bereiken. Ze verklaart ook het omgekeerde: een firewallregel die alles toestaat bewijst niets over wie welk adres mag claimen.

Ontwerp de twee lagen samen en test daarna beide. Een configuratie die in de ene laag correct is en in de andere ongetest, faalt open of dicht afhankelijk van de standaardwaarde.

Geef elke peer alleen zijn eigen adres

Peers met meerdere hosts verleiden je ertoe aan de serverkant het hele groepsbereik toe te kennen. Die toestemming is een claim op een bronadres, dus een gecompromitteerde of verkeerd geconfigureerde client kan elk adres in het bereik voorleggen en de tunnel accepteert het. Wijs per peer een /32 toe voor zijn eigen interne adres. Stel groepsbereiken alleen op de clients in, waar ze beschrijven welke bestemmingen die client mag bereiken in plaats van welke bronnen hij mag gebruiken.

De firewall vergelijkt dan een bron die hij kan vertrouwen. Een regel die voor het groepsbereik is geschreven blijft een nuttige groepering, en ze wordt pas betekenisvol wanneer geen enkele peer een adres kan claimen dat bij een ander lid hoort.

Schrijf het doorstuurbeleid dat groepen scheidt

Het interessante verkeer komt hier binnen en gaat eruit via dezelfde tunnelinterface, dus het kruist het doorstuurpad en niet het invoerpad van de host. Regels horen in de bestaande doorstuurketen van welke firewallbeheerder de host dan ook bezit, en het zijn fragmenten, geen volledige regelset.

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 eerste twee regels staan verkeer binnen elke groep toe. De laatste blokkeert al het andere dat die interface kruist, en dat is wat de isolatie tussen de groepen oplevert. Voeg expliciete regels voor de andere adresfamilie toe als je ze nodig hebt, want een drop die voor IPv4 is geschreven staat IPv6-gedrag niet toe en beschrijft het ook niet.

De volgorde bepaalt of het beleid geldt

De regelvolgorde is belangrijker dan het fragment zelf. Een generieke regel die bestaande verbindingen accepteert en vóór deze vermeldingen staat, laat een oude stroom tussen groepen doorlopen, dus de isolatie geldt alleen voor nieuwe verbindingen. Beslis welke van die twee uitkomsten je wilt voordat je herlaadt.

Een acceptatie-uitspraak is ook niet altijd definitief over ketens heen bij dezelfde hook. Als een andere basisketen later draait, is het effectieve beleid de combinatie, dus inspecteer de tellers in plaats van het bestand dat je hebt bewerkt. Tellers zijn het goedkoopste beschikbare bewijs. Een regel zonder pakketteller matcht niet, en een regel die matcht terwijl een latere keten accepteert, vertelt je dat de drop op de verkeerde plaats staat.

Test de matrix, niet het aantal bestanden

Bouw een kleine matrix van verwachte resultaten en controleer elke cel. Groep A naar groep A zou moeten werken, groep B naar groep B zou moeten werken, en A naar B niet, in beide richtingen en voor beide adresfamilies als je die ondersteunt.

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 eerste twee laten zien wat er geconfigureerd is. De ping vanaf een lid van de verkeerde groep laat zien wat er werkelijk gebeurt. De conntrack-lijst laat zien of een oudere stroom nog wordt geaccepteerd, en zo slaagt een isolatiewijziging er stilzwijgend niet in van kracht te worden.

Hostdiensten op de hub en toegang tot een LAN erachter zijn aparte paden met apart beleid. Noteer welke ervan de matrix dekt, want een test die alleen peer-naar-peer-verkeer controleert zegt niets over geen van beide.