To WireGuard-peers deler et område: hvem får pakken

To peers lister opp områder som berører hverandre, og trafikken når den gale. Ingenting er ødelagt: WireGuard velger en peer ved å matche destinasjonen mot de konfigurerte områdene, og den mest spesifikke treffen vinner. Før du utvider noe, må du bestemme hvilken peer som skal eie hvilket prefiks.

Det lengste prefikset vinner inne i WireGuard

Hver peer-oppføring bærer et sett med destinasjonsprefikser. Når en pakke rutes inn i grensesnittet, ser implementasjonen etter oppføringen med det mest spesifikke samsvarende prefikset — samme regel som en rutetabell bruker. Derfor slår en /24 en /16 som inneholder den, og den smalere peeren mottar trafikken.

Road-warrior-oppsett bruker dette med vilje. Én peer eier et bredt område for et nettsted, og enkelte verter skjæres ut med /32-oppføringer som tilhører andre peers. Mønsteret fungerer fordi utskjæringene er mer spesifikke, ikke på grunn av rekkefølgen.

Skriv ned eierskapet som en tabell over prefiks og peer. Hvis to oppføringer beskriver det samme prefikset, uttrykker ikke konfigurasjonen lenger en intensjon, den uttrykker et kappløp.

Operativsystemet velger grensesnittet først

WireGuard velger bare blant peerne på ett grensesnitt. Hvilket grensesnitt som mottar pakken, avgjøres tidligere av vertens rutetabell, og en annen standardrute eller en utdatert rute kan sende trafikken et sted peer-listen aldri ser den. Derfor kan en diagnose på peer-nivå være riktig og likevel ikke forklare feilen. Sjekk ruten til destinasjonen før du leser peer-konfigurasjonen, fordi en rute som peker på det fysiske grensesnittet omgår hele spørsmålet.

Verktøyet installerer vanligvis disse rutene fra peer-områdene, noe som betyr at en endring i én peers liste stille kan omdirigere trafikk som tidligere tilhørte en annen. Å redigere en peer er derfor en ruteendring i forkledning. Gå gjennom begge samtidig, ellers retter du den ene og ødelegger den andre.

Innkommende pakker kontrolleres etter kilde

Områdelisten har dobbel funksjon. For utgående trafikk velger den en peer etter destinasjon, og for innkommende trafikk autoriserer den en kildeadresse. En pakke som kommer fra en adresse utenfor den peerens områder, forkastes før noen brannmur ser den.

Denne asymmetrien er lett å overse når du leser den ene siden av konfigurasjonen. En peer som kan nå et subnett, er ikke dermed tillatt å sende fra det subnettet, og de to retningene håndheves av forskjellige kontroller.

Smal kildeeierskap gjør dette til en fordel. Gi hver peer en /32 for sin egen adresse, og brannmuren nedenfor har en pålitelig kilde å matche, i stedet for et område for hele gruppen som ethvert medlem kunne kreve.

Dupliserte områder er ikke failover

Å tildele det samme prefikset til to peers lager ikke en lastbalanserer eller en standby-sti. Det finnes ingen helsesjekk og ingen sesjonsaffinitet: oppføringen som vinner, avgjøres av implementasjonens interne rekkefølge, som ikke er en kontrakt du bør designe etter. Hvis du trenger alternative utganger, uttrykk dem der valget er definert. En rutingspolicy, en metrikk eller et par ulike prefikser med dokumentert eier på hver gir atferd du kan forutsi og teste.

Å utvide et område for å rette en urelatert feil er den andre vanlige feilen. Det flytter trafikk bort fra peeren som fungerte, og det nye symptomet kommer før det gamle er forstått.

Bekreft valget før du redigerer

Tre kommandoer svarer på de tre spørsmålene i rekkefølge. Den første lister områdene hver peer krever. Den andre viser hvilket grensesnitt verten ville bruke for en destinasjon. Den tredje viser live peer-tilstand etter at trafikk har flytt.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

Kjør dem før og etter en endring, og sammenlign. Hvis ruteutdataene er endret, men trafikken fortsatt kommer til feil peer, overlapper prefikslistene på en måte du ennå ikke har skrevet ned. Hvis ruteutdataene ikke er endret, var peer-konfigurasjonen aldri det som ble spurt.

Noter destinasjonen, det valgte grensesnittet og den valgte peeren i saken. Den trioen er det som gjør en overlapping gjennomgåelig senere, og den er langt mer nyttig enn et skjermbilde av konfigurasjonen.