Hoe je een WireGuard-test met twee peers bouwt die één pad bewijst

Een WireGuard-test die een standaardroute, een LAN-prefix, DNS en een firewall-uitzondering draagt, kan je niet vertellen welk daarvan kapot is. Reduceer hem tot twee peers, één adrespaar en één toegestane dienst, en de fout heeft nergens meer om zich te verstoppen. De saaie basis is de diagnose. Bouw die eerst; het kost vijftien minuten en bespaart de middag die je anders met gissen zou doorbrengen.

Wat de basis bewijst is smaller dan de meeste mensen verwachten. Hij bewijst dat twee identiteiten het eens zijn, dat UDP de luisterende poort bereikt en dat één toegestane bestemming een verzoek draagt. Forwarding, NAT, LAN-routes en DNS zijn aparte functies die daarna worden toegevoegd, één voor één.

Sleutels, adressen en het enige endpoint

Genereer op elk systeem een sleutelpaar en verplaats alleen de openbare helften tussen hen. wg genkey | tee privatekey | wg pubkey > publickey is de gedocumenteerde oneliner, en hij laat de privésleutel achter in een bestand dat je daarna kunt beschermen. Kies tunneladressen uit een bereik dat in geen enkele andere configuratie van jou voorkomt, zoals 10.99.0.1/24 en 10.99.0.2/24. Noteer welk adres bij welke machine hoort, want elke latere controle hangt van die koppeling af.

Privésleutels reizen nooit. Als een test er één naar de andere kant moet kopiëren, is de test al misgegaan. Als de twee systemen achter NAT zitten, heeft minstens één een bereikbare UDP-poort nodig terwijl de andere een Endpoint draagt die daarheen wijst, en het openbare adres en de poort horen in je notities, niet in je aannames over 51820.

Een port forward die een andere externe poort mapt, werkt prima zolang de Endpoint daarmee overeenkomt. Afwijkingen hier veroorzaken stilte in plaats van fouten, daarom is het de moeite waard ze op papier te controleren voordat je op de kabel debugt.

De velden die bij wg horen en die dat niet doen

De kernveldenset is klein: PrivateKey en ListenPort onder Interface, PublicKey, AllowedIPs en Endpoint onder Peer. Address en DNS horen bij wg-quick en niet bij wg zelf, en dat verschil bijt op het moment dat dezelfde configuratie naar een ander hulpmiddel verhuist.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs draagt twee taken tegelijk. Het kiest welke bestemmingen de tunnel in gaan, en het autoriseert de peer om die bronadressen bij aankomst te gebruiken. Daarom moet de spiegelvermelding aan de andere kant jouw tunneladres exact benoemen; een /32 voor de verkeerde peer leest als een routingprobleem en gedraagt zich als een autorisatieprobleem. De WireGuard-snelstart toont dezelfde tweepuntsvorm met de kanonieke formulering als je veldnamen wilt vergelijken.

De handshake lezen in plaats van het pictogram

Breng de interface omhoog via wat hem bezit, lees dan toestand in plaats van een statuslampje. wg show drukt de laatste handshake per peer af samen met bytetellers, en een handshake binnen de laatste paar minuten betekent dat sleutels, endpoint en UDP-pad allemaal werken. Een teller die maar één kant op stijgt is zijn eigen antwoord, en het is niet dezelfde fout als een handshake die nooit plaatsvindt.

De twee fouten vragen om verschillend onderzoek. Helemaal geen handshake wijst op een sleutelafwijking, een verkeerde Endpoint, geblokkeerde UDP of een firewall die de handshake zelf laat vallen. Een handshake die slaagt terwijl data nergens heen gaat, wijst op AllowedIPs, een dienst die niet op het tunneladres luistert, of een hostfirewall die de poort voor het LAN wel en voor de tunnelinterface niet accepteert. Dat zijn verschillende helften van het systeem, en de basis scheidt ze voordat je regels gaat wijzigen.

Eén toegestane dienst bewijzen, dan het omgekeerde

Stuur een verzoek naar het tunneladres van de andere peer op een dienst die hoort te antwoorden, en kies iets beters dan ping. Een ontbrekend ICMP-antwoord kan hostfiltering zijn en geen tunnelfout, dus een stille ping bewijst geen van beide richtingen. Een TCP-verbinding naar een poort waarvan je weet dat hij open is, of een verzoek dat data teruggeeft, geeft je een antwoord dat je kunt interpreteren.

Voer de tegenrichting uit als een aparte test met een eigen resultaat, omdat de twee richtingen aparte firewall- en AllowedIPs-vermeldingen hebben en onafhankelijk kunnen falen. Als de handshake werkt en het verzoek niet, zit het probleem in het datapad en niet in de tunnel: AllowedIPs, de luisterende dienst of een hostfirewall. Repareer dat voordat je forwarding, NAT of DNS toevoegt, anders breng je de middag door met het debuggen van een functie die nooit de schuld was.

De basis als referentie houden

Sla de werkende topologie en de profielbron op op een plek waaruit je kunt herstellen, en houd ze buiten elke map die naar een openbare dienst synchroniseert. Voeg dan één functie tegelijk toe en herhaal na elk het oorspronkelijke verzoek: forwarding, NAT, een LAN-route en pas daarna DNS. Elke toevoeging die de test breekt is nu herkenbaar, omdat er niets anders bewoog.

Een basis die alleen een pictogram groen maakt, heeft je niets verteld over welke toevoeging de volgende fout veroorzaakte. Houd het ene toegestane pad werkend als referentie, en elke latere wijziging wordt daaraan gemeten.