AllowedIPs är en routinglista, inte en brandväggsregel

De flesta läser AllowedIPs som en tillåtelselista, mängden adresser som får ansluta till en peer, ungefär som en brandväggsregel skriven för en tunnel. Så är det inte. Fältet är en routingtabell som arbetar i båda riktningarna: det väljer en peer för ett utgående paket och validerar källan för ett inkommande. Att läsa det som en åtkomstlista ger konfigurationer som routar trafik ingen har bett om.

Ett fält, två läsare: val ut och källkontroll

Hos en klient avgör prefixen vilka destinationer som reser till den peeren och vilka som stannar på det vanliga nätet. En post för 0.0.0.0/0 fångar därför varje IPv4-destination, och därför skickar import av en fulltunnelprofil vanligt surfande genom fjärrmaskinen. Smala poster gör det motsatta: de routar bara nätverken du listat och lämnar allt annat där det var. Avsnittet om kryptonyckelrouting i WireGuard-dokumentationen anger båda uppgifterna på ett ställe: val av utgående peer och validering av inkommande källa.

På servern beskriver samma fält vilka källadresser varje peer får använda. Det är en kryptografisk kontroll och inte ett paketfilter: ett paket vars inre källa inte matchar peerens lista släpps inuti WireGuard innan någon brandvägg på värden ser det. Båda uppgifterna delar en lista, och just därför beter sig en lista kopierad från annat håll fel på en plats du inte hade tänkt på.

Klientblocket är där det mesta av den här förvirringen börjar. En delad tunnel namnger fjärrnäten, och en full tunnel är samma fält med ett standardprefix:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Båda formerna är kompletta i sig, och de är alternativ snarare än steg. Den första skickar bara de två näten genom tunneln; den andra skickar varje destination, med posten ::/0 som lägger IPv6 till IPv4-standarden. Vilket du än väljer är dessa prefix hela routingbeslutet för den peeren när wg-quick börjar installera rutter.

Hubben behöver en annan lista

En hubb listar varje klients tunneladress som värdprefix, plus varje nätverk som verkligen ligger bakom den klienten. Att kopiera en klients breda lista till varje hubb-peer säger till hubben att många peers får använda samma adresser som källa, och det är ingen adressplan. Fältet Endpoint hör till ett helt annat lager: det namnger peerens yttre adress och port, aldrig en destination inuti tunneln.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

Värdprefixet bär tunneladressen och nätverksprefixet bär det som ligger bakom klienten, och båda behövs. Utan värdprefixet kan hubben inte returnera klientens egen trafik, och utan nätverksprefixet blir LAN:et bakom oåtkomligt; en peer utan något bakom sig får bara värdprefixet.

Att hoppa över ruttinstallation lämnar en lucka

wg-quick, hjälparen som reser ett gränssnitt från en konfigurationsfil, installerar gränssnittsadresser och rutter som en del av det arbetet. Att sätta Table = off säger till hjälparen att hoppa över ruttarbetet, vilket inte installerar ersättningar och inte gör det privata nätet nåbart. När automatiska rutter redan gör jobbet är det tydligare konfigurationen att namnge de prefix du behöver. Att stänga av routehantering och lämna ersättningen oskriven är inte en design, det är en utelämning.

Grundverktyget wg beter sig annorlunda: det konfigurerar gränssnittet och rör aldrig rutter, så en uppsättning byggd direkt på det behöver egna ruttkommandon. Instruktioner skrivna för ett verktyg kan se fel ut när de följs med det andra. En lyckad ping är också svagt bevis, eftersom den prövar en väg i stället för varje programväg du behöver.

DNS och IPv6 avgörs var för sig

Kontrollera DNS-serveradressen som tunneln annonserar och bekräfta att det finns en rutt till den adressen via de prefix du valde. En resolverinställning gör inte resolvern nåbar, och att snäva in en tunnel kan tyst ta bort rutten som ledde dit. Granska också IPv6 för sig, eftersom en korrekt IPv4-delning inte säger något om en IPv6-standardrutt som fortfarande pekar på den fysiska länken. Tre separata beslut kan ändras samtidigt när du redigerar ett peer-block.

Öppna sedan en privat resurs och en vanlig webbplats från en känd startkonfiguration. Om resursen svarar och surfandet fortfarande går ut genom den lokala anslutningen gör delningen det du bad om. Om surfandet bryts i samma ögonblick har tunneln tagit standardrutten, och prefixlistan är stället att titta på.