WireGuard-peer-grupper på hubben: källägande plus policy

En hubb som kör WireGuard kan hålla peer-grupper åtskilda utan ett separat gränssnitt eller routingtabell per grupp. Två mekanismer utför arbetet, och att blanda ihop dem är det vanliga skälet till att en policy ser korrekt ut och inte gör något. Ett lager avgör vem som får kräva en källadress. Det andra avgör vart det paketet får gå.

Två uppgifter, hållna åtskilda

Tunnellagret svarar på en smal fråga: auktoriserade den här peerns nyckel den här inre källadressen. Vidarebefordringslagret svarar på en bredare: får det här paketet lämna mot den destinationen. Ingen av dem svarar på den andras fråga, och ingen av dem är i sig en fullständig åtkomstpolicy.

Den uppdelningen är skälet till att en peer kan vara autentiserad, korrekt adresserad och ändå inte nå en värd som den inte borde nå. Den förklarar också det motsatta: en brandväggsregel som tillåter allt bevisar ingenting om vem som får kräva vilken adress.

Designa de två lagren tillsammans och testa sedan båda. En konfiguration som är korrekt i ett lager och otestad i det andra fallerar öppet eller stängt beroende på standardvärdet.

Ge varje peer bara dess egen adress

Peers med flera värdar frestar dig att tilldela hela gruppområdet på serversidan. Det tillståndet är ett anspråk på en källadress, så en komprometterad eller felkonfigurerad klient kan presentera vilken adress som helst i området och tunneln accepterar den. Tilldela en /32 per peer för dess egen inre adress. Sätt gruppområden bara på klienterna, där de beskriver vilka destinationer den klienten får nå i stället för vilka källor den får använda.

Brandväggen matchar då en källa som den kan lita på. En regel skriven för gruppens område är fortfarande en användbar gruppering, och den blir först meningsfull när ingen enskild peer kan kräva en adress som tillhör en annan medlem.

Skriv vidarebefordringspolicyn som skiljer grupper åt

Den intressanta trafiken går in och ut genom samma tunnelgränssnitt här, så den korsar vidarebefordringsvägen och inte värdens ingångsväg. Regler hör hemma i den befintliga vidarebefordringskedjan hos den brandväggshanterare som äger värden, och de är fragment, inte en komplett regeluppsättning.

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 två första reglerna tillåter trafik inom varje grupp. Den sista blockerar allt annat som korsar det gränssnittet, och det är det som skapar isolering mellan grupperna. Lägg till uttryckliga regler för den andra adressfamiljen om du behöver dem, för ett drop skrivet för IPv4 tillåter eller beskriver inte IPv6-beteende.

Ordningen avgör om policyn gäller

Regelordningen betyder mer än själva fragmentet. En generisk regel som accepterar upprättade anslutningar och står före dessa poster låter ett gammalt flöde mellan grupper fortsätta, så isoleringen gäller bara nya anslutningar. Bestäm vilket av de två utfallen du vill ha innan du läser in igen.

En acceptansdom är inte heller alltid slutgiltig mellan kedjor vid samma hook. Om en annan baskedja körs senare är den effektiva policyn kombinationen, så granska räknarna i stället för filen du redigerade. Räknarna är det billigaste beviset som finns. En regel utan paketräkning matchar inte, och en regel som matchar medan en senare kedja accepterar säger att droppen står på fel ställe.

Testa matrisen, inte filantalet

Bygg en liten matris med förväntade resultat och kontrollera varje cell. Grupp A till grupp A bör fungera, grupp B till grupp B bör fungera, och A till B bör inte, i båda riktningarna och för båda adressfamiljerna om du stöder 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 två första visar vad som är konfigurerat. Pinget från en medlem i fel grupp visar vad som faktiskt händer. conntrack-listan visar om ett äldre flöde fortfarande accepteras, och det är så en isoleringsändring tyst misslyckas med att träda i kraft.

Värdtjänster på hubben och åtkomst till ett LAN bakom den är separata vägar med separat policy. Notera vilka av dem matrisen täcker, för ett test som bara kontrollerar peer-till-peer-trafik säger ingenting om någon av dem.