Kuidas ehitada kahe peeriga WireGuard test, mis tõestab ühe tee

WireGuard test, mis kannab vaikimisi marsruuti, LAN-i prefiksit, DNS-i ja tulemüüri erandit, ei suuda sulle öelda, milline neist katki läks. Vii see kahe peeri, ühe aadripaari ja ühe lubatud teenuseni ning rikkel pole kuhugi peituda. Igav baas ongi diagnostika. Ehita see kõigepealt; see võtab viisteist minutit ja säästab pärastlõuna, mille muidu arvamise peale kulutaksid.

See, mida baas tõestab, on kitsam, kui enamik inimesi ootab. See tõestab, et kaks identiteeti on ühel meelel, et UDP jõuab kuulava pordini ja et üks lubatud sihtkoht kannab päringut. Edasisaatmine, NAT, LAN-i marsruudid ja DNS on eraldi funktsioonid, mida lisatakse hiljem, ükshaaval.

Võtmed, aadressid ja ainus endpoint

Loo igas süsteemis võtmepaar ja liiguta nende vahel ainult avalikke pooli. wg genkey | tee privatekey | wg pubkey > publickey on dokumenteeritud üherealune käsk ja jätab privaatvõtme faili, mida saad seejärel kaitsta. Vali tunneli aadressid vahemikust, mida ei esine üheski teises sinu konfiguratsioonis, näiteks 10.99.0.1/24 ja 10.99.0.2/24. Kirjuta üles, milline aadress kuulub millisele masinale, sest iga hilisem kontroll sõltub sellest vastendusest.

Privaatvõtmed ei reisi kunagi. Kui test vajab ühe kopeerimist teisele poole, on test juba viltu läinud. Kui kaks süsteemi on NAT-i taga, vajab vähemalt üks kättesaadavat UDP-porti, samal ajal kui teine kannab Endpointi, mis sellele osutab, ning avalik aadress ja port kuuluvad sinu märkmetesse, mitte sinu oletustesse 51820 kohta.

Pordiedastus, mis vastendab teistsuguse välise pordi, töötab hästi seni, kuni Endpoint sellega sobib. Kokkusobimatused tekitavad siin vaikuse, mitte vigu, seepärast tasub neid paberil kontrollida enne juhtmel silumist.

Väljad, mis kuuluvad wg-le, ja need, mis ei kuulu

Põhiväljade hulk on väike: PrivateKey ja ListenPort jaotises Interface, PublicKey, AllowedIPs ja Endpoint jaotises Peer. Address ja DNS kuuluvad wg-quickile, mitte wg-le endale, ja see vahe hammustab hetkel, mil sama konfiguratsioon liigub teise tööriista.

[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 kannab korraga kahte ülesannet. See valib, millised sihtkohad tunnelisse lähevad, ja volitab peeri neid lähteaadresse saabumisel kasutama. Seetõttu peab teispoolne peegelkirje sinu tunneli aadressi täpselt nimetama; vale peeri /32 loetakse marsruutimisprobleemiks ja käitub volitamisprobleemina. WireGuardi kiirstart näitab sama kahe peeri kuju kanoonilise sõnastusega, kui tahad väljanimesid võrrelda.

Kätlemise lugemine ikooni asemel

Tõsta liides üles selle kaudu, mis seda omab, seejärel loe olekut, mitte staatusetuld. wg show prindib iga peeri viimase kätlemise koos baidiloenduritega, ja kätlemine viimaste minutite jooksul tähendab, et võtmed, endpoint ja UDP-tee töötavad kõik. Loendur, mis kasvab ainult ühes suunas, on ise vastus, ja see ei ole sama rike kui kätlemine, mida ei toimugi.

Kaks riket eeldavad erinevaid uurimisi. Kätlemise täielik puudumine viitab võtmete lahknevusele, valele Endpointile, blokeeritud UDP-le või tulemüürile, mis viskab kätlemise enda maha. Kätlemine, mis õnnestub, aga andmed ei liigu kuhugi, viitab AllowedIPs-ile, teenusele, mis ei kuula tunneli aadressil, või hosti tulemüürile, mis võtab pordi vastu LAN-i jaoks, aga mitte tunneli liidese jaoks. Need on süsteemi erinevad pooled, ja baas eraldab need enne, kui hakkad reegleid muutma.

Ühe lubatud teenuse tõestamine, siis vastupidine suund

Tee päring teise peeri tunneli aadressile teenusele, mis peaks vastama, ja vali midagi paremat kui ping. Puuduv ICMP-vastus võib olla hosti filtreerimine, mitte tunneli rike, seega vaikne ping ei tõesta kumbagi suunda. TCP-ühendus pordile, mille sa tead olevat avatud, või päring, mis tagastab andmeid, annab sulle vastuse, mida saad tõlgendada.

Käivita vastupidine suund eraldi testina oma tulemusega, sest kahel suunal on eraldi tulemüüri- ja AllowedIPs-kirjed ning need võivad ebaõnnestuda sõltumatult. Kui kätlemine töötab ja päring mitte, on probleem andmete teel, mitte tunnelis: AllowedIPs, kuulav teenus või hosti tulemüür. Paranda see enne edasisaatmise, NAT-i või DNS-i lisamist, muidu veedad pärastlõuna siludes funktsiooni, mis ei olnud kunagi süüdi.

Baasi hoidmine võrdlusalusena

Salvesta töötav topoloogia ja profiili lähtefail kohta, kust saad taastada, ja hoia need eemale igast kaustast, mis sünkroonib avaliku teenusega. Seejärel lisa üks funktsioon korraga, korrates pärast igaüht algset päringut: edasisaatmine, NAT, LAN-i marsruut ja alles siis DNS. Iga täiendus, mis testi rikub, on nüüd tuvastatav, sest miski muu ei liikunud.

Baas, mis teeb ainult ikooni roheliseks, ei ole sulle öelnud midagi selle kohta, milline täiendus põhjustas järgmise rikke. Hoia ainus lubatud tee töös võrdlusalusena, ja iga hilisemat muudatust mõõdetakse selle vastu.