Kaip sukurti WireGuard testą su dviem partneriais, įrodantį vieną kelią
Vienas tunelis, viena adresų pora, vienas leidžiamas išteklius. Minimalus WireGuard pagrindas padaro matomą kiekvieną vėlesnį peradresavimo, NAT ar DNS pakeitimą.
WireGuard testas, kuris neša numatytąjį maršrutą, LAN prefiksą, DNS ir užkardos išimtį, negali pasakyti, kuri iš jų sugedo. Sumažinkite jį iki dviejų partnerių, vienos adresų poros ir vienos leidžiamos paslaugos, ir gedimas neturės kur pasislėpti. Nuobodus pagrindas ir yra diagnostika. Sukurkite jį pirmiausia; tai užtrunka penkiolika minučių ir sutaupo popietę, kurią kitaip praleistumėte spėliodami.
Tai, ką pagrindas įrodo, yra siauriau, nei dauguma tikisi. Jis įrodo, kad dvi tapatybės sutaria, kad UDP pasiekia klausymosi prievadą ir kad viena leidžiama paskirties vieta neša užklausą. Peradresavimas, NAT, LAN maršrutai ir DNS yra atskiros funkcijos, pridedamos vėliau, po vieną.
Raktai, adresai ir vienintelis endpoint
Sugeneruokite raktų porą kiekvienoje sistemoje ir perkelkite tarp jų tik viešąsias puses. wg genkey | tee privatekey | wg pubkey > publickey yra dokumentuota vienos eilutės komanda, ir ji palieka privatų raktą faile, kurį vėliau galite apsaugoti. Pasirinkite tunelio adresus iš diapazono, kuris nepasitaiko jokioje kitoje jūsų konfigūracijoje, pavyzdžiui, 10.99.0.1/24 ir 10.99.0.2/24. Užsirašykite, kuris adresas priklauso kuriai mašinai, nes kiekvienas vėlesnis patikrinimas priklauso nuo šio susiejimo.
Privatūs raktai niekada nekeliauja. Jei testui reikia vieno, nukopijuoto į kitą pusę, testas jau nuejo netinkamu keliu. Kai dvi sistemos yra už NAT, bent vienai reikia pasiekiamo UDP prievado, o kita neša Endpoint, nukreiptą į jį, ir viešasis adresas bei prievadas priklauso jūsų užrašams, o ne prielaidoms apie 51820.
Prievado peradresavimas, kuris susieja kitą išorinį prievadą, veikia gerai, kol Endpoint jį atitinka. Nesutapimai čia sukuria tylą, o ne klaidas, todėl verta juos patikrinti popieriuje prieš derinant laide.
Laukai, kurie priklauso wg, ir tie, kurie ne
Pagrindinis laukų rinkinys mažas: PrivateKey ir ListenPort po Interface, PublicKey, AllowedIPs ir Endpoint po Peer. Address ir DNS priklauso wg-quick, o ne pačiam wg, ir šis skirtumas įkanda tą akimirką, kai ta pati konfigūracija persikelia į kitą įrankį.
[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 vienu metu atlieka du darbus. Jis parenka, kurios paskirties vietos patenka į tunelį, ir įgalioja partnerį naudoti tuos šaltinio adresus atvykus. Todėl veidrodinis įrašas kitoje pusėje turi tiksliai įvardyti jūsų tunelio adresą; /32 netinkamam partneriui skaitomas kaip maršrutizavimo problema ir elgiasi kaip įgaliojimo problema. Greitas WireGuard startas rodo tą pačią dviejų partnerių formą su kanonine formuluote, jei norite palyginti laukų pavadinimus.
Rankos paspaudimo skaitymas vietoj piktogramos
Pakelkite sąsają per tai, kas ją valdo, tada skaitykite būseną, o ne būsenos lemputę. wg show išspausdina paskutinį rankos paspaudimą kiekvienam partneriui kartu su baitų skaitikliais, o rankos paspaudimas per paskutines kelias minutes reiškia, kad raktai, endpoint ir UDP kelias visi veikia. Skaitiklis, kuris didėja tik viena kryptimi, yra pats sau atsakymas, ir tai ne tas pats gedimas kaip rankos paspaudimas, kuris niekada neįvyksta.
Du gedimai reiškia skirtingus tyrimus. Visiškas rankos paspaudimo nebuvimas nurodo raktų nesutapimą, neteisingą Endpoint, užblokuotą UDP ar užkardą, kuri numeta patį rankos paspaudimą. Rankos paspaudimas, kuris pavyksta, bet duomenys niekur neina, nurodo AllowedIPs, paslaugą, kuri nesiklauso tunelio adrese, arba pagrindinio kompiuterio užkardą, kuri priima prievadą LAN tinklui, bet ne tunelio sąsajai. Tai skirtingos sistemos pusės, ir pagrindas jas atskiria prieš pradedant keisti taisykles.
Įrodyti vieną leidžiamą paslaugą, tada atvirkščiai
Siųskite užklausą kito partnerio tunelio adresu į paslaugą, kuri turėtų atsakyti, ir pasirinkite ką nors geresnio už ping. Trūkstamas ICMP atsakymas gali būti pagrindinio kompiuterio filtravimas, o ne tunelio gedimas, todėl tylus ping neįrodo nė vienos krypties. TCP ryšys su prievadu, kurį žinote esant atvirą, arba užklausa, grąžinanti duomenis, duoda atsakymą, kurį galite interpretuoti.
Vykdykite priešingą kryptį kaip atskirą testą su savo rezultatu, nes dvi kryptys turi atskirus užkardos ir AllowedIPs įrašus ir gali sugesti nepriklausomai. Jei rankos paspaudimas veikia, o užklausa ne, problema yra duomenų kelyje, o ne tunelyje: AllowedIPs, klausianti paslauga arba pagrindinio kompiuterio užkarda. Ištaisykite tai prieš pridėdami peradresavimą, NAT ar DNS, kitaip praleisite popietę derindami funkciją, kuri niekada nebuvo kalta.
Pagrindo išlaikymas kaip atskaitos
Išsaugokite veikiančią topologiją ir profilio šaltinį vietoje, iš kurios galite atkurti, ir laikykite juos toliau nuo bet kurio katalogo, kuris sinchronizuojamas su vieša paslauga. Tada pridėkite po vieną funkciją, po kiekvienos pakartodami pradinę užklausą: peradresavimas, NAT, LAN maršrutas ir tik tada DNS. Kiekvienas papildymas, kuris sugriauna testą, dabar yra atpažįstamas, nes niekas kitas nepasikeitė.
Pagrindas, kuris tik paverčia piktogramą žalia, nieko nepasakė apie tai, kuris papildymas sukėlė kitą gedimą. Laikykite vienintelį leidžiamą kelią veikiantį kaip atskaitą, ir kiekvienas vėlesnis pakeitimas matuojamas pagal jį.