Paano bumuo ng WireGuard test na may dalawang peer na nagpapatunay ng isang landas

Ang WireGuard test na may dalang default route, LAN prefix, DNS at firewall exception ay hindi masasabi kung alin sa mga ito ang nasira. Bawasan ito sa dalawang peer, isang pares ng address at isang pinapayagang serbisyo, at wala nang mapagtataguan ang failure. Ang boring na baseline ang diagnosis. Buuin ito muna; tumatagal ng labinlimang minuto at nakakatipid sa hapon na sana ay ginugol mo sa paghula.

Ang pinatutunayan ng baseline ay mas makitid kaysa inaasahan ng karamihan. Pinatutunayan nito na nagkakasundo ang dalawang pagkakakilanlan, na nakarating ang UDP sa port na nakikinig at na may isang pinapayagang destinasyon na may dalang request. Ang forwarding, NAT, mga LAN route at DNS ay hiwalay na feature na idinaragdag mamaya, isa-isa.

Mga key, address at ang nag-iisang endpoint

Gumawa ng key pair sa bawat sistema at ilipat lamang ang mga pampublikong kalahati sa pagitan nila. wg genkey | tee privatekey | wg pubkey > publickey ang dokumentadong one-liner, at iniiwan nito ang pribadong key sa file na maaari mong protektahan mamaya. Pumili ng tunnel address mula sa hanay na hindi lumalabas sa anumang iba pang configuration na pag-aari mo, tulad ng 10.99.0.1/24 at 10.99.0.2/24. Isulat kung aling address ang pag-aari ng aling makina, dahil ang bawat susunod na pagsusuri ay nakasalalay sa mapping na iyon.

Ang mga pribadong key ay hindi kailanman naglalakbay. Kung kailangan ng test na makopya ang isa sa kabilang panig, mali na ang takbo ng test. Kapag ang dalawang sistema ay nasa likod ng NAT, kahit isa ay nangangailangan ng maaabot na UDP port habang ang isa ay may dalang Endpoint na nakaturo doon, at ang pampublikong address at port ay nabibilang sa iyong mga tala, hindi sa iyong mga palagay tungkol sa 51820.

Ang port forward na nagmamapa ng ibang panlabas na port ay gumagana nang maayos hangga't tumutugma ang Endpoint dito. Ang mga hindi pagtutugma dito ay nagbubunga ng katahimikan kaysa mga error, kaya sulit na suriin ang mga ito sa papel bago mag-debug sa kable.

Ang mga field na kabilang sa wg at ang mga hindi

Maliit ang pangunahing set ng field: PrivateKey at ListenPort sa ilalim ng Interface, PublicKey, AllowedIPs at Endpoint sa ilalim ng Peer. Ang Address at DNS ay kabilang sa wg-quick hindi sa wg mismo, at ang pagkakaibang iyon ay kumakagat sa sandaling lumipat ang parehong configuration sa ibang tool.

[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

Ang AllowedIPs ay may dalang dalawang tungkulin nang sabay. Pinipili nito kung aling mga destinasyon ang pumapasok sa tunnel, at pinapahintulutan nito ang peer na gamitin ang mga source address na iyon sa pagdating. Kaya ang mirror entry sa kabilang panig ay dapat pangalanan nang eksakto ang address ng iyong tunnel; ang /32 para sa maling peer ay binabasa bilang problema sa routing at kumikilos tulad ng problema sa authorization. Ang Mabilis na simula ng WireGuard ay nagpapakita ng parehong hugis na may dalawang peer gamit ang kanonikal na pananalita kung nais mong ihambing ang mga pangalan ng field.

Pagbasa ng handshake kaysa sa icon

Itaas ang interface sa pamamagitan ng kung ano man ang may-ari nito, pagkatapos basahin ang kalagayan kaysa ilaw ng status. wg show ini-print ang pinakahuling handshake bawat peer kasama ang mga byte counter, at ang handshake sa loob ng nakaraang ilang minuto ay nangangahulugan na gumagana ang mga key, endpoint at UDP path. Ang counter na umaakyat lamang sa isang direksyon ay sarili nitong sagot, at hindi ito ang parehong failure gaya ng handshake na hindi kailanman nangyayari.

Ang dalawang failure ay nagpapahiwatig ng magkaibang pagsisiyasat. Ang kawalan ng handshake ay tumuturo sa hindi pagtutugma ng key, maling Endpoint, naka-block na UDP o firewall na nagtatapon ng handshake mismo. Ang handshake na nagtagumpay habang ang data ay hindi nakakarating kahit saan ay tumuturo sa AllowedIPs, serbisyong hindi nakikinig sa tunnel address, o firewall ng host na tumatanggap ng port para sa LAN ngunit hindi para sa tunnel interface. Magkaibang kalahati ng sistema ang mga ito, at pinaghihiwalay sila ng baseline bago ka magsimulang magbago ng mga patakaran.

Patunayan ang isang pinapayagang serbisyo, pagkatapos ang kabaligtaran

Magpadala ng request sa tunnel address ng kabilang peer sa isang serbisyong dapat sumagot, at pumili ng mas mabuti kaysa ping. Ang nawawalang ICMP reply ay maaaring pag-filter ng host at hindi failure ng tunnel, kaya ang tahimik na ping ay hindi nagpapatunay ng alinmang direksyon. Ang TCP connection sa port na alam mong bukas, o request na nagbabalik ng data, ay nagbibigay sa iyo ng sagot na maaari mong bigyang kahulugan.

Patakbuhin ang kabaligtarang direksyon bilang hiwalay na test na may sariling resulta, dahil ang dalawang direksyon ay may hiwalay na firewall at AllowedIPs entry at maaaring mabigo nang independiyente. Kung gumagana ang handshake at hindi ang request, nasa data path ang problema at hindi sa tunnel: AllowedIPs, ang serbisyong nakikinig o firewall ng host. Ayusin iyon bago magdagdag ng forwarding, NAT o DNS, kung hindi ay gugulin mo ang hapon sa pag-debug ng feature na hindi kailanman ang salarin.

Pagpapanatili ng baseline bilang sanggunian

I-save ang gumaganang topology at ang pinagmulan ng profile sa lugar na maaari mong ibalik, at ilayo ang mga ito sa anumang direktoryo na nagsi-sync sa pampublikong serbisyo. Pagkatapos magdagdag ng isang feature sa isang pagkakataon, inuulit ang orihinal na request pagkatapos ng bawat isa: forwarding, NAT, isang LAN route at pagkatapos lamang DNS. Ang bawat dagdag na sumisira sa test ay makikilala na ngayon, dahil wala nang iba pang gumalaw.

Ang baseline na pinapaputi lang ang isang icon ay wala pang sinasabi sa iyo tungkol sa kung aling dagdag ang naging sanhi ng susunod na failure. Panatilihing gumagana ang nag-iisang pinapayagang landas bilang sanggunian, at ang bawat susunod na pagbabago ay sinusukat laban dito.