WireGuard: ingen väg till peer efter ett subnätbyte — två vägar ut

Handskakningen är färsk i wg show, slutpunkten är rätt, nycklarna har aldrig ändrats — och ping säger fortfarande att det inte finns någon väg till peer. Du bytte tunnelns subnät för en timme sedan. Det symptomet är signaturen för ett prefixavvikelse och inte ett nyckelproblem: WireGuard slutförde handskakningen och kastade sedan datan eftersom en källadress inte längre matchar det som den mottagande peeren accepterar. Det finns två förnuftiga sätt att genomföra ett subnätbyte, och de fallerar på olika ställen.

Två sätt att genomföra ändringen, och vad varje kostar

Alternativ A är omnumrering på plats: redigera gränssnittsadressen, peer-intervallen, rutterna och varje kopia av konfigurationen, och ladda sedan om. Alternativ B är att bygga ett andra gränssnitt på det nya prefixet bredvid det gamla, flytta peerarna och ta bort det gamla gränssnittet när trafiken faktiskt har flyttat.

Det är det halvt tillämpade tillståndet som gör alternativ A farligt, eftersom det inte ser trasigt ut. Gränssnittet kommer upp, handskakningen lyckas och bara datavägen fallerar. Alternativ B kostar mer arbete men håller en fungerande väg vid liv medan du hittar varje referens.

Vad som måste flytta sig tillsammans på din sida

Fyra saker på den lokala värden beskriver samma subnät, och en ändring i en är en ändring i alla: gränssnittets adress, varje peers AllowedIPs, rutten systemet använder för dessa destinationer och allt som hanteraren installerar åt dig. Med wg-quick genereras de två sista från konfigurationen varje gång gränssnittet kommer upp, så en inaktuell kopia återinstallerar det gamla prefixet i tysthet.

Jämför det konfigurerade med det levande i stället för att lita på någon av dem:

wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5

Rutuppslaget är steget folk hoppar över. Det svarar på vad kärnan faktiskt skulle göra för en destination, inklusive en mer specifik rutt som en hanterare eller en container-runtime har lämnat kvar. Om det rapporterar ett annat gränssnitt än tunneln är konfigurationen inte problemet.

För ett gränssnitt som körs, tillämpa den redigerade filen utan att riva tunneln:

wg syncconf wg0 <(wg-quick strip wg0)

Det uppdaterar peers och intervall på plats. Det uppdaterar inte gränssnittsadressen eller rutterna, eftersom de inte är WireGuard-inställningar — så en omnumrering kräver fortfarande att gränssnittet skapas om eller att adressen ändras med ip, och därefter att routningen kontrolleras igen.

Vad som måste flytta sig tillsammans i den bortre änden

Det är här ett subnätbyte vanligtvis dör. AllowedIPs är inte bara en routningshint; det är också listan över källadresser en peer får presentera. När du omnumrerar klienter och låter serverns AllowedIPs stå kvar på det gamla prefixet accepterar servern handskakningen, tar emot de krypterade paketen och kastar dem eftersom den inre källan inte matchar något intervall den förknippar med den peeren. Ingen fel loggas och klienten ser en timeout.

Uppdatera därför mottagarsidan med avsikt: peer-posten på servern måste lista det nya klientprefixet, serverns egen returväg måste peka på tunneln för det prefixet, och varje nedströms nätverk bakom servern måste lära sig den nya vägen. Brandväggsregler som namngav det gamla intervallet behöver samma behandling, och detsamma gäller allt som gör källbaserat val.

Diagnostiken som skiljer de två felen är billig. En färsk handskakning utan data betyder att tunneln är uppe och att den inre adresseringen inte är överens. Ingen handskakning alls betyder att du tittar på nåbarhet eller nycklar. Rotera inte nycklar för ett prefixproblem; det nollställer det enda som fungerade.

Inaktuella kopior som överlever din redigering

Att redigera en fil är inte samma sak som att ändra det körande systemet, och kopiorna är fler än folk förväntar sig: enheten eller hanteraren som äger gränssnittet, en andra profil med samma namn i en annan katalog, en container med konfigurationen inbakad i en image, ett routergränssnitt med sin egen redigerade version och en klientapp som importerar en sparad tunnel igen vid start. Var och en av dem kan återställa det gamla prefixet efter att din ändring ser färdig ut.

Namn reser också. Om den numeriska rutten fungerar men värdnamnet misslyckas, pekar en intern DNS-post eller en tjänstekonfiguration fortfarande på den gamla tunneladressen. Rätta referensen i stället för att vidga varje peer-intervall, vilket skulle dölja det egentliga problemet och samtidigt förstora käll-ACL:en.

Håll en återställningsväg öppen medan du arbetar: ett andra sätt in på värden, en seriell konsol eller en schemalagd återrullning av konfigurationsfilerna. En tunneländring som låser dig ute från maskinen du ändrar är det vanligaste sättet den här uppgiften blir till en kväll.

Valet mellan de två, och verifiering av bytet

Välj A när du äger varje peer, antalet är litet och ett kort avbrott är acceptabelt. Välj B när peerarna är avlägsna händer du inte kontrollerar, när en länk mellan platser måste hållas uppe, eller när du inte kan garantera att varje kopia uppdateras i en enda omgång. I så fall lägg till det nya prefixet på båda gränssnitten, flytta peerarna en i taget, följ trafiken på det nya och ta först därefter bort det gamla gränssnittet och dess rutter.

Under båda alternativen är ändringen klar när fyra kontroller passerar: handskakningen är färsk, rutuppslaget för en destination på det nya prefixet namnger tunneln, en nyttlast på några hundra byte går i båda riktningarna, och detsamma gäller efter en omstart av värden eller hanteraren. Den wg(8)-handboken är referensen för vad AllowedIPs betyder i varje riktning, och den är värd att läsa om innan du vidgar ett intervall för att ett symptom ska försvinna.

• Färsk handskakning och ingen data: titta på AllowedIPs hos mottagaren innan du rör nycklarna.
• Rutuppslaget pekar på fel gränssnitt: en hanterare eller container äger rutten, inte din fil.
• Numerisk adress i ordning och värdnamn trasigt: en gammal referens, inte en routningsloop.
• Ändringen är först fullständig när en omstart fortfarande använder det nya prefixet.