WireGuard AllowedIPs: rutten som NetworkManager aldrig lade till
En giltig WireGuard-profil kan slutföra handskakningen och ändå inte skicka något. Jämför kärntabellen med AllowedIPs och ge sedan rutten en enda ägare.
Handskakningsräknaren uppdateras, gränssnittet behåller sin adress, och en ping till andra sidan kommer ingenstans. Den kombinationen förvirrar folk, eftersom en fungerande handskakning känns som bevis på att tunneln är klar. Det är den inte: en tunnel kan vara fullt förhandlad och ändå sakna varje rutt som leder trafik in i den, och det är två åtskilda jobb som utförs av två åtskilda bitar tillstånd. Åtgärden beror helt på vilken av de två som saknas, så första steget är att ta reda på det.
wg-quick gör båda utan att bli tillfrågad. NetworkManagers inbyggda WireGuard-stöd installerar också peer-rutter som standard, vilket begränsar de misstänkta till ett inaktiverat alternativ, en annan routingtabell eller en konfiguration som importerats via något annat.
Bekräfta tunneln innan du jagar rutten
wg show skriver ut gränssnittet, peeren, slutpunkten och åldern på den senaste handskakningen, och ip addr show bekräftar att adressen finns. En nylig handskakning betyder att nycklarna, slutpunkten och UDP-vägen fungerar. Allt som är trasigt sitter nedströms om dem: routing, filtrering eller namnuppslagning.
Fråga sedan kärnan vad den skulle göra med en riktig destination i stället för en hypotetisk: ip route get 10.42.7.9. Svaret namnger det utgående gränssnittet och källadressen som paketet skulle bära. När det namnger den fysiska adaptern kommer paketet aldrig in i tunneln, hur sunt handskakningen än ser ut.
AllowedIPs är ett filter och en ruttlista
Prefixen i AllowedIPs gör två jobb. De väljer vilken peer som bär en utgående destination, och de validerar källadressen för inkommande paket, vilket är gränsen för kryptonyckelrouting. I wg-quick styr de också automatisk ruttinstallation, och just det extra beteendet är anledningen till att samma konfiguration fungerar från en terminal och inte från en skrivbordsklient.
I fallet bakom den här artikeln importerades profilen via ett tredjepartstillägg i stället för via det inbyggda stödet, och gränssnittet kom upp utan prefixrutten. En lista över tabellen visar det direkt: ip route show innehåller bara den anslutna rutten för gränssnittsadressen och ingenting för det avlägsna området.
Fråga om peer-rutter är påslagna överhuvudtaget
Läs inställningen innan du ändrar något: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. När peer-routes visar no är den stödda reparationen nmcli connection modify work-wg wireguard.peer-routes yes, följt av en återanslutning. Att i stället lägga till en statisk rutt fungerar till nästa aktivering och försvinner sedan tyst. Det försvinnandet är ledtråden: en rutt som kommer tillbaka som ett mysterium varje morgon installeras inte av profilen.
Om alternativet redan är påslaget, kontrollera med ip route show table all | grep 10 om prefixet bor i en annan tabell. En rutt i en tabell som inte är huvudtabellen saknas inte, den är bara osynlig för en sökning som bara tittar i huvudtabellen. Reparera policyroutingen i stället för att stapla en dubblerad post ovanpå.
Lägg till prefixet i anslutningen, inte i det körande systemet
I anslutningsredigeraren håller WireGuard-sidan peeren och dess AllowedIPs, och IPv4-sidan håller extra rutter. En rutt som läggs till där överlever återanslutningar eftersom den tillhör profilen. På kommandoraden är motsvarigheten att lägga till en rutt i anslutningen i formen med tom gateway, och sedan ta anslutningen ned och upp så att ändringen tillämpas.
Välj det smalaste prefix som täcker de värdar du behöver. Att kopiera leverantörens exempel /8 kan svälja lokala områden som råkar ligga inuti det, och felen som följer ser ut som en trasig tunnel snarare än en för bred rutt.
Delad tunnel avgörs av prefixlistan
Det finns ingen brytare för delad tunnel; prefixlistan är beslutet. En peer med ett område för kontorets LAN och ett för ett laboratorienätverk skickar exakt dessa destinationer genom tunneln och lämnar allt annat i fred. En enda värd behöver en /32, och överlappande områden på två platser behöver värdprefix tills någon numrerar om ett subnät.
Att välja att inte skicka något genom tunneln driver samma beslut till sin gräns: en minimal lista håller länken uppe medan vanlig trafik håller sig på sin vanliga väg. Skriv ner avsikten, annars kommer nästa läsare att behandla den korta listan som en förbiseende och hjälpsamt utöka den.
En ägare för routingtabellen
wg-quick och NetworkManager anser båda att de äger gränssnittets rutter. Importera en konfiguration skriven för wg-quick och starta sedan också wg-quick-tjänsten, och du får dubblerade eller motstridiga poster vars beteende beror på vilken som kördes sist. Välj en enda ägare och ta bort den andra: om NetworkManager hanterar anslutningen, inaktivera wg-quick-enheten för det gränssnittet, och lägg aldrig till en andra profil för samma enhet.
När uppdelningen måste följa en fysisk adapter i stället för en destination har du flyttat till policyrouting, och policyrouting behöver också en enda författare. Bekräfta genom att upprepa ip route get och sedan nå en värd inne i det avlägsna prefixet med något som skriver ut källadressen den valde. Kontrollera IPv6 och DNS separat om profilen bär någon av dem.