WireGuard delad tunnel: ställ in den utan standardrutt

En delad tunnel definieras av det du utelämnar, och WireGuard fattar det beslutet i ett enda fält. AllowedIPs på klientens peer väljer samtidigt vilka destinationer som går genom tunneln och filtrerar vilka inre källadresser som accepteras, och wg-quick gör samma lista till värdrutter. Om listan är fel sväljer tunneln allt eller bär ingenting.

Bestäm prefixlistan först

Skriv ner de destinationer som måste använda tunneln innan du rör en konfigurationsfil. Kontorsnät, ett databasintervall, ett hanteringsnät: var och en är ett prefix med en anledning. Allt som inte står på listan stannar på den fysiska vägen, och det är hela poängen med designen.

Om listan innehåller 0.0.0.0/0 eller ::/0 har du byggt en full tunnel och bör säga det, eftersom fellägena och DNS-förväntningarna skiljer sig.

Håll listan kort nog att en granskare senare kan jämföra den med routingtabellen.

Klientkonfiguration: peer, AllowedIPs, DNS

Klientens gränssnittsblock innehåller dess egen tunneladress och privata nyckel. Peerblocket innehåller serverns publika nyckel, slutpunkten och prefixen från första steget:

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

AllowedIPs på klienten är mängden avlägsna destinationer, inte klientens egen adress. DNS-raden verkar bara genom wg-quicks resolverintegration, så en värd utan stöd för resolvconf eller systemd-resolved ignorerar den. PersistentKeepalive håller en NAT-mappning vid liv och behövs inte på en direkt väg.

Kommentera varje prefix med tjänsten det betjänar, annars blir nästa ändring en gissning.

Serverkonfiguration: den motsatta synvinkeln

På servern representerar peer-posten klienten, så dess AllowedIPs är klientens tunneladress, vanligtvis en /32. Det är inte kontorsnätet. Att kopiera klientens lista till serverposten är det vanligaste misstaget vid delad tunnel, och det utökar antingen åtkomsten eller bryter den inre källkontrollen vid handskakningen.

Serverns egen gränssnittsadress och de rutter den behöver mot kontoret är åtskilda från varje peer-post.

Två filer, två synvinklar, en uppsättning prefix delad mellan dem.

Ta upp den och läs rutterna

Starta gränssnittet med den stödda hanteraren och titta sedan på vad den installerade, inte vad du avsåg. wg-quick härleder rutter från AllowedIPs; om profilen sätter Table = off installeras ingenting och routingen är din. Läs rutten för varje prefix och bekräfta att den pekar på WireGuard-gränssnittet. En tom ruttlista betyder oftast att profilen som användes inte är den du redigerade.

Kontrollera även handskakningsräknarna, eftersom en peer utan handskakning har ett nyckel-, slutpunkts- eller nåbarhetsproblem, inte ett routingproblem.

Skriv ner det exakta kommando du använde, eftersom nästa person kommer att köra det under press.

Verifiera båda sidor och notera sedan återställningen

Testa en privat adress, dess interna namn och en destination som måste förbli direkt. Om den privata adressen fungerar och den direkta nu lämnar genom tunneln är prefixlistan för bred. Om namnet misslyckas medan adressen fungerar trädde inte DNS-raden i kraft. Återställning är ett kommando, och det hör i samma anteckning.

Efter en återanslutning, bekräfta att rutterna fortfarande finns, eftersom en hanterare som tillämpar profilen igen kan ersätta manuella rutter.

Håll en enda konfigurationsägare, eftersom två hanterare som producerar samma gränssnitt till slut kommer att bli oense. wg-quick-handboken dokumenterar det rutt- och DNS-beteende den erbjuder.