Två WireGuard-peers delar ett intervall: vem får paketet

Två peers listar intervall som tangerar varandra, och trafiken når den felaktiga. Inget är skadat: WireGuard väljer en peer genom att matcha destinationen mot de konfigurerade intervallen, och den mest specifika matchningen vinner. Innan du breddar något ska du bestämma vilken peer som ska äga vilket prefix.

Det längsta prefixet vinner inuti WireGuard

Varje peer-post bär en uppsättning destinationsprefix. När ett paket routas in i gränssnittet letar implementationen efter posten med det mest specifika matchande prefixet — samma regel som en routingtabell tillämpar. Därför slår en /24 en /16 som innehåller den, och den smalare peeren tar emot trafiken.

Road-warrior-uppsättningar använder detta medvetet. En peer äger ett brett intervall för en plats, och enskilda värdar skärs ut med /32-poster som tillhör andra peers. Mönstret fungerar eftersom utskärningarna är mer specifika, inte på grund av ordningen.

Skriv ner ägandet som en tabell över prefix och peer. Om två poster beskriver samma prefix uttrycker konfigurationen inte längre en avsikt, den uttrycker en kapplöpning.

Operativsystemet väljer gränssnittet först

WireGuard väljer bara bland peerarna på ett gränssnitt. Vilket gränssnitt som tar emot paketet avgörs tidigare, av värdens routingtabell, och en andra standardrutt eller en inaktuell rutt kan skicka trafiken någonstans där peer-listan aldrig ser den. Det är därför en diagnos på peer-nivå kan vara korrekt och ändå inte förklara felet. Kontrollera rutten till destinationen innan du läser peer-konfigurationen, eftersom en rutt som pekar på det fysiska gränssnittet kringgår hela frågan.

Verktyget installerar vanligtvis dessa rutter från peer-intervallen, vilket innebär att en ändring i en peers lista tyst kan omdirigera trafik som tidigare tillhörde en annan. Att redigera en peer är därför en ruttändring i förklädnad. Granska båda samtidigt, annars reparerar du den ena och förstör den andra.

Inkommande paket kontrolleras efter källa

Intervallistan tjänar ett dubbelt syfte. För utgående trafik väljer den en peer efter destination, och för inkommande trafik auktoriserar den en källadress. Ett paket som anländer från en adress utanför den peerns intervall släpps innan någon brandvägg ser det.

Den asymmetrin är lätt att missa när man läser ena sidan av konfigurationen. En peer som kan nå ett subnät är inte därmed tillåten att skicka från det subnätet, och de två riktningarna upprätthålls av olika kontroller.

Smal källäganderätt gör detta till en fördel. Ge varje peer en /32 för sin egen adress och brandväggen nedanför har en pålitlig källa att matcha, i stället för ett intervall för hela gruppen som varje medlem skulle kunna göra anspråk på.

Dubblerade intervall är inte failover

Att tilldela samma prefix till två peers skapar ingen lastbalanserare eller standby-väg. Det finns ingen hälsokontroll och ingen sessionsaffinitet: posten som vinner avgörs av implementationens interna ordning, vilket inte är ett kontrakt man bör designa efter. Om du behöver alternativa utgångar ska du uttrycka dem där valet definieras. En routingpolicy, ett mått eller ett par olika prefix med dokumenterad ägare för varje ger beteende som du kan förutsäga och testa.

Att bredda ett intervall för att åtgärda ett orelaterat fel är det andra vanliga misstaget. Det flyttar trafik bort från peeren som fungerade, och det nya symptomet kommer innan det gamla har förståtts.

Verifiera valet innan du redigerar

Tre kommandon besvarar de tre frågorna i ordning. Den första listar intervallen som varje peer gör anspråk på. Den andra visar vilket gränssnitt värden skulle använda för en destination. Den tredje visar peerarnas livestatus efter att trafik har flödat.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

Kör dem före och efter en ändring och jämför. Om ruttutdata har ändrats men trafiken fortfarande når fel peer, överlappar prefixlistorna på ett sätt som du ännu inte har skrivit ner. Om ruttutdata inte har ändrats var peer-konfigurationen aldrig det som efterfrågades.

Anteckna destinationen, det valda gränssnittet och den valda peeren i ärendet. Den trion är det som gör en överlappning granskningsbar senare, och den är mycket mer användbar än en skärmdump av konfigurationen.