WireGuard-standardrute-loop: find endepunktets sti

Interfacet kommer op, peer-konfigurationen ser rigtig ud, og intet handshake fuldføres nogensinde. At tilføje en standardrute gennem tunnelen er det trin, der ofte forårsager det: den samme rutetabel bestemmer nu, hvor tunnelens egne krypterede pakker skal hen, og det svar, den giver, er tilbage i tunnelen. Intet kan bære den ydre pakke, der skulle bære den indre, så forbindelsen stopper, før den begynder. Reparationen er lille, men den har en rækkefølge, og verifikationen betyder mere end ændringen.

Bekræft loopet, før du ændrer en rute

Læs peerens aktuelle endepunktsadresse, og spørg derefter rutestakken, hvor en pakke til den adresse ville gå hen. Hvis svaret nævner tunnelinterfacet, er loopet bekræftet, og der er ikke brug for yderligere diagnosticering. Gem begge output i ændringsloggen, før du rører noget, fordi sammenligningen efter rettelsen er de samme to kommandoer. Et loop er ikke subtilt, når det først er set; vanskeligheden er, at interfacet ser sundt ud, mens det sker.

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

Medtag politikreglerne i den registrering. En standardrute, der ser korrekt ud i hovedtabellen, kan stadig tabe til en regel, der vælger en anden tabel for markeret eller umarkeret trafik, og loopet vil dukke op igen med en rutetabel, der ser fin ud.

Læs endepunktets sti, ikke tunnelens sti

Endepunktets sti er den rute, de krypterede datagrammer tager til peerens offentlige adresse, og den skal blive uden for tunnelen, så længe tunnelen findes. Tunnelens sti er alt, hvad peerens må bære. De to stier deler en rutetabel, og det er netop derfor, en enkelt catch-all-post kan kollapse dem ind i hinanden. At skille tunnelens trafik fra tunnelens egen transport er hele designproblemet, og hvert understøttet værktøj løser det lidt forskelligt.

Kontrollér begge adressefamilier separat, hvis interfacet bærer begge. En fungerende IPv4-udelukkelse siger intet om, hvorvidt IPv6-endepunktet stadig er tilgængeligt, og en blandet konfiguration kan se ud til at virke, indtil peerens IPv6-adresse vælges.

Gendan endepunktets sti med én sammenhængende ændring

Der findes to understøttede fremgangsmåder, og at blande dem er, hvordan en fungerende opsætning bliver uforudsigelig. Den første er at lade værktøjet, der ejer interfacet, håndtere hele tunnelen: wg-quick har særlig håndtering af et standard-peer-område, som installerer en separat tabel, politikregler og et socket-mærke, hvilket holder de ydre pakker ude af tunnelen. Lad det maskineri være intakt i stedet for at genskabe halvdelen af det manuelt. En opsætning, der blander en manuelt tilføjet standardrute med en manager, der allerede installerer mærker og regler, har tendens til at fejle efter genopkobling, når manageren overskriver tilstand, som det manuelle trin antog.

Den anden er et manuelt design, hvor endepunktet får en eksplicit værtsrute gennem den fysiske gateway. Tilføj den rute før standardruten, erstat i stedet for at tilføje, så en forældet post ikke kan vinde, og bekræft opslaget bagefter.

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

Verificér, og behold derefter en vej tilbage

Et handshake-tidsstempel, der rykker frem, er det første bevis, og det er stærkere end et interface, der blot findes. Følg det op med en applikationstest gennem tunnelen, tag derefter interfacet ned med vilje, og bekræft, at værten vender tilbage til en brugbar tilstand i stedet for at holde en standardrute, der peger på ingenting. Det sidste trin er det, folk springer over, og det er det, der afgør, om en genstart efterlader maskinen uden 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 noget af dette skal du gemme den aktuelle routingtilstand og sikre dig, at der er en vej ind, som ikke afhænger af tunnelen: en konsol, en out-of-band-administrationsadresse eller en kollega på stedet. En fjern maskine, der mister sin standardrute, kan ikke gendannes over den forbindelse, den netop har mistet, og det sikreste runbook-trin er det, der tages før den første kommando.