Nola eraiki bi pareko WireGuard proba bide bakarra frogatzen duena

Bide lehenetsia, LAN aurrizkia, DNS eta suebaki salbuespena daramatzan WireGuarden proba batek ezin dizu esan horietako zein hondatu zen. Murriztu bi pare, helbide pare bat eta baimendutako zerbitzu bakarrera, eta hutsegiteak ez du ezkutatzeko tokirik izango. Oinarri aspergarria da diagnostikoa. Eraiki hori lehenengo; hamabost minutu behar ditu eta bestela asmatzen emango zenukeen arratsaldea aurrezten du.

Oinarriak frogatzen duena jendeak espero duena baino estuagoa da. Bi nortasun ados daudela, UDP entzuten ari den portura iristen dela eta baimendutako helmuga batek eskaera bat daramala frogatzen du. Birbidalketa, NAT, LAN ibilbideak eta DNS geroago gehitzen diren funtzio bereiziak dira, banan-banan.

Gakoak, helbideak eta endpoint bakarra

Sortu gako-pare bat sistema bakoitzean eta eraman haien artean erdi publikoak soilik. wg genkey | tee privatekey | wg pubkey > publickey dokumentatutako lerro bakarreko komandoa da, eta gako pribatua gero babes dezakezun fitxategi batean uzten du. Aukeratu tunel helbideak daukazun beste konfigurazio batean agertzen ez den barruti batetik, adibidez 10.99.0.1/24 eta 10.99.0.2/24. Idatzi zein helbide dagokion zein makinari, geroagoko egiaztapen bakoitza mapaketa horren mende baitago.

Gako pribatuek ez dute inoiz bidaiatzen. Proba batek beste aldera kopiatutako bat behar badu, proba gaizki joan da jada. Bi sistemak NAT atzean daudenean, gutxienez batek UDP portu irisgarri bat behar du, besteak hara seinalatzen duen Endpoint bat daraman bitartean, eta helbide publikoa eta portua zure oharretan daude, ez 51820ri buruzko zure suposizioetan.

Kanpoko portu ezberdin bat mapatzen duen portu birbidalketak ondo funtzionatzen du Endpoint harekin bat datorren bitartean. Hemen desadostasunek isiltasuna sortzen dute, ez erroreak, horregatik merezi du paperean egiaztatzea kablean araztu aurretik.

wg-ri dagozkion eremuak eta ez dagozkionak

Oinarrizko eremu-multzoa txikia da: PrivateKey eta ListenPort Interface azpian, PublicKey, AllowedIPs eta Endpoint Peer azpian. Address eta DNS wg-quick-i dagozkio, ez wg berari, eta bereizketa horrek hozka egiten du konfigurazio bera beste tresna batera igarotzen den unean.

[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-ek bi zeregin daramatza aldi berean. Helmuga zeintzuk tunelera sartzen diren hautatzen du, eta pareari iturri helbide horiek iristean erabiltzeko baimena ematen dio. Horregatik, beste aldeko ispilu-sarrerak zure tunelaren helbidea zehazki izendatu behar du; pare oker baterako /32 batek bideratze arazo gisa irakurtzen da eta baimen arazo gisa jokatzen du. WireGuard abiarazte azkarra erakusten du bi pareko forma bera hitzez hitzeko formulazioarekin, eremu izenak alderatu nahi badituzu.

Handshakea irakurtzea ikonoaren ordez

Jaso interfazea daramanak berak, gero irakurri egoera, ez argi bat. wg show pare bakoitzeko azken handshakea inprimatzen du byte-kontagailuekin, eta azken minutuetako handshake batek esan nahi du gakoak, endpoint eta UDP bidea denak funtzionatzen dutela. Norabide bakarrean soilik igotzen den kontagailu bat bere buruaren erantzuna da, eta ez da sekula gertatzen ez den handshake baten hutsegite bera.

Bi hutsegiteek ikerketa ezberdinak dakartzate. Handshakerik ez egoteak gakoen desadostasuna, Endpoint okerra, blokeatutako UDP edo handshakea bera botatzen duen suebaki bat adierazten du. Handshakeak arrakasta izaten duenean baina datuek inora ere ez doazenean, AllowedIPs, tunel helbidean entzuten ez duen zerbitzua edo LANerako portua onartzen duen baina tunel interfazerako ez duen host suebaki bat adierazten du. Sistemaren erdi desberdinak dira, eta oinarriak bereizten ditu erregelak aldatzen hasi aurretik.

Baimendutako zerbitzu bat frogatzea, gero alderantzizkoa

Egin eskaera bat beste parearen tunel helbidera erantzun behar duen zerbitzu batean, eta aukeratu ping baino zerbait hobea. ICMP erantzunik ez egotea hostaren iragazketa izan daiteke, ez tunelaren hutsegitea, beraz ping isilak ez du norabide bat ere frogatzen. Jakina duzun portu ireki baterako TCP konexioak, edo datuak itzultzen dituen eskaera batek, interpreta dezakezun erantzuna ematen dizu.

Exekutatu kontrako norabidea bere emaitza duen proba bereizi gisa, bi norabideek suebaki eta AllowedIPs sarrera bereiziak dituztelako eta independenteki huts egin dezaketelako. Handshakeak funtzionatzen badu eta eskaerak ez, arazoa datu bidean dago, ez tunelean: AllowedIPs, entzuten ari den zerbitzua edo host suebakia. Konpondu hori birbidalketa, NAT edo DNS gehitu aurretik, bestela inoiz errudun izan ez den funtzio bat arazten emango duzu arratsaldea.

Oinarria erreferentzia gisa mantentzea

Gorde funtzionatzen duen topologia eta profilearen iturburua berreskura dezakezun leku batean, eta eduki itzazu zerbitzu publiko batera sinkronizatzen den edozein karpetatik kanpo. Ondoren gehitu funtzio bat aldi berean, jatorrizko eskaera bakoitzaren ondoren errepikatuz: birbidalketa, NAT, LAN ibilbide bat eta soilik gero DNS. Proba hausten duen gehitze bakoitza orain identifikagarria da, beste ezerk ez baitu mugitu.

Ikonoa berde egiten duen oinarri batek ez dizu ezer esan hurrengo hutsegitea zein gehitzek eragin zuenari buruz. Eutsi baimendutako bide bakarra erreferentzia gisa, eta geroagoko aldaketa bakoitza haren aurka neurtzen da.