Hoe't do in WireGuard-test mei twa peers bouwe kinst dy't ien paad bewissiget
Ien tunnel, ien adrespear, ien tastien boarne. In minimale WireGuard-basis makket elke lettere feroaring yn trochstjoering, NAT of DNS sichtber.
In WireGuard-test dy't in standertrûte, in LAN-prefiks, DNS en in firewall-útsûndering draacht, kin dy net fertelle hokker dêrfan stikken gien is. Werombring it ta twa peers, ien adrespear en ien tastiene tsjinst, en de flater hat nearne om him te ferskûljen. De saaiige basis is de diagnostyk. Bou dy earst; it nimt fyftjin minuten en sparret de middei dy't do oars oan rieden besteegje soest.
Wat de basis bewissiget is smeller as't de measte minsken ferwachtsje. It bewissiget dat twa identiteiten it iens binne, dat UDP it harkjende poarte berikt en dat ien tastiene bestimming in fersyk draacht. Trochstjoering, NAT, LAN-rûtes en DNS binne aparte funksjes dy't letter tafoege wurde, ien foar ien.
Kaaien, adressen en it iene einpunt
Generearje in kaaipear op elk systeem en ferpleats allinne de iepenbiere helten tusken har. wg genkey | tee privatekey | wg pubkey > publickey is de dokumintearre ienrigel, en it lit de priveekaai efter yn in bestân dat do dêrnei beskermje kinst. Kies tunneladressen út in berik dat yn gjin inkelde oare konfiguraasje fan dy foarkomt, lykas 10.99.0.1/24 en 10.99.0.2/24. Skriuw op hokker adres by hokker masine heart, want elke lettere kontrôle hinget fan dy koppeling ôf.
Priveekaaien reizgje nea. As in test ien nedich hat dy't nei de oare kant kopiaat wurdt, is de test al ferkeard gien. Wêr't de twa systemen efter NAT sitte, hat teminsten ien in berikbere UDP-poarte nedich wylst de oare in Endpoint draacht dy't dêrnei wiist, en it iepenbiere adres en de poarte hearre yn dyn notysjes, net yn dyn oannames oer 51820.
In poartetrochstjoering dy't in oare eksterne poarte mappet wurket goed salang't de Endpoint dêrmei oerienkomt. Misoerienkomsten hjir produsearje stilte ynstee fan flaters, dêrom is it de muoite wurdich se op papier te kontrolearjen foardat do op 'e tried debugst.
De fjilden dy't by wg hearre en dy't net
De kearnset fjilden is lyts: PrivateKey en ListenPort ûnder Interface, PublicKey, AllowedIPs en Endpoint ûnder Peer. Address en DNS hearre by wg-quick en net by wg sels, en dat ferskil byt fan it momint dat deselde konfiguraasje nei in oar ark ferhúzet.
[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 draacht twa taken tagelyk. It kiest hokker bestimmingen de tunnel yn geane, en it autorisearret de peer om dy boarneadressen by oankomst te brûken. Dêrom moat de spegelregel oan 'e oare kant dyn tunneladres krekt beneame; in /32 foar de ferkearde peer lêst as in rûtprobleem en hâldt him as in autorisaasjeprobleem. De WireGuard-flugge start lit deseldefoarm mei twa peers sjen mei de kanonike wurden as do fjildnammen fergelykje wolst.
De hânskud lêze ynstee fan it byldsje
Bring de ynterfaasje omheech fia wat him besit, lês dan steat ynstee fan in statuslampe. wg show prints it lêste hânskud per peer tegearre mei byttetellers, en in hânskud binnen de lêste pear minuten betsjut dat kaaien, einpunt en UDP-paad allegear wurkje. In teller dy't allinnich yn ien rjochting omheech giet is syn eigen antwurd, en it is net deselde flater as in hânskud dat nea bart.
De twa flaters betsjutte ferskate ûndersiken. Gjin hânskud hielendal wiist op kaaiferskil, in ferkearde Endpoint, blokkearre UDP of in firewall dy't it hânskud sels falle lit. In hânskud dat slagget wylst gegevens nearne hinne geane wiist op AllowedIPs, in tsjinst dy't net op it tunneladres harket, of in hostfirewall dy't de poarte foar it LAN akseptearret mar net foar de tunnelinterfaasje. Dat binne ferskate helten fan it systeem, en de basis skiedt se foardat do regels begjinst te feroarjen.
Ien tastiene tsjinst bewissigje, dan it omkearde
Doch in fersyk nei it tunneladres fan 'e oare peer op in tsjinst dy't antwurdzje moat, en kies wat better as ping. In ûntbrekkend ICMP-antwurd kin hostfiltering wêze en net in tunneldefekt, dus in stil ping bewissiget gjin inkelde rjochting. In TCP-ferbining nei in poarte dy't do witst iepen is, of in fersyk dat gegevens weromjout, jout dy in antwurd dat do ynterpretearje kinst.
Rin de omkearde rjochting as in aparte test mei eigen resultaat, want de twa rjochtingen hawwe aparte firewall- en AllowedIPs-regels en kinne ûnôfhinklik mislearje. As it hânskud wurket en it fersyk net, sit it probleem yn it gegevenspaad en net yn 'e tunnel: AllowedIPs, de harkjende tsjinst, of in hostfirewall. Reparearje dat foardat do trochstjoering, NAT of DNS tafoegest, oars besteegje do de middei oan it debuggen fan in funksje dy't nea de skuld wie.
De basis as referinsje hâlde
Bewarje de wurkjende topology en de profylboarne op in plak dêr't do fan werstelle kinst, en hâld se bûten elke map dy't mei in iepenbiere tsjinst syngronisearret. Foegje dan ien funksje tagelyk ta, en werhelje it oorspronklike fersyk nei elk: trochstjoering, NAT, in LAN-rûte en pas dêrnei DNS. Elke tafoeging dy't de test brekt is no werkenber, want neat oars beweegde.
In basis dy't allinnich in byldsje grien makket hat dy neat ferteld oer hokker tafoeging de folgjende flater feroarsake. Hâld it iene tastiene paad oan it wurkjen as referinsje, en elke lettere feroaring wurdt dêroan metten.