Hoe om 'n WireGuard-toets met twee eweknieë te bou wat een pad bewys

'n WireGuard-toets wat 'n verstekroete, 'n LAN-prefiks, DNS en 'n firewall-uitsondering dra, kan nie vir jou sê watter een van hulle gebreek het nie. Stroop dit af na twee eweknieë, een adrespaar en een toegelate diens, en die fout het nêrens om weg te kruip nie. Die vervelige basislyn is die diagnostiek. Bou dit eerste; dit neem vyftien minute en spaar die middag wat jy andersins sou vermors aan raaiwerk.

Wat die basislyn bewys, is smaller as wat meeste mense verwag. Dit bewys dat twee identiteite saamstem, dat UDP die luisterpoort bereik, en dat een toegelate bestemming 'n versoek dra. Aanstuur, NAT, LAN-roetes en DNS is aparte kenmerke wat later bygevoeg word, een op 'n slag.

Sleutels, adresse en die enkele eindpunt

Genereer 'n sleutelpaar op elke stelsel en skuif net die publieke helftes tussen hulle. wg genkey | tee privatekey | wg pubkey > publickey is die gedokumenteerde eenreël, en dit laat die privaat sleutel in 'n lêer wat jy dan kan beskerm. Kies tonneladresse uit 'n reeks wat in geen ander konfigurasie van jou voorkom nie, soos 10.99.0.1/24 en 10.99.0.2/24. Skryf neer watter adres aan watter masjien behoort, want elke latere kontrole hang van daardie kartering af.

Privaat sleutels reis nooit nie. As 'n toets een nodig het wat na die ander kant gekopieer word, het die toets al klaar verkeerd gegaan. Waar die twee stelsels agter NAT sit, het ten minste een 'n bereikbare UDP-poort nodig terwyl die ander 'n Endpoint dra wat daarheen wys, en die publieke adres en poort hoort in jou notas eerder as in jou aannames oor 51820.

'n Poortaanstuur wat 'n ander eksterne poort karteer, werk fyn solank die Endpoint daarby pas. Wanpassings hier lewer stilte eerder as foute, en daarom is dit die moeite werd om dit op papier na te gaan voordat jy op die draad ontfout.

Die velde wat aan wg behoort en dié wat nie

Die kernveldtak is klein: PrivateKey en ListenPort onder Interface, PublicKey, AllowedIPs en Endpoint onder Peer. Address en DNS behoort aan wg-quick eerder as aan wg self, en daardie onderskeid byt die oomblik wanneer dieselfde konfigurasie na 'n ander instrument skuif.

[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 dra twee take tegelyk. Dit kies watter bestemmings in die tonnel gaan, en dit magtig die eweknie om daardie bronadresse by aankoms te gebruik. Daarom moet die spieëlinskrywing aan die ander kant jou tonneladres presies noem; 'n /32 vir die verkeerde eweknie lees soos 'n roeteprobleem en gedra hom soos 'n magtigingsprobleem. Die WireGuard-vinnigstart wys dieselfde tweeeweknie-vorm met die kanonieke bewoording as jy veldname wil vergelyk.

Lees die handdruk in plaas van die ikoon

Bring die koppelvlak op deur wat dit ook al besit, en lees dan toestand eerder as 'n statusliggie. wg show druk die jongste handdruk per eweknie saam met greptellers, en 'n handdruk binne die laaste paar minute beteken sleutels, eindpunt en UDP-pad werk almal. 'n Teller wat net in een rigting styg, is sy eie antwoord, en dit is nie dieselfde fout as 'n handdruk wat nooit gebeur nie.

Die twee foute impliseer verskillende ondersoeke. Geen handdruk hoegenaamd wys op 'n sleutelwanpassing, 'n verkeerde Endpoint, geblokkeerde UDP of 'n firewall wat die handdruk self laat val. 'n Handdruk wat slaag terwyl data nêrens heen gaan nie, wys op AllowedIPs, 'n diens wat nie op die tonneladres luister nie, of 'n gasheerfirewall wat die poort vir die LAN aanvaar maar nie vir die tonnelkoppelvlak nie. Dit is verskillende helftes van die stelsel, en die basislyn skei hulle voordat jy reëls begin verander.

Een toegelate diens bewys, dan die omgekeerde

Maak 'n versoek na die ander eweknie se tonneladres op 'n diens wat bedoel is om te antwoord, en kies iets beters as ping. 'n Ontbrekende ICMP-antwoord kan gasheerfiltrering wees eerder as 'n tonnelfout, so 'n stil ping bewys geen rigting nie. 'n TCP-verbinding na 'n poort waarvan jy weet dit is oop, of 'n versoek wat data teruggee, gee jou 'n antwoord wat jy kan interpreteer.

Voer die omgekeerde rigting as 'n aparte toets met sy eie resultaat uit, want die twee rigtings het aparte firewall- en AllowedIPs-inskrywings en kan onafhanklik faal. As die handdruk werk en die versoek nie, sit die probleem in die datapad eerder as in die tonnel: AllowedIPs, die luisterdiens, of 'n gasheerfirewall. Maak dit reg voordat jy aanstuur, NAT of DNS byvoeg, of jy sal die middag spandeer om 'n kenmerk te ontfout wat nooit die skuld was nie.

Die basislyn as die verwysing hou

Stoor die werkende topologie en die profielbron op 'n plek waaruit jy kan herstel, en hou dit uit enige gids wat na 'n publieke diens sinkroniseer. Voeg dan een kenmerk op 'n slag by, en herhaal die oorspronklike versoek na elkeen: aanstuur, NAT, 'n LAN-roete, en eers dan DNS. Elke toevoeging wat die toets breek, is nou identifiseerbaar, want niks anders het beweeg nie.

'n Basislyn wat net 'n ikoon groen maak, het jou niks vertel oor watter toevoeging die volgende fout veroorsaak het nie. Hou die een toegelate pad aan die werk as die verwysing, en elke latere verandering word daarteen gemeet.