WireGuard-værtspræfiks: hvorfor én adresse virker, og resten ikke

Tunnelen er oppe, håndtrykket sker hvert andet minut, og præcis én adresse på den anden side svarer. Ping til peerens tunneladresse virker; intet bag den gør. Nogen læser interfacekonfigurationen, ser et værtspræfiks og konkluderer, at masken er forkert. At udvide den til et /24 løser pingen i et stykke tid og ødelægger derefter noget andet. Præfikset var aldrig fejlen, og den manglende rute er ikke den, masken styrer.

Hvad interfacepræfikset faktisk opretter

På Linux opretter det at tildele en adresse til en interface en forbundet rute for det præfiks. Tildeler du et værtspræfiks, dækker den forbundne rute én adresse. Tildeler du et /24, dækker den 256, og hver af dem betragtes nu som tilgængelig over det link.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Et værtspræfiks er et helt normalt valg til en punkt-til-punkt-tunnel, for der er præcis én peer i den anden ende. Den tredje kommando er den, der besvarer brugerens spørgsmål: den siger, hvilken interface kernen ville bruge til den destination, og den viser intet brugbart, hvis ingen rute passer.

Det er hele forklaringen på symptomet. Én adresse svarer, fordi der findes en forbundet rute til den, eller fordi peerens tilladte liste tilfældigvis indeholder den. Alt andet har ingen rute og kasseres, før WireGuard overhovedet er involveret. Tunnelen er sund hele vejen igennem, og derfor fortsætter håndtrykstælleren med at se betryggende ud.

AllowedIPs er to regler under ét navn

WireGuards tilladte liste pr. peer udfører to opgaver på én gang, og konfigurationssyntaksen får dem til at se ud som én. Indgående bestemmer den, hvilke kildeadresser en peer må præsentere. Udgående vælger den, hvilken peer et paket sendes til, ved at finde det mest specifikke match.

Ingen af opgaverne er routing. Kernen skal stadig beslutte, at et paket hører på tunnelinterfacet, før WireGuard overhovedet ser på det, og den beslutning kommer fra routingtabellen. En peer-post med en bred tilladt liste installerer ikke en rute af sig selv.

Derfor kan en konfiguration se komplet ud og opføre sig asymmetrisk. Klienten sender til den anden ende, fordi der findes en rute, og svar ankommer aldrig, fordi den anden endes tilladte liste ikke tillader klientens kilde, eller fordi den anden ende ikke har nogen returvej. Begge retninger er separate beslutninger med separate fejlmønstre. At skrive ned, hvilken man tester, er halvdelen af diagnosen.

Hvor ruten kommer fra

Hvis du bruger wg-quick, genereres ruterne for dig ud fra hver peers tilladte liste, medmindre du har sat Table = off og selv overtaget styringen. Det er den adfærd, værktøjet dokumenterer, og det er grunden til, at en konfiguration uden eksplicitte routedirektiver stadig virker.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Sammenlign den tilladte liste med de ruter, der faktisk findes. En peer, der tillader et helt subnet, men kun har skabt en værtsrute, betyder, at hjælperen aldrig kørte, eller at du styrer interfacet direkte med wg og ip; så genererer intet ruter for dig.

Når du styrer det i hånden, er ruten én linje, og dens form er eksplicit: destinationen gennem interfacet, uden gateway, fordi linket er punkt-til-punkt. At tilføje den er ikke en nødløsning på et dårligt præfiks; det er den manglende halvdel af et design, der bevidst selv styrer routing.

Et bredere præfiks tilføjer ikke peer-posten

Den fristende løsning er at ændre adressen til et /24, så den forbundne rute dækker serverens LAN. Det ser ud til at virke, og grunden til, at det ser ud til at virke, er, at den forbundne rute nu passer, ikke at WireGuard har lært noget nyt.

Det, du også gjorde, er at gøre krav på hele området som direkte tilgængeligt over det link, inklusive adresser, der hører til andre peers eller til et LAN, der faktisk ligger bag serveren. Trafik til de adresser går nu ind i tunnelen, og om den kommer ud på den anden side, afhænger af serverens egen routing og tilladte lister.

Kryptosiden er upåvirket uanset hvad. WireGuard har stadig brug for en post i den tilladte liste, der dækker destinationen, for at vælge en peer, og den anden ende har stadig brug for en post, der dækker din kilde, for at acceptere den. Et bredere interfacepræfiks kan ikke levere nogen af delene.

Bekræft begge retninger, før du ændrer noget

Arbejd de to ender hver for sig og skriv ned, hvad hver af dem siger. På klienten ruten og peer-posten; på serveren spejlbilledet plus dens egen returvej:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

Optagelsen er det, der afgør strid om retning. Hvis udgående pakker dukker op på tunnelinterfacet, og serveren ikke logger noget, afviser den anden ende dem, normalt fordi din kilde ligger uden for dens tilladte liste. Hvis der slet ikke dukker noget op, mangler ruten, eller den peger et andet sted hen.

Reparer så den smalleste ende. En post i den tilladte liste på serversiden til din klientadresse og en post på klientsiden til destinationssubnettet er den normale form, og den lader interfacepræfikset være. Udvid kun præfikset, hvis adresseplanen virkelig vil have et delt subnet på det link, og gør det som en planændring i stedet for som et fejlsøgningstrin.