Läs en WireGuard-konfiguration rad för rad, från Interface till Peer

De flesta trasiga WireGuard-konfigurationer har inte fel värde; de sätter rätt värde på fel sida. En privat nyckel hör till den här maskinen, en peer bär den andra maskinens publika nyckel, och en adress sitter i interface-blocket fast den beskriver var tunneln bor. Läs filen som två riktningar som möts och kontrollera sedan vad hjälpscriptet lade till ovanpå. Protokollet självt har färre fält än filen, och de extra är värda att känna till separat.

Interface-nycklar beskriver den här maskinen

Interface-blocket håller den här änden egen identitet. PrivateKey är den identiteten och lämnar aldrig värden; den matchande publika nyckeln härleds från den och det är den andra peers listar. ListenPort är där den här sidan tar emot handskakningar, så två klienter bakom en adress behöver olika portar.

Address är tunneladressen som värden svarar på, skriven med en prefixlängd eftersom den också är källan som den kommer att använda. Fel prefix här ändrar vilka destinationer värden tror är direkt anslutna, och det ger fel som ser ut som routning och inte som konfiguration.

Allt annat i ett [Interface] block med en riktig klient läggs vanligtvis till av wg-quick: DNS, MTU, Table, och hook-raderna. Det är inga protokollfält, och en bar wg uppsättning ignorerar dem helt.

Varje peer-post beskriver en annan sida

Ett [Peer] block är den andra parten. PublicKey är den partens härledda nyckel, aldrig deras privata nyckel, och PresharedKey är en valfri extra hemlighet som båda sidor måste hålla identisk. Endpoint är vart det ska skickas, och PersistentKeepalive ber den här värden skicka ett paket efter intervallet när inget annat går ut.

Två misstag förklarar det mesta av förvirringen här. Att kopiera sin egen privata nyckel till ett peer-block får de två ändarna att dela en identitet, och handskakningen misslyckas på ett sätt som loggas dåligt. Endpoint att utelämna på en klient är oftast medvetet, eftersom servern lär sig adressen från den inkommande handskakningen; att utelämna det på en server som måste initiera är det inte. Kom också ihåg att keepalive håller en NAT-mappning öppen, och det förbättrar inte genomströmningen eller minskar latensen, så trettio sekunder extra paket köper ingenting när trafiken redan flödar.

AllowedIPs är routning, inte en tillåtelselista

AllowedIPs är WireGuards kryptonyckel-routning. Utgående avgör den vilken peer som tar emot ett paket baserat på destinationen. Inkommande avgör den om ett paket från den peeren accepteras baserat på källan. Samma fält gör båda jobben, därför är det inte en åtkomstkontrollista och inte en lista över tillåtna webbplatser.

En smal AllowedIPs på servern för en klient betyder att servern bara accepterar paket som hävdar dessa källor, och bara skickar dessa destinationer till den klienten. Vidga ena sidan utan att vidga den andra, och du får en tunnel som kommer upp och inte släpper igenom något.

Vad wg-quick lägger till runt protokollet

wg-quick läser samma fil och utför nätverksstegen som protokollet lämnar till operativsystemet. Det tilldelar interface-adressen, lägger till rutter härledda från AllowedIPs, skriver resolverinställningarna och kör hook-kommandona i ordning.

Det lagret förklarar den klassiska asymmetrin. En fil med 0.0.0.0/0 och en DNS rad ger en klient en standardrutt och en resolver, och den gör absolut ingenting åt serverns vidarebefordrings- eller NAT-regler. De hör till serverns egen konfiguration, och ingen klientfil kan leverera dem.

Håll en ägare till filen. Att redigera den för hand medan SaveConfig är aktiverat betyder att din ändring försvinner nästa gång interface går ner, och interface kommer inte att berätta att det hände.

Kontrollera det tillämpade tillståndet, inte filen

Filen är en avsikt. Det tillämpade tillståndet är vad kärnan håller, och de divergerar varje gång ett hjälpmedel, en drop-in eller en hook redigerade något efter aktiveringen.

Läs det levande tillståndet och adresseringen tillsammans och jämför sedan båda med det du skrev:

sudo wg show
ip -4 addr show dev wg0
ip -4 route show dev wg0
grep -v "^#" /etc/wireguard/wg0.conf

Om peer-listan är tom skapades interface utan att dess konfiguration tillämpades. Om adresser och rutter finns men räknarna stannar på noll laddades filen och handskakningen misslyckas, vilket är ett nyckel- eller ändpunktsproblem och inte ett sektionsordningsproblem. Jämför de två vyerna före redigering, eftersom gapet mellan dem vanligtvis är det egentliga felet.