Twee WireGuard-peers delen een bereik: wie krijgt het pakket

Twee peers vermelden bereiken die elkaar raken, en het verkeer bereikt de verkeerde. Niets is beschadigd: WireGuard kiest een peer door de bestemming te matchen met de geconfigureerde bereiken, en de meest specifieke match wint. Voordat je iets verbreedt, beslis welke peer welk prefix hoort te bezitten.

Het langste prefix wint binnen WireGuard

Elke peer-regel draagt een set bestemmingsprefixen. Wanneer een pakket naar de interface wordt gerouteerd, zoekt de implementatie de regel met het meest specifieke overeenkomende prefix — dezelfde regel die een routingtabel toepast. Een /24 verslaat dus een /16 die hem bevat, en de smallere peer ontvangt het verkeer.

Road-warrior-opstellingen gebruiken dit bewust. Eén peer bezit een breed bereik voor een locatie, en afzonderlijke hosts worden uitgesneden met /32-regels die bij andere peers horen. Het patroon werkt omdat de uitsneden specifieker zijn, niet door de volgorde.

Leg het eigendom vast als een tabel van prefix en peer. Als twee regels hetzelfde prefix beschrijven, drukt de configuratie geen intentie meer uit, maar een race.

Het besturingssysteem kiest eerst de interface

WireGuard kiest alleen tussen de peers op één interface. Welke interface het pakket ontvangt, wordt eerder bepaald door de routingtabel van de host, en een tweede standaardroute of een verouderde route kan het verkeer ergens heen sturen waar de peer-lijst het nooit ziet. Daarom kan een diagnose op peer-niveau correct zijn en toch de storing niet verklaren. Controleer de route naar de bestemming voordat je de peer-configuratie leest, want een route die naar de fysieke interface wijst, omzeilt de hele vraag.

De tool installeert die routes meestal uit de peer-bereiken, wat betekent dat een wijziging in de lijst van één peer verkeer dat eerder bij een ander hoorde stil kan omleiden. Een peer bewerken is dus een routingwijziging in vermomming. Bekijk beide tegelijk, anders repareer je de een en breek je de ander.

Inkomende pakketten worden op bron gecontroleerd

De bereiklijst vervult een dubbele rol. Voor uitgaand verkeer kiest hij een peer op bestemming, en voor inkomend verkeer autoriseert hij een bronadres. Een pakket dat binnenkomt vanaf een adres buiten de bereiken van die peer wordt weggegooid voordat een firewall het ziet.

Die asymmetrie is makkelijk te missen als je één kant van de configuratie leest. Een peer die een subnet kan bereiken, mag daarom nog niet vanaf dat subnet verzenden, en de twee richtingen worden door verschillende controles afgedwongen.

Smalle broneigendom maakt dit tot een voordeel. Geef elke peer een /32 voor zijn eigen adres en de firewall stroomafwaarts heeft een betrouwbare bron om te matchen, in plaats van een bereik voor de hele groep dat elk lid zou kunnen opeisen.

Dubbele bereiken zijn geen failover

Hetzelfde prefix aan twee peers toewijzen maakt geen load balancer of standby-pad. Er is geen healthcheck en geen sessieaffiniteit: de winnende regel wordt bepaald door de interne volgorde van de implementatie, en dat is geen contract waarop je moet ontwerpen. Als je alternatieve uitgangen nodig hebt, druk ze uit waar de selectie is gedefinieerd. Een routingbeleid, een metriek of een paar verschillende prefixen met elk een gedocumenteerde eigenaar leveren gedrag op dat je kunt voorspellen en testen.

Een bereik verbreden om een losstaande storing op te lossen is de andere veelgemaakte fout. Het verplaatst verkeer weg van de peer die werkte, en het nieuwe symptoom komt voordat het oude is begrepen.

Verifieer de selectie voordat je bewerkt

Drie commando’s beantwoorden de drie vragen in volgorde. De eerste somt de bereiken op die elke peer opeist. De tweede toont welke interface de host voor een bestemming zou gebruiken. De derde toont de live peer-status nadat er verkeer is gestroomd.

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

Voer ze voor en na een wijziging uit en vergelijk. Als de route-uitvoer is veranderd maar het verkeer nog steeds bij de verkeerde peer aankomt, overlappen de prefixlijsten op een manier die je nog niet hebt opgeschreven. Als de route-uitvoer niet is veranderd, was de peer-configuratie nooit wat er werd geraadpleegd.

Noteer de bestemming, de gekozen interface en de gekozen peer in het ticket. Die drie-eenheid maakt een overlap later controleerbaar, en is veel nuttiger dan een screenshot van de configuratie.