WireGuard: ingen rute til peer etter eit subnettbyte — to vegar ut

Handtrykket er ferskt i wg show, endepunktet er rett, nøklane er aldri endra — og ping seier framleis at det ikkje finst noka rute til peer. Du endra subnettet til tunnelen for ein time sidan. Det symptomet er signaturen til eit prefiksavvik og ikkje eit nøkkelproblem: WireGuard fullførte handtrykket og slapp deretter dataa fordi ei kjeldeadresse ikkje lenger samsvarar med det den mottakande peeren vil godta. Det finst to fornuftige måtar å gjennomføre eit subnettbyte på, og dei feilar på ulike stader.

To måtar å gjennomføre endringa på, og kva kvar kostar

Alternativ A er omnummerering på staden: rediger grensesnittadressa, peer-områda, rutene og kvar kopi av konfigurasjonen, og last deretter inn på nytt. Alternativ B er å byggje eit andre grensesnitt på det nye prefikset ved sida av det gamle, flytte peere over og fjerne det gamle grensesnittet når trafikken faktisk har flytta seg.

Den halvt brukte tilstanden er det som gjer alternativ A farleg, fordi han ikkje ser øydelagd ut. Grensesnittet kjem opp, handtrykket lykkast, og berre datastien feilar. Alternativ B kostar meir arbeid, men held ein fungerande sti i live medan du finn kvar referanse.

Kva som må flytte seg saman på di side

Fire ting på den lokale verten skildrar det same subnettet, og ei endring i éin er ei endring i alle: grensesnittadressa, AllowedIPs til kvar peer, ruta systemet brukar for desse destinasjonane, og alt administratoren installerer på dine vegner. Med wg-quick blir dei to siste genererte frå konfigurasjonen kvar gong grensesnittet kjem opp, så ein utdatert kopi gjeninstallerer det gamle prefikset i det stille.

Samanlikn det konfigurerte med det levande i staden for å stole på nokon av dei:

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

Ruteoppslaget er trinnet folk hoppar over. Det svarar på kva kjernen faktisk ville gjere for ein destinasjon, inkludert ei meir spesifikk rute som ein administrator eller eit container-miljø har lagt att. Viss det rapporterer eit anna grensesnitt enn tunnelen, er ikkje konfigurasjonen problemet.

For eit køyrande grensesnitt, bruk den redigerte fila utan å rive ned tunnelen:

wg syncconf wg0 <(wg-quick strip wg0)

Det oppdaterer peere og område på staden. Det oppdaterer ikkje grensesnittadressa eller rutene, fordi dei ikkje er WireGuard-innstillingar — så ei omnummerering treng framleis at grensesnittet blir laga på nytt eller at adressa blir endra med ip, og deretter at rutinga blir kontrollert på nytt.

Kva som må flytte seg saman i den fjerne enden

Det er her eit subnettbyte vanlegvis døyr. AllowedIPs er ikkje berre eit rutehint; det er også lista over kjeldeadresser ein peer har lov til å presentere. Når du omnummererer klientar og lèt AllowedIPs til serveren stå på det gamle prefikset, godtek serveren handtrykket, tek imot dei krypterte pakkane og kastar dei fordi kjelda inni ikkje samsvarar med noko område han knyter til den peeren. Ingen feil blir logga, og klienten ser ein tidsavbrot.

Så oppdater mottakarsida med vilje: peer-oppføringa på serveren må liste det nye klientprefikset, eigen returrute til serveren må peike på tunnelen for det prefikset, og kvart nedstraums nettverk bak serveren må lære den nye stien. Brannmurpolitikk som namngav det gamle området treng same handsaming, og det same gjer alt som gjer kjeldebasert val.

Diagnostikken som skil dei to feila er billig. Eit nyleg handtrykk utan data betyr at tunnelen er oppe og at den indre adresseringa ikkje er samd. Ingen handtrykk i det heile betyr at du ser på tilgjenge eller nøklar. Ikkje roter nøklar for eit prefiksproblem; det nullstiller det einaste som virka.

Utdaterte kopiar som overlever redigeringa di

Å redigere ei fil er ikkje det same som å endre det køyrande systemet, og kopiane er fleire enn folk ventar: eininga eller administratoren som eig grensesnittet, ein andre profil med same namn i ei anna mappe, ein container med konfigurasjonen baka inn i eit image, eit rutergrensesnitt med si eiga redigerte utgåve og ein klientapp som importerer ein lagra tunnel på nytt ved oppstart. Kvar av dei kan gjenopprette det gamle prefikset etter at endringa di ser ferdig ut.

Namn reiser også. Viss den numeriske ruta virkar men vertsnamnet feilar, peikar ein intern DNS-post eller ein tenestekonfigurasjon framleis på den gamle tunneladressa. Rett referansen i staden for å utvide kvart peer-område, noko som ville dekkje over det eigentlege problemet og samstundes forstørre kjelde-ACL-en.

Hald éin gjenopprettingsveg open medan du arbeider: ein andre veg inn på verten, ein seriell konsoll eller ei planlagd tilbakerulling av konfigurasjonsfilene. Ei tunnelendring som låser deg ute av maskinen du endrar, er den vanlegaste måten denne oppgåva blir til ein kveld.

Valet mellom dei to, og verifisering av skiftet

Vel A når du eig kvar peer, talet er lite og eit kort avbrot er akseptabelt. Vel B når peerane er fjerne hender du ikkje kontrollerer, når ei lenke mellom lokasjonar må haldast oppe, eller når du ikkje kan garantere at kvar kopi blir oppdatert i éin gjennomgang. I så fall legg det nye prefikset til båe grensesnitta, flytt peere éin om gongen, følg med på trafikken på det nye, og fjern først då det gamle grensesnittet og rutene hans.

Under båe alternativa er endringa ferdig når fire kontrollar passerer: handtrykket er nyleg, ruteoppslaget for ein destinasjon på det nye prefikset namngir tunnelen, ei nyttelast på eit par hundre byte blir overført i båe retningar, og det same gjeld etter ein omstart av verten eller administratoren. Den wg(8)-handboka er referansen for kva AllowedIPs betyr i kvar retning, og det er verdt å lese henne på nytt før du utvidar eit område for å få eit symptom til å forsvinne.

• Nyleg handtrykk og ingen data: sjå på AllowedIPs hos mottakaren før du rører nøklane.
• Ruteoppslaget peikar på feil grensesnitt: ein administrator eller container eig ruta, ikkje fila di.
• Numerisk adresse i orden og vertsnamn øydelagt: ein gamal referanse, ikkje ei rutingløkke.
• Endringa er først fullført når ein omstart framleis brukar det nye prefikset.