WireGuard: ingen rute til peer etter subnettendring — to veier ut

Håndtrykket er nytt i wg show, endepunktet er korrekt, nøklene er aldri endret — likevel melder ping at det ikke er noen rute til peer. Du byttet tunnelens subnett for en time siden. Det symptomet er kjennetegnet på et prefiksavvik, ikke et nøkkelproblem: WireGuard fullførte håndtrykket og forkastet deretter dataene fordi en kildeadresse ikke lenger stemmer med det mottakende peeren godtar. Det finnes to fornuftige måter å få gjennomført en subnettendring, og de svikter på hvert sitt sted.

To måter å få endringen gjennomført, og hva hver koster

Alternativ A er omnummerering på stedet: endre grensesnittadressen, peer-områdene, rutene og hver kopi av konfigurasjonen, og last inn på nytt etterpå. Alternativ B er å sette opp et andre grensesnitt på det nye prefikset ved siden av det gamle, flytte peerne over og fjerne det gamle grensesnittet når trafikken faktisk har flyttet på seg.

Det er den halvferdige tilstanden som gjør alternativ A risikabel, fordi den ikke ser ødelagt ut. Grensesnittet kommer opp, håndtrykket lykkes, og bare datastien svikter. Alternativ B krever mer arbeid, men holder en fungerende sti oppe mens du finner hver referanse.

Hva som må flyttes samtidig på din side

Fire ting på den lokale maskinen beskriver det samme subnettet, og en endring i én er en endring i alle: grensesnittadressen, AllowedIPs for hver peer, ruten systemet bruker mot disse destinasjonene, og det manageren installerer på dine vegne. Med wg-quick genereres de to siste fra konfigurasjonen hver gang grensesnittet kommer opp, så en foreldet kopi gjenoppretter det gamle prefikset uten et ord.

Sammenlign det som er konfigurert med det som lever, i stedet for å tro på én av dem:

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

Ruteoppslaget er trinnet folk hopper over. Det svarer på hva kjernen faktisk ville gjort mot en destinasjon, også en mer spesifikk rute som en manager eller en container-runtime har etterlatt. Rapporterer det et annet grensesnitt enn tunnelen, er ikke konfigurasjonen problemet.

På et grensesnitt som kjører, bruk den endrede filen uten å rive ned tunnelen:

wg syncconf wg0 <(wg-quick strip wg0)

Det oppdaterer peere og områder på stedet. Det oppdaterer ikke grensesnittadressen eller rutene, siden de ikke er WireGuard-innstillinger — en omnummerering krever derfor fortsatt at grensesnittet gjenskapes eller at adressen endres med ip, og at rutingen deretter kontrolleres på nytt.

Hva som må flyttes samtidig i den andre enden

Det er her en subnettendring som regel dør. AllowedIPs er ikke bare et rutehint; det er også listen over kildeadresser en peer har lov til å presentere. Når du omnummererer klienter og lar serverens AllowedIPs stå på det gamle prefikset, godtar serveren håndtrykket, mottar de krypterte pakkene og forkaster dem fordi den indre kilden ikke stemmer med noe område den knytter til den peeren. Ingen feil loggføres, og klienten ser en tidsavbrudd.

Oppdater derfor mottakersiden med vilje: peer-oppføringen på serveren må liste det nye klientprefikset, serverens egen returrute må peke mot tunnelen for det prefikset, og ethvert nettverk nedstrøms bak serveren må lære den nye stien. Brannmurregler som navnga det gamle området trenger samme behandling, og det samme gjelder alt som gjør kildebaserte valg.

Diagnostikken som skiller de to feilene er billig. Et nytt håndtrykk uten data betyr at tunnelen er oppe og at den indre adresseringen ikke er enig. Helt fravær av håndtrykk betyr at du ser på tilgjengelighet eller nøkler. Ikke ruller nøkler for et prefiksproblem; det nullstiller det eneste som fungerte.

Foreldede kopier som overlever endringen din

Å endre en fil er ikke det samme som å endre det kjørende systemet, og kopiene er flere enn folk regner med: enheten eller manageren som eier grensesnittet, en annen profil med samme navn i en annen mappe, en container med konfigurasjonen bakt inn i et image, et rutergrensesnitt med sin egen endrede versjon og en klientapp som importerer en lagret tunnel på nytt ved oppstart. Hver av dem kan gjenopprette det gamle prefikset etter at endringen din ser ferdig ut.

Navn reiser også. Virker den numeriske ruten men vertsnavnet svikter, peker en intern DNS-oppføring eller en tjenestekonfigurasjon fortsatt mot den gamle tunneladressen. Rett referansen i stedet for å utvide hvert peer-område, for det ville skjule det egentlige problemet og samtidig gjøre kilde-ACL-en større.

Hold én gjenopprettingsvei åpen mens du jobber: en annen vei inn på maskinen, en seriell konsoll eller en planlagt tilbakerulling av konfigurasjonsfilene. En tunnelendring som låser deg ute fra maskinen du endrer, er den vanligste grunnen til at denne oppgaven blir en hel kveld.

Valget mellom de to, og verifisering av overgangen

Velg A når du eier hver peer, antallet er lite og et kort avbrudd er akseptabelt. Velg B når peerne er fjerne hender du ikke styrer, når en lenke mellom to steder må holdes oppe, eller når du ikke kan garantere at hver kopi blir oppdatert i én runde. I så fall legger du det nye prefikset på begge grensesnittene, flytter peerne én av gangen, følger med på trafikken på det nye, og fjerner først da det gamle grensesnittet med rutene sine.

Uansett alternativ er endringen ferdig når fire kontroller er grønne: håndtrykket er nytt, ruteoppslaget mot en destinasjon på det nye prefikset navngir tunnelen, en nyttelast på noen hundre byte går begge veier, og det samme gjelder etter en omstart av maskinen eller manageren. Den wg(8)-håndboken er referansen for hva AllowedIPs betyr i hver retning, og den er verdt å lese på nytt før du utvider et område for å få et symptom til å forsvinne.

• Nytt håndtrykk og ingen data: se på AllowedIPs hos mottakeren før du tar på nøklene.
• Ruteoppslaget peker på feil grensesnitt: en manager eller container eier ruten, ikke filen din.
• Numerisk adresse i orden og vertsnavn ødelagt: en gammel referanse, ikke en rutingløkke.
• Endringen er først fullstendig når en omstart fortsatt bruker det nye prefikset.