Lees 'n WireGuard-konfigurasie reël vir reël, van Interface tot Peer

Die meeste stukkende WireGuard-konfigurasies het nie die verkeerde waarde nie; hulle sit die regte waarde aan die verkeerde kant. 'n Privaatsleutel hoort by hierdie masjien, 'n peer dra die ander masjien se publieke sleutel, en 'n adres staan in die interface-blok al beskryf dit waar die tonnel woon. Lees die lêer as twee rigtings wat mekaar ontmoet, en kyk dan wat die hulpskrip bo-op bygevoeg het. Die protokol self het minder velde as die lêer, en die ekstra velde is werd om apart te ken.

Interface-sleutels beskryf hierdie masjien

Die interface-blok hou hierdie eindpunt se eie identiteit. PrivateKey is daardie identiteit en verlaat nooit die gasheer nie; die ooreenstemmende publieke sleutel word daaruit afgelei en dit is wat ander peers lys. ListenPort is waar hierdie kant handskuddings ontvang, so twee kliënte agter een adres het verskillende poorte nodig.

Address is die tonneladres waarop hierdie gasheer antwoord, geskryf met 'n voorvoegsellengte omdat dit ook die bron is wat hy sal gebruik. Om die voorvoegsel hier verkeerd te kry, verander watter bestemmings die gasheer as on-link beskou, wat foute lewer wat soos roetering eerder as konfigurasie lyk.

Alles anders in 'n [Interface] blok met 'n werklike kliënt word gewoonlik bygevoeg deur wg-quick: DNS, MTU, Table, en die haaklyne. Hulle is nie protokolvelde nie, en 'n kaal wg opstelling ignoreer hulle heeltemal.

Elke peer-inskrywing beskryf een ander kant

'n [Peer] blok is die ander party. PublicKey is daardie party se afgeleide sleutel, nooit hulle privaatsleutel nie, en PresharedKey is 'n opsionele ekstra geheim wat beide kante identies moet hou. Endpoint is waarheen om te stuur, en PersistentKeepalive vra hierdie gasheer om 'n pakkie te stuur ná die interval wanneer niks anders uitgaan nie.

Twee foute verklaar die meeste verwarring hier. Om jou eie privaatsleutel in 'n peer-blok te kopieer, maak dat die twee kante een identiteit deel, en die handskud misluk op 'n manier wat swak logs lewer. Om Endpoint op 'n kliënt weg te laat is gewoonlik opsetlik, want die bediener leer die adres uit die inkomende handskud; om dit weg te laat op 'n bediener wat moet begin, is nie. Onthou ook dat keepalive 'n NAT-kaarte oop hou, en dit verbeter nie deurset nie en verminder nie latensie nie, so dertig sekondes se ekstra pakkies koop niks as verkeer reeds vloei.

AllowedIPs is roetering, nie 'n toestemmingslys nie

AllowedIPs is WireGuard se kriptosleutelroetering. Uitwaarts besluit dit watter peer 'n pakkie ontvang op grond van sy bestemming. Inwaarts besluit dit of 'n pakkie wat van daardie peer aankom, aanvaar word op grond van sy bron. Dieselfde veld doen albei take, daarom is dit nie 'n toegangsbeheerlys nie en ook nie 'n lys van toegelate webwerwe nie.

'n Smal AllowedIPs op die bediener vir 'n kliënt beteken die bediener aanvaar net pakkies wat daardie bronne beweer, en stuur net daardie bestemmings na daardie kliënt. Verbreed een kant sonder om die ander te verbreed, en jy kry 'n tonnel wat opkom en niks deurlaat nie.

Wat wg-quick rondom die protokol byvoeg

wg-quick lees dieselfde lêer en doen die netwerkstappe wat die protokol aan die bedryfstelsel oorlaat. Dit wys die interface-adres toe, voeg roetes by wat uit AllowedIPs afgelei is, skryf die oplosserinstellings en voer die haakopdragte in volgorde uit.

Daardie laag verduidelik die klassieke asimmetrie. 'n Lêer met 0.0.0.0/0 en 'n DNS reël gee 'n kliënt 'n verstekroete en 'n oplosser, en dit doen glad niks aan die bediener se deurgee- of NAT-reëls nie. Daardie dinge hoort by die bediener se eie konfigurasie, en geen kliëntlêer kan dit verskaf nie.

Hou een eienaar vir die lêer. Om dit met die hand te wysig terwyl SaveConfig geaktiveer is, beteken jou wysiging verdwyn die volgende keer dat die interface afgaan, en die interface sal jou nie vertel dat dit gebeur het nie.

Kontroleer die toegepaste toestand, nie die lêer nie

Die lêer is 'n voorneme. Die toegepaste toestand is wat die kern hou, en hulle wyk af wanneer 'n hulp, 'n drop-in of 'n haak iets ná aktivering gewysig het.

Lees die lewende toestand en die adressering saam en vergelyk dan albei met wat jy geskryf het:

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

As die peer-lys leeg is, is die interface geskep sonder dat sy konfigurasie toegepas is. As adresse en roetes bestaan maar tellers op nul bly, het die lêer gelaai en die handskud misluk, wat 'n sleutel- of eindpuntprobleem is eerder as 'n afdelingorde-probleem. Vergelyk die twee sienings voordat jy wysig, want die gaping tussen hulle is gewoonlik die werklike fout.