Læs en WireGuard-konfiguration linje for linje, fra Interface til Peer

De fleste ødelagte WireGuard-konfigurationer tager fejl af en værdi; de sætter den rigtige værdi på den forkerte side. En privat nøgle hører til denne maskine, en peer bærer den anden maskines offentlige nøgle, og en adresse står i interface-blokken, selv om den beskriver, hvor tunnelen bor. Læs filen som to retninger, der mødes, og kontroller så, hvad hjælpescriptet tilføjede ovenpå. Protokollen selv har færre felter end filen, og de ekstra er værd at kende separat.

Interface-nøgler beskriver denne maskine

Interface-blokken rummer dette endepunkts egen identitet. PrivateKey er den identitet og forlader aldrig værten; den matchende offentlige nøgle udledes af den, og det er den, andre peers angiver. ListenPort er hvor denne side modtager handshakes, så to klienter bag én adresse skal bruge forskellige porte.

Address er den tunneladresse, denne vært svarer på, skrevet med en præfikslængde, fordi den også er den kilde, den vil bruge. Forkert præfiks her ændrer, hvilke destinationer værten anser for at være direkte forbundet, og det giver fejl, der ligner routing frem for konfiguration.

Alt andet i en [Interface] blok med en virkelig klient tilføjes normalt af wg-quick: DNS, MTU, Table, og hook-linjerne. De er ikke protokolfelter, og et bart wg opsætning ignorerer dem helt.

Hver peer-post beskriver en anden side

En [Peer] blok er den fjerneste part. PublicKey er den parts udledte nøgle, aldrig deres private nøgle, og PresharedKey er en valgfri ekstra hemmelighed, som begge sider skal have identisk. Endpoint er hvor der skal sendes hen, og PersistentKeepalive beder denne vært sende en pakke efter intervallet, når intet andet går ud.

To fejl forklarer det meste af forvirringen her. At kopiere sin egen private nøgle ind i en peer-blok får de to ender til at dele én identitet, og handshaket fejler på en måde, der logges dårligt. At udelade Endpoint på en klient er normalt bevidst, fordi serveren lærer adressen fra det indgående handshake; at udelade den på en server, der skal tage initiativ, er det ikke. Husk også, at keepalive holder en NAT-mapping åben, og det forbedrer ikke gennemstrømningen eller sænker latenstiden, så tredive sekunders ekstra pakker køber intet, når trafikken allerede flyder.

AllowedIPs er routing, ikke en tilladelsesliste

AllowedIPs er WireGuards kryptonøgle-routing. Udadtil afgør den, hvilken peer der modtager en pakke ud fra dens destination. Indadtil afgør den, om en pakke, der ankommer fra den peer, accepteres ud fra dens kilde. Det samme felt gør begge ting, og derfor er det ikke en adgangskontrolliste og ikke en liste over tilladte websteder.

En snæver AllowedIPs på serveren for en klient betyder, at serveren kun accepterer pakker, der hævder disse kilder, og kun sender disse destinationer til den klient. Udvid den ene side uden at udvide den anden, og du får en tunnel, der kommer op og ikke sender noget igennem.

Hvad wg-quick tilføjer omkring protokollen

wg-quick læser den samme fil og udfører de netværkstrin, som protokollen overlader til styresystemet. Den tildeler interface-adressen, tilføjer ruter udledt af AllowedIPs, skriver resolver-indstillingerne og kører hook-kommandoerne i rækkefølge.

Det lag forklarer den klassiske asymmetri. En fil med 0.0.0.0/0 og en DNS linje giver en klient en standardrute og en resolver, og den gør absolut intet ved serverens videresendelses- eller NAT-regler. De hører til serverens egen konfiguration, og ingen klientfil kan levere dem.

Hold én ejer af filen. At redigere den i hånden, mens SaveConfig er aktiveret, betyder, at din ændring forsvinder næste gang, interfacet går ned, og interfacet fortæller dig ikke, at det skete.

Kontrollér den anvendte tilstand, ikke filen

Filen er en intention. Den anvendte tilstand er det, kernen holder, og de divergerer, når en hjælper, en drop-in eller et hook har redigeret noget efter aktiveringen.

Læs den levende tilstand og adresseringen sammen, og sammenlign derefter begge 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

Hvis peer-listen er tom, blev interfacet oprettet, uden at dets konfiguration blev anvendt. Hvis adresser og ruter findes, men tællerne bliver på nul, blev filen indlæst, og handshaket fejler, hvilket er et nøgle- eller endepunktproblem frem for et sektionsrækkefølgeproblem. Sammenlign de to visninger, før du redigerer, fordi forskellen mellem dem normalt er den egentlige fejl.