Les en WireGuard-konfigurasjon linje for linje, fra Interface til Peer
Interface-nøkler hører til dette endepunktet, peer-nøkler til den andre siden. Les hver linje som én retning, og bekreft deretter hva wg-quick la til rundt protokollen.
De fleste ødelagte WireGuard-konfigurasjoner tar ikke feil av en verdi; de setter riktig verdi på feil side. En privat nøkkel hører til denne maskinen, en peer bærer den andre maskinens offentlige nøkkel, og en adresse sitter i interface-blokken selv om den beskriver hvor tunnelen bor. Les filen som to retninger som møtes, og sjekk deretter hva hjelpeskriptet la til på toppen. Protokollen selv har færre felt enn filen, og de ekstra er verdt å kjenne separat.
Interface-nøkler beskriver denne maskinen
Interface-blokken holder dette endepunktets egen identitet. PrivateKey er den identiteten og forlater aldri verten; den samsvarende offentlige nøkkelen utledes fra den, og det er den andre peers lister. ListenPort er hvor denne siden mottar håndtrykk, så to klienter bak én adresse trenger forskjellige porter.
Address er tunneladressen denne verten svarer på, skrevet med en prefikslengde fordi den også er kilden den vil bruke. Feil prefiks her endrer hvilke destinasjoner verten tror er direkte tilkoblet, og det gir feil som ser ut som ruting og ikke som konfigurasjon.
Alt annet i en [Interface] blokk med en virkelig klient legges vanligvis til av wg-quick: DNS, MTU, Table, og krok-linjene. De er ikke protokollfelt, og et bart wg oppsett ignorerer dem helt.
Hver peer-oppføring beskriver én annen side
[Peer] blokk er den fjerne parten. PublicKey er den partens utledede nøkkel, aldri deres private nøkkel, og PresharedKey er en valgfri ekstra hemmelighet som begge sider må holde identisk. Endpoint er hvor det skal sendes, og PersistentKeepalive ber denne verten sende en pakke etter intervallet når ingenting annet går ut.
To feil forklarer det meste av forvirringen her. Å kopiere sin egen private nøkkel inn i en peer-blokk gjør at de to endene deler én identitet, og håndtrykket feiler på en måte som logges dårlig. Endpoint å utelate på en klient er vanligvis med vilje, fordi serveren lærer adressen fra det innkommende håndtrykket; å utelate det på en server som må initiere er det ikke. Husk også at keepalive holder en NAT-mapping åpen, og det forbedrer ikke gjennomstrømningen eller reduserer latensen, så tretti sekunder med ekstra pakker kjøper ingenting når trafikken allerede flyter.
AllowedIPs er ruting, ikke en tillatelsesliste
AllowedIPs er WireGuards kryptonøkkel-ruting. Utgående avgjør den hvilken peer som mottar en pakke basert på destinasjonen. Innkommende avgjør den om en pakke som kommer fra den peeren godtas basert på kilden. Det samme feltet gjør begge jobbene, og derfor er det ikke en tilgangskontrolliste og ikke en liste over tillatte nettsteder.
En smal AllowedIPs på serveren for en klient betyr at serveren bare godtar pakker som hevder disse kildene, og bare sender disse destinasjonene til den klienten. Utvid den ene siden uten å utvide den andre, og du får en tunnel som kommer opp og ikke slipper noe gjennom.
Hva wg-quick legger til rundt protokollen
wg-quick leser den samme filen og utfører nettverkstrinnene protokollen overlater til operativsystemet. Den tildeler interface-adressen, legger til ruter utledet fra AllowedIPs, skriver innstillingene for resolveren og kjører krok-kommandoene i rekkefølge.
Det laget forklarer den klassiske asymmetrien. En fil med 0.0.0.0/0 og en DNS linje gir en klient en standardrute og en resolver, og den gjør absolutt ingenting med serverens videresendings- eller NAT-regler. De hører til serverens egen konfigurasjon, og ingen klientfil kan levere dem.
Ha én eier av filen. Å redigere den for hånd mens SaveConfig er aktivert betyr at endringen din forsvinner neste gang interface går ned, og interface vil ikke fortelle deg at det skjedde.
Kontroller den anvendte tilstanden, ikke filen
Filen er en intensjon. Den anvendte tilstanden er det kjernen holder, og de divergerer hver gang en hjelper, en drop-in eller en krok redigerte noe etter aktiveringen.
Les den levende tilstanden og adresseringen sammen, og sammenlign deretter 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.confHvis peer-listen er tom, ble interface opprettet uten at konfigurasjonen ble anvendt. Hvis adresser og ruter finnes men tellerne blir stående på null, ble filen lastet og håndtrykket feiler, noe som er et nøkkel- eller endepunktproblem og ikke et seksjonsrekkefølgeproblem. Sammenlign de to visningene før du redigerer, fordi gapet mellom dem vanligvis er den egentlige feilen.