WireGuard-värdprefix: varför en adress fungerar och resten inte

Tunneln är uppe, handskakningen sker varannan minut, och exakt en adress på andra sidan svarar. Ping mot peerns tunneladress fungerar; inget bakom den gör det. Någon läser gränssnittskonfigurationen, ser ett värdprefix och drar slutsatsen att masken är fel. Att bredda den till ett /24 lagar pinget ett tag och förstör sedan något annat. Prefixet var aldrig felet, och den saknade rutten är inte den som masken styr.

Vad gränssnittsprefixet faktiskt skapar

På Linux skapar det att man tilldelar en adress till ett gränssnitt en ansluten rutt för det prefixet. Tilldelar du ett värdprefix täcker den anslutna rutten en adress. Tilldelar du ett /24 täcker den 256, och var och en av dem betraktas nu som nåbar över den länken.

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

Ett värdprefix är ett helt normalt val för en punkt-till-punkt-tunnel, för det finns exakt en peer i andra änden. Det tredje kommandot är det som besvarar användarens fråga: det säger vilket gränssnitt kärnan skulle använda för destinationen, och det visar inget användbart om ingen rutt matchar.

Det är hela förklaringen till symptomet. En adress svarar därför att det finns en ansluten rutt till den, eller därför att peerns tillåtna lista råkar innehålla den. Allt annat har ingen rutt och kastas innan WireGuard ens är inblandat. Tunneln är frisk hela tiden, och därför fortsätter handskakningsräknaren att se betryggande ut.

AllowedIPs är två regler under ett namn

WireGuards tillåtna lista per peer utför två uppgifter samtidigt, och konfigurationssyntaxen får dem att se ut som en. Inkommande avgör den vilka källadresser en peer får presentera. Utgående väljer den vilken peer ett paket skickas till, genom att hitta den mest specifika matchningen.

Ingen av uppgifterna är routing. Kärnan måste fortfarande avgöra att ett paket hör hemma på tunnelgränssnittet innan WireGuard ens tittar på det, och det beslutet kommer från routingtabellen. En peer-post med en bred tillåten lista installerar ingen rutt av sig själv.

Därför kan en konfiguration se komplett ut och bete sig asymmetriskt. Klienten skickar till andra änden därför att det finns en rutt, och svar kommer aldrig fram därför att andra ändens tillåtna lista inte tillåter klientens källa, eller därför att andra änden inte har någon returväg. Båda riktningarna är separata beslut med separata felmönster. Att skriva ner vilken man testar är halva diagnosen.

Varifrån rutten kommer

Om du använder wg-quick genereras rutterna åt dig från varje peers tillåtna lista, om du inte har satt Table = off och tagit över styrningen själv. Det är beteendet verktyget dokumenterar, och det är skälet till att en konfiguration utan explicita rutt-direktiv ändå fungerar.

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

Jämför den tillåtna listan med de rutter som faktiskt finns. En peer som tillåter ett helt subnät men bara skapade en värdrutt betyder att hjälparen aldrig körde, eller att du hanterar gränssnittet direkt med wg och ip; då genererar inget rutter åt dig.

När du hanterar det för hand är rutten en rad och dess form explicit: destinationen genom gränssnittet, utan gateway eftersom länken är punkt-till-punkt. Att lägga till den är ingen nödlösning för ett dåligt prefix; det är den saknade halvan av en design som medvetet sköter routing själv.

Ett bredare prefix lägger inte till peer-posten

Den frestande lösningen är att ändra adressen till ett /24 så att den anslutna rutten täcker serverns LAN. Det verkar fungera, och skälet till att det verkar fungera är att den anslutna rutten nu matchar, inte att WireGuard har lärt sig något nytt.

Vad du också gjorde var att göra anspråk på hela intervallet som direkt nåbart över den länken, inklusive adresser som tillhör andra peers eller ett LAN som faktiskt ligger bakom servern. Trafik till de adresserna går nu in i tunneln, och om den kommer ut på andra sidan beror på serverns egen routing och tillåtna listor.

Kryptosidan är opåverkad oavsett. WireGuard behöver fortfarande en post i den tillåtna listan som täcker destinationen för att välja en peer, och andra änden behöver fortfarande en post som täcker din källa för att acceptera den. Ett bredare gränssnittsprefix kan inte leverera något av det.

Bekräfta båda riktningarna innan du ändrar något

Arbeta med de två ändarna var för sig och skriv ner vad var och en säger. På klienten rutten och peer-posten; på servern spegelbilden plus dess egen returväg:

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

Insamlingen är det som avgör tvister om riktning. Om utgående paket dyker upp på tunnelgränssnittet och servern inte loggar något, avvisar andra änden dem, oftast därför att din källa ligger utanför dess tillåtna lista. Om inget alls dyker upp saknas rutten, eller så pekar den någon annanstans.

Reparera sedan den smalaste änden. En post i den tillåtna listan på serversidan för din klientadress och en post på klientsidan för destinationssubnätet är den normala formen, och den lämnar gränssnittsprefixet i fred. Bredda bara prefixet om adressplanen verkligen vill ha ett delat subnät på den länken, och gör det som en planändring i stället för som ett felsökningssteg.