WireGuard: to halve ruter mot 0.0.0.0/0 i wg-quick

To /1-prefikser dekker nøyaktig de samme IPv4-adressene som ett /0, og denne likheten gjelder bare inne i peerens liste over tillatte prefikser. Den slutter å gjelde i det øyeblikket oppsettverktøyet bestemmer hvordan det skal rutes, fordi Linux wg-quick behandler et standardprefiks som et spesialtilfelle og ikke som aritmetikk. Den spesielle grenen installerer en egen tabell, to policyregler, et socketmerke og innstillinger for omvendt sti som et par halve ruter aldri får. Når en proxy eller en nettleser derfor slutter å virke etter endringen, er prefiksene den minst interessante delen av endringen.

Prefikslisten er ikke hele konfigurasjonen

AllowedIPs gjør to jobber samtidig, og bare én av dem handler om dekning. For WireGuard selv er listen kryptonøkkelrutting: den avgjør hvilke destinasjoner som krypteres mot en peer, og hvilke kildeadresser den peeren kan bruke. For wg-quick fungerer den samme listen også som en rutespesifikasjon, og ruten den lager avhenger av hvilken gren listen tilfeldigvis treffer. Identisk dekning på tvers av to ulike listeformer sier derfor ingenting om identisk vertstilstand.

Standardkonfigurasjonen tar den avgjørelsen ut av hendene dine, fordi Table er automatisk som standard og verktøyet velger hvor rutene lander. En annen nettverksbehandler, en distribusjonsinnpakning eller en tilpasset Table-verdi endrer resultatet igjen, og derfor kan råd skrevet for én vert se gale ut på den neste.

Hva standardgrenen legger til utover en rute

En /0-oppføring sender wg-quick inn i sin standardrutesti: en egen rutetabell mottar standardruten, én policyregel sender umerket trafikk dit, en andre regel holder mer spesifikke ruter i hovedtabellen autoritative, og grensesnittet får et brannmurmerke på sin egen socket. Det merket er løkkevakten. De krypterte datagrammene som bærer tunneltrafikken, forlater verten med merket satt, slik at regelen som styrer alt annet inn i tunnelen, ikke sluker tunnelens egne transportpakker.

Et par /1-oppføringer tar i stedet den vanlige rutestien. To ruter lander i den konfigurerte tabellen, og ingenting av maskineriet rundt dukker opp, ikke fordi det er unødvendig, men fordi den kodeveien aldri ble betrådt.

Hvor de to ordningene går fra hverandre

Avviket viser seg først som rekursjon. Med de halve rutene i hovedtabellen faller peerens egen transportadresse innenfor et tunnelprefiks, slik at pakken som skulle bære tunnelen, treffer en rute som peker inn i tunnelen. Noe må unnta den: en vertsrute for gjeldende endepunkt, et merke satt for hånd eller en grensesnittspesifikk regel. En vertsrute virker til endepunktets adresse endres, noe som skjer med DNS-baserte endepunkter, gjestende klienter og konfigurasjoner med flere peers.

For det andre endrer alt som resonnerer om merker, atferd. En gjennomsiktig proxy som omdirigerer tilkoblinger lokalt, lager nye sockets der merker og kilder avviker fra den opprinnelige klientflyten, og policyreglene som standardgrenen genererer, var en del av det som sorterte disse flytene. Å lese proxyens egen utgående tilkobling er en annen øvelse enn å teste om den opprinnelige destinasjonen er nåbar.

Les reglene og merkene før du redigerer

Ta opp gjeldende tilstand mens tunnelen er sunn, og deretter igjen etter endringen, og sammenlign de to utskriftene i stedet for å resonnere fra konfigurasjonsfilen. Ta med policyreglene, hver tabell, grensesnittets merke og de registrerte endepunktene.

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

Hvis den første utskriftslinjen har mistet regelen for umerket trafikk og den egne tabellen er tom, kjører ikke standardgrenen, og ingen mengde prefiksaritmetikk gjenoppretter virkningene. Et merke på null på et grensesnitt som tidligere hadde ett, er samme signal, synlig i én enkelt verdi.

Øv på tap av tunnelen før du ruller ut

Hvis halvruteoppsettet er det bevisste valget, må det levere de manglende delene eksplisitt: en endepunktssti som overlever adresseendringer, den tiltenkte atferden når tunnelen faller, og tilsvarende behandling for IPv6. Skriv det ned som krav i stedet for å oppdage det under en avbrudd. Øv deretter på feilen, for en full tunnel som stille faller tilbake til den fysiske opplenken, er verre enn en som slutter å virke.

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

Ruteoppslaget bør løse endepunktet ut av det fysiske grensesnittet uten å krysse tunnelen, og å ta grensesnittet ned bør etterlate verten i den tilstanden designet lovet. En proxy som virker etter utskiftningen, beviser at den genererte vertstilstanden betydde noe; det beviser ikke at løkkeforebygging og atferd i nedslått tilstand overlevde endringen.