To peers angiver intervaller, der støder op til hinanden, og trafikken når den forkerte. Intet er beskadiget: WireGuard vælger en peer ved at matche destinationen mod de konfigurerede intervaller, og det mest specifikke match vinder. Før du udvider noget, skal du beslutte, hvilken peer der skal eje hvilket præfiks.

Det længste præfiks vinder inde i WireGuard

Hver peer-post indeholder et sæt destinationspræfikser. Når en pakke rutes ind i grænsefladen, leder implementeringen efter posten med det mest specifikke matchende præfiks — samme regel som en routingtabel anvender. Derfor slår /24 en /16, der indeholder den, og den smallere peer modtager trafikken.

Road-warrior-opsætninger bruger dette med vilje. Én peer ejer et bredt interval for et sted, og enkelte værter skæres ud med /32-poster, der tilhører andre peers. Mønstret virker, fordi udskæringerne er mere specifikke, ikke på grund af rækkefølgen.

Skriv ejerskabet ned som en tabel over præfiks og peer. Hvis to poster beskriver det samme præfiks, udtrykker konfigurationen ikke længere en hensigt, den udtrykker et kapløb.

Operativsystemet vælger grænsefladen først

WireGuard vælger kun blandt peerne på én grænseflade. Hvilken grænseflade der modtager pakken, afgøres tidligere af værtens routingtabel, og en anden standardrute eller en forældet rute kan sende trafikken et sted, hvor peer-listen aldrig ser den. Derfor kan en diagnose på peer-niveau være korrekt og stadig ikke forklare fejlen. Tjek ruten til destinationen, før du læser peer-konfigurationen, fordi en rute, der peger på den fysiske grænseflade, omgår hele spørgsmålet.

Værktøjet installerer normalt disse ruter ud fra peer-intervallerne, hvilket betyder, at en ændring i én peers liste stille kan omdirigere trafik, der tidligere tilhørte en anden. En peer-redigering er derfor en ruteændring i forklædning. Gennemgå begge på én gang, ellers retter du den ene og ødelægger den anden.

Indgående pakker kontrolleres efter kilde

Interval-listen tjener to formål. For udgående trafik vælger den en peer efter destination, og for indgående trafik autoriserer den en kildeadresse. En pakke, der ankommer fra en adresse uden for den peers intervaller, droppes, før nogen firewall ser den.

Den asymmetri er let at overse, når man læser den ene side af konfigurationen. En peer, der kan nå et undernet, er ikke dermed tilladt at sende fra det undernet, og de to retninger håndhæves af forskellige kontroller.

Smal kildeejerskab gør dette til en fordel. Giv hver peer et /32 til sin egen adresse, og firewallen længere nede har en troværdig kilde at matche i stedet for et interval for hele gruppen, som ethvert medlem kunne gøre krav på.

Dublerede intervaller er ikke failover

At tildele det samme præfiks til to peers skaber ikke en load balancer eller en standby-rute. Der er ingen sundhedskontrol og ingen session-affinitet: den post, der vinder, afgøres af implementeringens interne rækkefølge, hvilket ikke er en kontrakt, du bør designe efter. Hvis du har brug for alternative udgange, udtryk dem, hvor valget er defineret. En routingpolitik, en metrik eller et par forskellige præfikser med dokumenteret ejer på hver giver adfærd, du kan forudsige og teste.

At udvide et interval for at rette en urelateret fejl er den anden almindelige fejl. Det flytter trafik væk fra den peer, der fungerede, og det nye symptom kommer, før det gamle er forstået.

Bekræft valget før redigering

Tre kommandoer besvarer de tre spørgsmål i rækkefølge. Den første viser de intervaller, hver peer kræver. Den anden viser, hvilken grænseflade værten ville bruge til en destination. Den tredje viser peer-tilstand i realtid, efter at trafik er løbet igennem.

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

Kør dem før og efter en ændring, og sammenlign. Hvis ruteoutputtet er ændret, men trafikken stadig ankommer til den forkerte peer, overlapper præfikslistene på en måde, du endnu ikke har skrevet ned. Hvis ruteoutputtet ikke er ændret, var peer-konfigurationen aldrig det, der blev spurgt.

Noter destinationen, den valgte grænseflade og den valgte peer i sagen. Den tredobling gør en overlapning gennemgåelig senere og er langt mere nyttig end et skærmbillede af konfigurationen.

Relaterede artikler