WireGuard: ingen rute til peer efter et subnet-skift — to veje ud

Håndtrykket er frisk i wg show, endpointet er rigtigt, nøglerne er aldrig ændret — og ping siger stadig ingen rute til peer. Du ændrede tunnelens subnet for en time siden. Det symptom er signaturen på et præfiks-mismatch snarere end et nøgleproblem: WireGuard gennemførte håndtrykket og droppede derefter dataene, fordi en kildeadresse ikke længere matcher det, den modtagende peer vil acceptere. Der er to fornuftige måder at lande et subnet-skift på, og de fejler forskellige steder.

To måder at lande ændringen på, og hvad hver koster

Mulighed A er omnummerering på stedet: rediger interfaceadressen, peer-intervallerne, ruterne og enhver kopi af konfigurationen, og genindlæs derefter. Mulighed B er at bygge et andet interface på det nye præfiks ved siden af det gamle, flytte peers over og fjerne det gamle interface, når trafikken faktisk er flyttet.

Den halvt anvendte tilstand er det, der gør mulighed A farlig, fordi den ikke ser brudt ud. Interfacet kommer op, håndtrykket lykkes, og kun datastien fejler. Mulighed B koster mere arbejde, men holder en fungerende sti i live, mens du finder hver reference.

Hvad der skal flytte sig sammen på din ende

Fire ting på værten beskriver det samme subnet, og en ændring af én er en ændring af alle: interfacets adresse, hver peers AllowedIPs, den rute systemet bruger til de destinationer, og hvad manageren end installerer på dine vegne. Med wg-quick genereres de to sidste ud fra konfigurationen, hver gang interfacet kommer op, så en forældet kopi lydløst geninstallerer det gamle præfiks.

Sammenlign det konfigurerede med det levende i stedet for at stole på nogen af dem:

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

Ruteopslaget er det, folk springer over. Det svarer på, hvad kernen faktisk ville gøre for en destination, inklusive en mere specifik rute, som en manager eller en container-runtime har efterladt. Hvis det rapporterer et andet interface end tunnelen, er konfigurationen ikke problemet.

For et kørende interface kan du anvende den redigerede fil uden at rive tunnelen ned:

wg syncconf wg0 <(wg-quick strip wg0)

Det opdaterer peers og intervaller på stedet. Det opdaterer ikke interfaceadressen eller ruterne, fordi de ikke er WireGuard-indstillinger — så en omnummerering kræver stadig, at interfacet genskabes, eller at adressen ændres med ip, og derefter at routing kontrolleres igen.

Hvad der skal flytte sig sammen i den fjerne ende

Det er her, et subnet-skift normalt dør. AllowedIPs er ikke kun et routing-vink; det er også listen over kildeadresser, en peer må præsentere. Når du omnummererer klienter og lader serverens AllowedIPs stå på det gamle præfiks, accepterer serveren håndtrykket, modtager de krypterede pakker og kasserer dem, fordi kilden indeni ikke matcher noget interval, den forbinder med den peer. Der logges ingen fejl, og klienten ser en timeout.

Så opdater modtagersiden med vilje: peer-posten på serveren skal liste klientens nye præfiks, serverens egen returrute skal pege på tunnelen for det præfiks, og ethvert nedstrøms netværk bag serveren skal lære den nye sti. Firewallpolitik, der navngav det gamle interval, skal have samme behandling, og det samme skal alt, der laver kildebaseret valg.

Den diagnostik, der adskiller de to fejl, er billig. Et nyligt håndtryk uden data betyder, at tunnelen er oppe, og at den indre adressering er uenig. Slet intet håndtryk betyder, at du kigger på nåbarhed eller nøgler. Roter ikke nøgler for et præfiksproblem; det nulstiller det eneste, der virkede.

Forældede kopier, der overlever din redigering

At redigere en fil er ikke det samme som at ændre det kørende system, og kopierne er flere, end folk forventer: den unit eller manager, der ejer interfacet, en anden profil med samme navn i en anden mappe, en container med sin konfiguration bagt ind i et image, en router-UI med sin egen redigerede version og en klientapp, der genimporterer en gemt tunnel ved opstart. Hver af dem kan gendanne det gamle præfiks, efter din ændring ser færdig ud.

Navne rejser også. Hvis den numeriske rute virker, men værtsnavnet fejler, peger en intern DNS-post eller en tjenestekonfiguration stadig på den gamle tunneladresse. Ret referencen i stedet for at udvide hvert peer-interval, hvilket ville dække over det egentlige problem og samtidig forstørre kilde-ACL'en.

Hold én gendannelsesvej åben, mens du arbejder: en anden vej ind på værten, en seriel konsol eller en planlagt tilbagerulning af konfigurationsfilerne. En tunnelændring, der låser dig ude af den maskine, du ændrer, er den mest almindelige måde, denne opgave bliver til en aften.

Valget mellem de to, og verifikation af skiftet

Vælg A, når du ejer hver peer, antallet er lille, og et kort udfald er acceptabelt. Vælg B, når peers er fjerne hænder, du ikke styrer, når et site-til-site-link skal blive oppe, eller når du ikke kan garantere, at hver kopi bliver opdateret i ét gennemløb. I så fald tilføj det nye præfiks til begge interfaces, flyt peers én ad gangen, hold øje med trafikken på det nye, og fjern først derefter det gamle interface og dets ruter.

Under begge muligheder er ændringen færdig, når fire kontroller består: håndtrykket er nyligt, ruteopslaget for en destination på det nye præfiks nævner tunnelen, en nyttelast på et par hundrede bytes overføres i begge retninger, og det samme gælder efter en genstart af værten eller manageren. Den wg(8)-manualen er referencen for, hvad AllowedIPs betyder i hver retning, og den er værd at læse igen, før du udvider et interval for at få et symptom til at forsvinde.

• Nyligt håndtryk og ingen data: se på AllowedIPs hos modtageren, før du rører nøglerne.
• Ruteopslag peger på det forkerte interface: en manager eller container ejer ruten, ikke din fil.
• Numerisk adresse i orden og værtsnavn i stykker: en gammel reference, ikke en routing-løkke.
• Ændringen er først fuldført, når en genstart stadig bruger det nye præfiks.