WireGuard-standardrute-løkke: finn endepunktets sti

Grensesnittet kommer opp, peer-konfigurasjonen ser riktig ut, og ingen håndtrykk fullføres noen gang. Å legge til en standardrute gjennom tunnelen er trinnet som ofte forårsaker det: den samme rutetabellen bestemmer nå hvor tunnelens egne krypterte pakker skal gå, og svaret den produserer går tilbake i tunnelen. Ingenting kan bære den ytre pakken som skulle bære den indre, så forbindelsen stopper før den begynner. Reparasjonen er liten, men den har en rekkefølge, og verifiseringen betyr mer enn endringen.

Bekreft løkken før du endrer en rute

Les peerens gjeldende endepunktadresse, og spør deretter rutestakken hvor en pakke til den adressen ville gå. Hvis svaret nevner tunnelgrensesnittet, er løkken bekreftet og ingen ytterligere diagnose er nødvendig. Lagre begge utdataene i endringsloggen før du berører noe, fordi sammenligningen etter reparasjonen er de samme to kommandoene. En løkke er ikke subtil når den først er sett; vanskeligheten er at grensesnittet ser sunt ut mens det skjer.

sudo wg show wg1 endpoints
ip route get 198.51.100.20
ip rule show

Ta med policyreglene i den registreringen. En standardrute som ser riktig ut i hovedtabellen kan fortsatt tape mot en regel som velger en annen tabell for merket eller umerket trafikk, og løkken vil dukke opp igjen med en rutetabell som ser fin ut.

Les endepunktets sti, ikke tunnelens sti

Endepunktets sti er ruten de krypterte datagrammene tar til peerens offentlige adresse, og den må holde seg utenfor tunnelen så lenge tunnelen finnes. Tunnelens sti er alt peeren har lov til å bære. Disse to stiene deler én rutetabell, og det er nettopp derfor én enkelt altfangende oppføring kan kollapse dem inn i hverandre. Å skille tunnelens trafikk fra tunnelens egen transport er hele designproblemet, og hvert støttet verktøy løser det litt forskjellig et sted.

Kontroller begge adressefamiliene separat hvis grensesnittet bærer begge. En fungerende IPv4-utelatelse sier ingenting om hvorvidt IPv6-endepunktet fortsatt er tilgjengelig, og en blandet konfigurasjon kan se ut til å virke til peerens IPv6-adresse velges.

Gjenopprett endepunktets sti med én sammenhengende endring

Det finnes to støttede tilnærminger, og å blande dem er hvordan en fungerende oppsett blir uforutsigbar. Den første er å la verktøyet som eier grensesnittet håndtere hele tunnelen: wg-quick har egen håndtering for et standard peer-område som installerer en separat tabell, policyregler og et socket-merke, som holder de ytre pakkene ute av tunnelen. La den mekanikken være intakt i stedet for å gjenskape halvparten av den manuelt. Et oppsett som blander en manuelt lagt til standard med en behandler som allerede installerer merker og regler, har en tendens til å feile etter gjenoppkobling, når behandleren skriver om tilstand som det manuelle trinnet forutsatte.

Den andre er et manuelt design der endepunktet får en eksplisitt vertsrute gjennom den fysiske gatewayen. Legg til den ruten før standarden, erstatt i stedet for å legge til, slik at en foreldet oppføring ikke kan vinne, og bekreft oppslaget etterpå.

sudo ip route replace 198.51.100.20/32 via 192.0.2.1 dev eth0
ip route get 198.51.100.20
sudo ip route add default dev wg1

Verifiser, og behold deretter en vei tilbake

Et håndtrykkstidsstempel som går fremover er det første beviset, og det er sterkere enn et grensesnitt som bare finnes. Følg det opp med en applikasjonstest gjennom tunnelen, ta deretter grensesnittet ned med vilje og bekreft at verten går tilbake til en brukbar tilstand i stedet for å holde en standardrute som peker på ingenting. Det siste trinnet er det folk hopper over, og det er det som avgjør om en omstart etterlater maskinen uten forbindelse.

sudo wg show wg1 latest-handshakes
sudo wg-quick down wg1
ip route show default
ip route get 198.51.100.20

Før noe av dette, lagre gjeldende rutertilstand og forsikre deg om at det finnes en inngangsvei som ikke avhenger av tunnelen: en konsoll, en out-of-band-administrasjonsadresse eller en kollega på stedet. En fjernmaskin som mister standardruten sin, kan ikke gjenopprettes over forbindelsen den nettopp mistet, og det sikreste runbook-trinnet er det som tas før den første kommandoen.