WireGuard-standardrute-løkke: finn stien til endepunktet

Grensesnittet kjem opp, peer-konfigurasjonen ser rett ut, og ingen handtrykk blir nokon gong fullført. Å leggje til ei standardrute gjennom tunnelen er trinnet som ofte årsakar det: den same rutetabellen avgjer no kvar dei eigne krypterte pakkane til tunnelen skal gå, og svaret han gjev går tilbake i tunnelen. Ingenting kan bera den ytre pakken som skulle bera den indre, så sambandet stoppar før det byrjar. Reparasjonen er liten, men han har ein rekkjefølgje, og verifiseringa tyder meir enn endringa.

Stadfest løkka før du endrar ei rute

Les den gjeldande endepunktadressa til peeren, og spør deretter rutestakken kvar ein pakke til den adressa ville gå. Viss svaret nemner tunnelgrensesnittet, er løkka stadfesta og inga vidare diagnostikk er naudsynt. Lagre begge utdata i endringsloggen før du rører noko, fordi samanlikninga etter reparasjonen er dei same to kommandoane. Ei løkke er ikkje subtil når ho først er sett; vanskane er at grensesnittet ser sunt ut medan det skjer.

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

Ta med policyreglane i den registreringa. Ei standardrute som ser rett ut i hovudtabellen kan framleis tape mot ein regel som vel ein annan tabell for merkt eller umerkt trafikk, og løkka vil dukke opp att med ein rutetabell som ser fin ut.

Les stien til endepunktet, ikkje stien til tunnelen

Stien til endepunktet er ruta dei krypterte datagramma tek til den offentlege adressa til peeren, og han må halde seg utanfor tunnelen så lenge tunnelen finst. Stien til tunnelen er alt peeren har lov til å bera. Desse to stiane deler éin rutetabell, og det er nettopp derfor éi einskild altfangande oppføring kan kollapse dei inn i kvarandre. Å skilje trafikken til tunnelen frå eigen transport av tunnelen er heile designproblemet, og kvart støtta verktøy løyser det litt ulikt ein stad.

Kontroller begge adressefamiliane kvar for seg viss grensesnittet ber begge. Ei fungerande IPv4-utelating seier ingenting om korvidt IPv6-endepunktet framleis er tilgjengeleg, og ein blanda konfigurasjon kan sjå ut til å verke til IPv6-adressa til peeren blir vald.

Gjenopprett stien til endepunktet med éi samanhengande endring

Det finst to støtta tilnærmingar, og å blande dei er korleis eit fungerande oppsett blir uføreseieleg. Den første er å la verktøyet som eig grensesnittet handsame heile tunnelen: wg-quick har eigen handsaming for eit standard peer-område som installerer ein separat tabell, policyreglar og eit socket-merke, som held dei ytre pakkane ute av tunnelen. La den mekanikken vere intakt i staden for å gjenskape halvparten av han manuelt. Eit oppsett som blandar ein manuelt lagd standard med ein behandlar som allereie installerer merke og reglar, har ein tendens til å feile etter gjenoppkopling, når behandlaren skriv om tilstand som det manuelle trinnet føresette.

Den andre er eit manuelt design der endepunktet får ei eksplisitt vertsrute gjennom den fysiske gatewayen. Legg til den ruta før standarden, erstatt i staden for å leggje til, slik at ei forelda oppføring ikkje kan vinne, og stadfest 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 hald deretter ein veg tilbake

Eit handtrykkstidsstempel som går framover er det første beviset, og det er sterkare enn eit grensesnitt som berre finst. Følg det opp med ein applikasjonstest gjennom tunnelen, ta deretter grensesnittet ned med vilje og stadfest at verten går tilbake til ein brukbar tilstand i staden for å halde ei standardrute som peikar på ingenting. Det siste trinnet er det folk hoppar over, og det er det som avgjer om ein omstart lèt maskinen utan samband.

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

Før noko av dette, lagre gjeldande rutertilstand og forsikre deg om at det finst ein inngangsveg som ikkje er avhengig av tunnelen: ein konsoll, ei out-of-band-administrasjonsadresse eller ein kollega på staden. Ein fjernmaskin som mistar standardruta si, kan ikkje gjenopprettast over sambandet han nettopp mista, og det tryggaste runbook-trinnet er det som blir teke før den første kommandoen.