Kako zgraditi test WireGuarda z dvema peerjema, ki dokaže eno pot

Test WireGuarda, ki nosi privzeto pot, predpono LAN, DNS in izjemo v požarnem zidu, ne more povedati, kateri od njih se je zlomil. Skrčite ga na dva peerja, en par naslovov in eno dovoljeno storitev, in napaki ne ostane prostora za skrivanje. Dolgočasna osnova je diagnoza. Zgradite jo najprej; traja petnajst minut in prihrani popoldne, ki bi ga sicer preživeli z ugibanjem.

Kar osnova dokaže, je ožje, kot pričakuje večina. Dokaže, da se dve identiteti strinjata, da UDP doseže vhodna vrata in da en dovoljen cilj nosi zahtevo. Posredovanje, NAT, poti LAN in DNS so ločene funkcije, ki jih dodajamo pozneje, eno za drugo.

Ključi, naslovi in edini endpoint

Ustvarite par ključev na vsakem sistemu in med njima prenesite le javni polovici. wg genkey | tee privatekey | wg pubkey > publickey je dokumentiran enovrstični ukaz in pusti zasebni ključ v datoteki, ki jo lahko nato zaščitite. Izberite naslove tunela iz obsega, ki se ne pojavi v nobeni drugi vaši konfiguraciji, na primer 10.99.0.1/24 in 10.99.0.2/24. Zapišite, kateri naslov pripada kateremu stroju, ker je vsako poznejše preverjanje odvisno od tega preslikavanja.

Zasebni ključi nikoli ne potujejo. Če test potrebuje enega kopiranega na drugo stran, je test že šel narobe. Ko sta oba sistema za NAT, vsaj eden potrebuje dosegljiva vrata UDP, medtem ko drugi nosi Endpoint, ki kaže nanje, javni naslov in vrata pa sodita v vaše zapiske, ne v vaše predpostavke o 51820.

Preusmerjanje vrat, ki preslika druga zunanja vrata, deluje dobro, dokler se Endpoint ujema z njimi. Neujemanja tu ustvarijo tišino namesto napak, zato jih je vredno preveriti na papirju, preden razhroščujete na kablu.

Polja, ki pripadajo wg, in tista, ki ne

Osnovni nabor polj je majhen: PrivateKey in ListenPort pod Interface, PublicKey, AllowedIPs in Endpoint pod Peer. Address in DNS pripadata wg-quick, ne wg samemu, in ta razlika ugrizne v trenutku, ko se ista konfiguracija preseli v drugo orodje.

[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 opravlja dve nalogi hkrati. Izbere, katere destinacije gredo v tunel, in pooblasti peerja, da te izvorne naslove uporabi ob prihodu. Zato mora zrcalni vnos na drugi strani natančno navesti naslov vašega tunela; /32 za napačnega peerja se bere kot težava usmerjanja in se obnaša kot težava pooblastila. Hitri začetek WireGuarda prikaže enako obliko z dvema peerjema s kanoničnim besedilom, če želite primerjati imena polj.

Branje rokovanja namesto ikone

Dvignite vmesnik skozi to, kar ga ima, nato berite stanje, ne lučke. wg show izpiše zadnje rokovanje na peerja skupaj s števci bajtov, in rokovanje v zadnjih nekaj minutah pomeni, da ključi, endpoint in pot UDP vsi delujejo. Števec, ki raste le v eno smer, je sam svoj odgovor in ni ista okvara kot rokovanje, ki se nikoli ne zgodi.

Okvari zahtevata različne preiskave. Popolna odsotnost rokovanja kaže na neujemanje ključev, napačen Endpoint, blokiran UDP ali požarni zid, ki zavrže samo rokovanje. Rokovanje, ki uspe, medtem ko podatki ne gredo nikamor, kaže na AllowedIPs, storitev, ki ne posluša na naslovu tunela, ali požarni zid gostitelja, ki sprejme vrata za LAN, ne pa za vmesnik tunela. To sta različni polovici sistema, in osnova ju loči, preden začnete spreminjati pravila.

Dokazati eno dovoljeno storitev, nato obratno

Pošljite zahtevo na naslov tunela drugega peerja na storitev, ki naj bi odgovorila, in izberite kaj boljšega od ping. Manjkajoč odgovor ICMP je lahko filtriranje gostitelja in ne okvara tunela, zato tihi ping ne dokaže nobene smeri. TCP povezava na vrata, za katera veste, da so odprta, ali zahteva, ki vrne podatke, vam da odgovor, ki ga lahko razložite.

Zaženite obratno smer kot ločen test z lastnim rezultatom, ker imata obe smeri ločene vnose požarnega zidu in AllowedIPs ter lahko neuspešno delujeta neodvisno. Če rokovanje deluje in zahteva ne, je težava na podatkovni poti, ne v tunelu: AllowedIPs, storitev, ki posluša, ali požarni zid gostitelja. Popravite to, preden dodate posredovanje, NAT ali DNS, sicer boste popoldne preživeli z razhroščevanjem funkcije, ki ni bila nikoli kriva.

Ohranjanje osnove kot reference

Shranite delujočo topologijo in vir profila na mesto, od koder lahko obnovite, in ju hranite zunaj vsake mape, ki se sinhronizira z javno storitvijo. Nato dodajajte eno funkcijo naenkrat in po vsaki ponovite prvotno zahtevo: posredovanje, NAT, pot LAN in šele nato DNS. Vsak dodatek, ki pokvari test, je zdaj prepoznaven, ker se ni premaknilo nič drugega.

Osnova, ki samo obarva ikono zeleno, vam ni povedala ničesar o tem, kateri dodatek je povzročil naslednjo okvaro. Ohranite edino dovoljeno pot delujočo kot referenco, in vsaka poznejša sprememba se meri proti njej.