Si të ndërtosh një test WireGuard me dy peer që provon një rrugë të vetme

Një test WireGuard që mban një rrugë të paracaktuar, një prefiks LAN, DNS dhe një përjashtim firewall nuk mund të thotë se cila prej tyre u prish. Reduktoje në dy peer, një çift adresash dhe një shërbim të lejuar, dhe dështimi nuk ka ku të fshihet. Baza e mërzitshme është diagnoza. Ndërtoje fillimisht; merr pesëmbëdhjetë minuta dhe kursen pasditen që përndryshe do të kalosh duke hamendësuar.

Ajo që provon baza është më e ngushtë sesa pret shumica. Provon se dy identitete pajtohen, se UDP arrin portën e dëgjimit dhe se një destinacion i lejuar mban një kërkesë. Forwarding, NAT, rrugët LAN dhe DNS janë funksione të veçanta që shtohen më vonë, një nga një.

Çelësat, adresat dhe endpoint-i i vetëm

Gjenero një çift çelësash në çdo sistem dhe zhvendos mes tyre vetëm gjysmat publike. wg genkey | tee privatekey | wg pubkey > publickey është komanda e dokumentuar një-rresht, dhe e lë çelësin privat në një skedar që më pas mund ta mbrosh. Zgjidh adresa tuneli nga një interval që nuk shfaqet në asnjë konfigurim tjetër tëndin, si për shembull 10.99.0.1/24 dhe 10.99.0.2/24. Shkruaj cila adresë i përket cilit makinë, sepse çdo kontroll i mëvonshëm varet nga ky mapim.

Çelësat privatë nuk udhëtojnë kurrë. Nëse një test ka nevojë për një të kopjuar në anën tjetër, testi tashmë ka shkuar keq. Kur dy sistemet janë pas NAT, të paktën një ka nevojë për një portë UDP të arritshme ndërsa tjetri mban një Endpoint që tregon drejt saj, dhe adresa dhe porta publike i përkasin shënimeve të tua, jo supozimeve të tua për 51820.

Një ridrejtim porte që mapon një portë tjetër të jashtme funksionon mirë për sa kohë Endpoint përputhet me të. Mospërputhjet këtu prodhojnë heshtje në vend të gabimeve, prandaj ia vlen t'i kontrollosh në letër para se të korrigjosh gabimet në kabllo.

Fushat që i përkasin wg dhe ato që nuk i përkasin

Grupi bazë i fushave është i vogël: PrivateKey dhe ListenPort nën Interface, PublicKey, AllowedIPs dhe Endpoint nën Peer. Address dhe DNS i përkasin wg-quick dhe jo vetë wg, dhe ky dallim kafshon në momentin kur i njëjti konfigurim kalon në një mjet tjetër.

[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 mban dy detyra njëkohësisht. Zgjedh se cilat destinacione hyjnë në tunel, dhe autorizon peer-in të përdorë ato adresa burimi në mbërritje. Prandaj zëri pasqyrë në anën tjetër duhet të emërojë saktësisht adresën e tunelit tënd; një /32 për peer-in e gabuar lexohet si problem rrugëtimi dhe sillet si problem autorizimi. Nisje e shpejtë e WireGuard tregon të njëjtën formë me dy peer me formulimin kanonik nëse do të krahasosh emrat e fushave.

Leximi i handshake në vend të ikonës

Ngri ndërfaqen përmes asaj që e zotëron, pastaj lexo gjendjen në vend të një drite statusi. wg show printon handshake-un e fundit për çdo peer bashkë me numëruesit e bajtëve, dhe një handshake brenda minutave të fundit do të thotë se çelësat, endpoint-i dhe rruga UDP funksionojnë të gjitha. Një numërues që rritet vetëm në një drejtim është përgjigjja e vetë, dhe nuk është i njëjti dështim si një handshake që nuk ndodh kurrë.

Dy dështimet nënkuptojnë hetime të ndryshme. Mungesa e plotë e handshake tregon mospërputhje çelësash, Endpoint të gabuar, UDP të bllokuar ose një firewall që hedh vetë handshake-un. Një handshake që ka sukses ndërsa të dhënat nuk shkojnë askund tregon AllowedIPs, një shërbim që nuk dëgjon në adresën e tunelit, ose një firewall hosti që pranon portën për LAN por jo për ndërfaqen e tunelit. Këto janë gjysma të ndryshme të sistemit, dhe baza i ndan ato para se të fillosh të ndryshosh rregullat.

Të provosh një shërbim të lejuar, pastaj të kundërtën

Dërgo një kërkesë në adresën e tunelit të peer-it tjetër në një shërbim që pritet të përgjigjet, dhe zgjidh diçka më të mirë se ping. Një përgjigje ICMP që mungon mund të jetë filtrimi i hostit dhe jo një defekt tuneli, kështu që një ping i heshtur nuk provon asnjë drejtim. Një lidhje TCP me një portë që e di të hapur, ose një kërkesë që kthen të dhëna, të jep një përgjigje që mund ta interpretosh.

Ekzekuto drejtimin e kundërt si një test të veçantë me rezultatin e vet, sepse dy drejtimet kanë zëra të veçantë firewall dhe AllowedIPs dhe mund të dështojnë në mënyrë të pavarur. Nëse handshake funksionon dhe kërkesa jo, problemi është në rrugën e të dhënave dhe jo në tunel: AllowedIPs, shërbimi që dëgjon ose një firewall hosti. Rregulloje këtë para se të shtosh forwarding, NAT ose DNS, përndryshe do të kalosh pasditen duke korrigjuar gabimet e një funksioni që nuk ishte kurrë fajtor.

Mbajtja e bazës si referencë

Ruaj topologjinë që funksionon dhe burimin e profilit në një vend nga i cili mund të rikthehesh, dhe mbaji jashtë çdo direktorie që sinkronizohet me një shërbim publik. Pastaj shto një funksion në një kohë, duke përsëritur kërkesën origjinale pas secilit: forwarding, NAT, një rrugë LAN dhe vetëm pastaj DNS. Çdo shtesë që thyen testin tani është e identifikueshme, sepse asgjë tjetër nuk lëvizi.

Një bazë që vetëm bën një ikonë të gjelbër nuk të ka thënë asgjë se cila shtesë shkaktoi dështimin tjetër. Mbaj rrugën e vetme të lejuar duke funksionuar si referencë, dhe çdo ndryshim i mëvonshëm matet kundrejt saj.