WireGuard: ingen rute til peer etter et subnettbytte — to veier ut

Håndtrykket er ferskt i wg show, endepunktet er riktig, nøklene er aldri endret — og ping sier fortsatt at det ikke finnes noen rute til peer. Du endret tunnelens subnett for en time siden. Det symptomet er signaturen til et prefiksavvik og ikke et nøkkelproblem: WireGuard fullførte håndtrykket og slapp deretter dataene fordi en kildeadresse ikke lenger samsvarer med det den mottakende peeren vil godta. Det finnes to fornuftige måter å gjennomføre et subnettbytte på, og de feiler på forskjellige steder.

To måter å gjennomføre endringen på, og hva hver koster

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

Den halvt anvendte tilstanden er det som gjør alternativ A farlig, fordi den ikke ser ødelagt ut. Grensesnittet kommer opp, håndtrykket lykkes, og bare datastien feiler. Alternativ B koster mer arbeid, men holder en fungerende sti i live mens du finner hver referanse.

Hva som må flytte seg sammen på din side

Fire ting på den lokale verten beskriver det samme subnettet, og en endring i én er en endring i alle: grensesnittadressen, hver peers AllowedIPs, ruten systemet bruker for disse destinasjonene, og alt manageren installerer på dine vegne. Med wg-quick genereres de to siste fra konfigurasjonen hver gang grensesnittet kommer opp, så en utdatert kopi gjeninstallerer det gamle prefikset i stillhet.

Sammenlign det konfigurerte med det levende i stedet for å stole på noen 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 gjøre for en destinasjon, inkludert en mer spesifikk rute som en manager eller en container-runtime har lagt igjen. Hvis det rapporterer et annet grensesnitt enn tunnelen, er ikke konfigurasjonen problemet.

For et kjørende grensesnitt, bruk den redigerte 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, fordi de ikke er WireGuard-innstillinger — så en omnummerering trenger fortsatt at grensesnittet gjenskapes eller at adressen endres med ip, og deretter at rutingen kontrolleres på nytt.

Hva som må flytte seg sammen i den fjerne enden

Det er her et subnettbytte vanligvis 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 kilden inni ikke samsvarer med noe område den knytter til den peeren. Ingen feil logges, og klienten ser en tidsavbrudd.

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

Diagnostikken som skiller de to feilene er billig. Et nylig håndtrykk uten data betyr at tunnelen er oppe og at den indre adresseringen ikke er enig. Ingen håndtrykk i det hele tatt betyr at du ser på tilgjengelighet eller nøkler. Ikke roter nøkler for et prefiksproblem; det nullstiller det eneste som virket.

Utdaterte kopier som overlever redigeringen din

Å redigere en fil er ikke det samme som å endre det kjørende systemet, og kopiene er flere enn folk forventer: enheten eller manageren som eier grensesnittet, en andre profil med samme navn i en annen mappe, en container med konfigurasjonen bakt inn i et image, et rutergrensesnitt med sin egen redigerte 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å. Hvis den numeriske ruten virker men vertsnavnet feiler, peker en intern DNS-post eller en tjenestekonfigurasjon fortsatt på den gamle tunneladressen. Rett referansen i stedet for å utvide hvert peer-område, noe som ville dekke over det egentlige problemet og samtidig forstørre kilde-ACL-en.

Hold én gjenopprettingsvei åpen mens du arbeider: en andre vei inn på verten, en seriell konsoll eller en planlagt tilbakerulling av konfigurasjonsfilene. En tunnelendring som låser deg ute av maskinen du endrer, er den vanligste måten denne oppgaven blir til en kveld.

Valget mellom de to, og verifisering av skiftet

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 kontrollerer, når en lenke mellom lokasjoner må holdes oppe, eller når du ikke kan garantere at hver kopi blir oppdatert i én gjennomgang. I så fall legg det nye prefikset til begge grensesnittene, flytt peere én om gangen, følg med på trafikken på det nye, og fjern først da det gamle grensesnittet og dets ruter.

Under begge alternativene er endringen ferdig når fire kontroller passerer: håndtrykket er nylig, ruteoppslaget for en destinasjon på det nye prefikset navngir tunnelen, en nyttelast på et par hundre byte overføres i begge retninger, og det samme gjelder etter en omstart av verten eller manageren. Den wg(8)-håndboken er referansen for hva AllowedIPs betyr i hver retning, og det er verdt å lese den på nytt før du utvider et område for å få et symptom til å forsvinne.

• Nylig håndtrykk og ingen data: se på AllowedIPs hos mottakeren før du rører 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 fullført når en omstart fortsatt bruker det nye prefikset.