WireGuard-standardrutans slinga: hitta slutpunktens väg

Gränssnittet kommer upp, peer-konfigurationen ser korrekt ut och inget handskakning slutförs någonsin. Att lägga till en standardrutt genom tunneln är steget som ofta orsakar det: samma routingtabell avgör nu vart tunnelns egna krypterade paket ska ta vägen, och svaret den producerar går tillbaka in i tunneln. Inget kan bära det yttre paketet som skulle bära det inre, så anslutningen stannar innan den börjar. Reparationen är liten, men den har en ordning, och verifieringen betyder mer än ändringen.

Bekräfta slingan innan du ändrar en rutt

Läs peerens aktuella slutpunktsadress och fråga sedan routingstacken vart ett paket till den adressen skulle ta vägen. Om svaret namnger tunnelgränssnittet är slingan bekräftad och ingen ytterligare diagnostik behövs. Spara båda utdata i ändringsloggen innan du rör något, eftersom jämförelsen efter reparationen är samma två kommandon. En slinga är inte subtil när den väl har setts; svårigheten är att gränssnittet ser friskt ut medan det händer.

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

Ta med policyreglerna i den registreringen. En standardrutt som ser korrekt ut i huvudtabellen kan fortfarande förlora mot en regel som väljer en annan tabell för märkt eller omärkt trafik, och slingan kommer att dyka upp igen med en routingtabell som ser fin ut.

Läs slutpunktens väg, inte tunnelns väg

Slutpunktens väg är den rutt de krypterade datagrammen tar till peerens offentliga adress, och den måste stanna utanför tunneln så länge tunneln finns. Tunnelns väg är allt peeren får bära. Dessa två vägar delar en routingtabell, och det är just därför en enda alltfångande post kan kollapsa dem i varandra. Att skilja tunnelns trafik från tunnelns egen transport är hela designproblemet, och varje stödd verktyg löser det någonstans lite annorlunda.

Kontrollera båda adressfamiljerna separat om gränssnittet bär båda. En fungerande IPv4-uteslutning säger ingenting om huruvida IPv6-slutpunkten fortfarande är nåbar, och en blandad konfiguration kan se ut att fungera tills peerens IPv6-adress väljs.

Återställ slutpunktens väg med en enda sammanhängande ändring

Det finns två stödda tillvägagångssätt, och att blanda dem är hur en fungerande uppsättning blir oförutsägbar. Det första är att låta verktyget som äger gränssnittet hantera hela tunneln: wg-quick har särskild hantering för ett standard peer-intervall som installerar en separat tabell, policyregler och en socket-markering, vilket håller de yttre paketen utanför tunneln. Låt den mekaniken vara intakt i stället för att återskapa hälften av den för hand. En uppsättning som blandar en manuellt tillagd standard med en hanterare som redan installerar markeringar och regler tenderar att misslyckas efter återanslutning, när hanteraren skriver om tillstånd som det manuella steget förutsatte.

Det andra är en manuell design där slutpunkten får en explicit värdrutt via den fysiska gatewayen. Lägg till den rutten före standardrutten, ersätt i stället för att lägga till så att en inaktuell post inte kan vinna, och bekräfta uppslaget efteråt.

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

Verifiera och behåll sedan en väg tillbaka

En handskakningstidsstämpel som rör sig framåt är det första beviset, och det är starkare än ett gränssnitt som bara finns. Följ upp med ett applikationstest genom tunneln, ta sedan ner gränssnittet med avsikt och bekräfta att värden återgår till ett användbart tillstånd i stället för att behålla en standardrutt som pekar på ingenting. Det sista steget är det folk hoppar över, och det avgör om en omstart lämnar maskinen utan anslutning.

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

Spara före allt detta det aktuella routingtillståndet och se till att det finns en väg in som inte beror på tunneln: en konsol, en out-of-band-hanteringsadress eller en kollega på plats. En fjärrmaskin som tappar sin standardrutt kan inte återställas över anslutningen den just förlorade, och det säkraste runbook-steget är det som tas före det första kommandot.