To WireGuard-peerar deler eit område: kven får pakken

To peerar listar opp område som rører kvarandre, og trafikken når den gale. Ingenting er øydelagt: WireGuard vel ein peer ved å matche destinasjonen mot dei konfigurerte områda, og den mest spesifikke treffet vinn. Før du utvidar noko, må du avgjere kva peer som skal eige kva prefiks.

Det lengste prefikset vinn inne i WireGuard

Kvar peer-oppføring ber eit sett med destinasjonsprefiks. Når ein pakke blir ruta inn i grensesnittet, ser implementasjonen etter oppføringa med det mest spesifikke samsvarande prefikset — same regel som ei rutetabell brukar. Difor slår ein /24 ein /16 som inneheld han, og den smalare peeren mottek trafikken.

Road-warrior-oppsett brukar dette med vilje. Éin peer eig eit breitt område for eit nettstad, og einskilde vertar blir skorne ut med /32-oppføringar som høyrer til andre peerar. Mønsteret fungerer fordi utskjeringane er meir spesifikke, ikkje på grunn av rekkjefølgja.

Skriv ned eigarskapen som ein tabell over prefiks og peer. Viss to oppføringar skildrar det same prefikset, uttrykkjer ikkje konfigurasjonen lenger ei intensjon, han uttrykkjer eit kappløp.

Operativsystemet vel grensesnittet først

WireGuard vel berre blant peerane på eitt grensesnitt. Kva grensesnitt som mottek pakken, blir avgjort tidlegare av rutetabellen til verten, og ei anna standardrute eller ei utdatert rute kan sende trafikken ein stad peer-lista aldri ser han. Difor kan ein diagnose på peer-nivå vere riktig og likevel ikkje forklare feilen. Sjekk ruta til destinasjonen før du les peer-konfigurasjonen, fordi ei rute som peikar på det fysiske grensesnittet omgår heile spørsmålet.

Verktøyet installerer vanlegvis desse rutene frå peer-områda, noko som betyr at ei endring i lista til éin peer stille kan omdirigere trafikk som tidlegare høyrde til ein annan. Å redigere ein peer er difor ei ruteendring i forkledning. Gå gjennom begge samtidig, elles rettar du den eine og øydelegg den andre.

Innkommande pakkar blir kontrollerte etter kjelde

Områdelista har dobbel funksjon. For utgåande trafikk vel han ein peer etter destinasjon, og for inngåande trafikk autoriserer han ei kjeldeadresse. Ein pakke som kjem frå ei adresse utanfor områda til den peeren, blir forkasta før nokon brannmur ser han.

Denne asymmetrien er lett å oversjå når du les den eine sida av konfigurasjonen. Ein peer som kan nå eit subnett, er ikkje dermed tillaten å sende frå det subnettet, og dei to retningane blir handheva av ulike kontrollar.

Smal kjeldeeigarskap gjer dette til ein fordel. Gi kvar peer ein /32 for si eiga adresse, og brannmuren nedanfor har ei påliteleg kjelde å matche, i staden for eit område for heile gruppa som kvar medlem kunne krevje.

Dupliserte område er ikkje failover

Å tildele det same prefikset til to peerar lagar ikkje ein lastbalansar eller ein standby-sti. Det finst ingen helsesjekk og ingen sesjonsaffinitet: oppføringa som vinn, blir avgjort av den interne rekkjefølgja i implementasjonen, som ikkje er ein kontrakt du bør designe etter. Viss du treng alternative utgangar, uttrykk dei der valet er definert. Ein rutingspolicy, ein metrikk eller eit par ulike prefiks med dokumentert eigar på kvar gir åtferd du kan føresjå og teste.

Å utvide eit område for å rette ein urelatert feil er den andre vanlege feilen. Det flyttar trafikk bort frå peeren som fungerte, og det nye symptomet kjem før det gamle er forstått.

Stadfest valet før du redigerer

Tre kommandoar svarar på dei tre spørsmåla i rekkjefølgje. Den første listar områda kvar peer krev. Den andre viser kva grensesnitt verten ville bruke for ein 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

Køyr dei før og etter ei endring, og samanlikn. Viss ruteutdataa er endra, men trafikken framleis kjem til feil peer, overlappar prefikslister på ein måte du enno ikkje har skrive ned. Viss ruteutdataa ikkje er endra, var peer-konfigurasjonen aldri det som vart spurt.

Noter destinasjonen, det valde grensesnittet og den valde peeren i saka. Den trioen er det som gjer ei overlapping gjennomgåeleg seinare, og han er langt meir nyttig enn eit skjermbilete av konfigurasjonen.