WireGuard: två halva rutter mot 0.0.0.0/0 i wg-quick

Två /1-prefix täcker exakt samma IPv4-adresser som ett enda /0, och den likheten gäller bara inom peerens lista över tillåtna prefix. Den slutar gälla i samma stund som installationsverktyget bestämmer hur det ska routas, eftersom Linux wg-quick behandlar ett standardprefix som ett specialfall och inte som aritmetik. Den särskilda grenen installerar en egen tabell, två policyregler, en socketmarkering och inställningar för omvänd väg som ett par halva rutter aldrig får. När en proxy eller en webbläsare därför slutar fungera efter ändringen är prefixen den minst intressanta delen av ändringen.

Prefixlistan är inte hela konfigurationen

AllowedIPs gör två saker samtidigt, och bara en av dem handlar om täckning. För WireGuard självt är listan krypteringsnyckelroutning: den avgör vilka destinationer som krypteras mot en peer och vilka källadresser den peeren får använda. För wg-quick fungerar samma lista också som en rutspecifikation, och rutten den skapar beror på vilken gren listan råkar matcha. Identisk täckning över två olika listformer säger därför ingenting om identiskt värdsläge.

Standardkonfigurationen tar det beslutet ur dina händer, eftersom Table är automatiskt som standard och verktyget väljer var rutterna landar. En annan nätverkshanterare, ett distributionspaket eller ett anpassat Table-värde ändrar resultatet igen, och därför kan råd skrivna för en värd se fel ut på nästa.

Vad standardgrenen tillför utöver en rutt

En /0-post skickar wg-quick in i sin standardruttväg: en separat routingtabell tar emot standardrutten, en policyregel skickar omarkerad trafik dit, en andra regel håller mer specifika rutter i huvudtabellen auktoritativa, och gränssnittet får en brandväggsmarkering på sin egen socket. Den markeringen är slingans väktare. De krypterade datagram som bär tunneltrafiken lämnar värden med markeringen satt, så att regeln som styr allt annat in i tunneln inte slukar tunnelns egna transportpaket.

Ett par /1-poster tar i stället den vanliga ruttvägen. Två rutter landar i den konfigurerade tabellen, och inget av maskineriet runt omkring dyker upp, inte för att det är onödigt utan för att den kodvägen aldrig beträddes.

Där de två arrangemangen skiljs åt

Avvikelsen visar sig först som rekursion. Med de halva rutterna i huvudtabellen faller peerens egen transportadress inom ett tunnelprefix, så paketet som skulle bära tunneln matchar en rutt som pekar in i tunneln. Något måste undanta det: en värdrutt för den aktuella slutpunkten, en markering satt för hand eller en gränssnittsspecifik regel. En värdrutt fungerar tills slutpunktens adress ändras, vilket händer med DNS-baserade slutpunkter, kringflackande klienter och konfigurationer med flera peers.

För det andra ändrar allt som resonerar om markeringar sitt beteende. En transparent proxy som omdirigerar anslutningar lokalt skapar nya sockets vars markeringar och källor skiljer sig från klientens ursprungliga flöde, och de policyregler som standardgrenen genererar var en del av det som skilde dessa flöden åt. Att läsa proxyns egen utgående anslutning är en annan övning än att testa om den ursprungliga destinationen är nåbar.

Läs reglerna och markeringarna innan du redigerar

Fånga det aktuella tillståndet medan tunneln är frisk, och sedan igen efter ändringen, och jämför de två utskrifterna i stället för att resonera utifrån konfigurationsfilen. Ta med policyreglerna, varje tabell, gränssnittets markering och de registrerade slutpunkterna.

ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints

Om den första utskriftsraden har tappat regeln för omarkerad trafik och den egna tabellen är tom, körs inte standardgrenen och ingen mängd prefixaritmetik återställer dess effekter. En markering på noll på ett gränssnitt som tidigare bar en är samma signal, synlig i ett enda värde.

Öva på förlust av tunneln innan du rullar ut

Om halvruteupplägget är det medvetna valet måste det leverera de saknade delarna uttryckligen: en slutpunktsväg som överlever adressändringar, det avsedda beteendet när tunneln faller och motsvarande hantering för IPv6. Skriv ned det som krav i stället för att upptäcka det under ett avbrott. Öva sedan på felet, för en full tunnel som tyst faller tillbaka till den fysiska upplänken är sämre än en som slutar fungera.

sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1

Rutuppslagningen bör lösa slutpunkten ur det fysiska gränssnittet utan att korsa tunneln, och att ta ned gränssnittet bör lämna värden i det tillstånd som designen lovade. En proxy som fungerar efter bytet bevisar att det genererade världstillståndet spelade roll; det bevisar inte att slingförebyggande och beteende i nedtaget tillstånd överlevde ändringen.