Näin rakennat kahden peerin WireGuard-testin, joka todistaa yhden reitin

WireGuard-testi, joka kuljettaa oletusreittiä, LAN-etuliitettä, DNS:ää ja palomuurin poikkeusta, ei voi kertoa sinulle, mikä niistä hajosi. Pelkistä se kahteen peeriin, yhteen osoitepariin ja yhteen sallittuun palveluun, niin vian ei tarvitse piiloutua mihinkään. Tylsä perusta on diagnoosi. Rakenna se ensin; se vie viisitoista minuuttia ja säästää iltapäivän, jonka muuten käyttäisit arvailuun.

Se, mitä perusta todistaa, on kapeampaa kuin useimmat odottavat. Se todistaa, että kaksi identiteettiä ovat samaa mieltä, että UDP saavuttaa kuuntelevan portin ja että yksi sallittu kohde kuljettaa pyynnön. Edelleenohjaus, NAT, LAN-reitit ja DNS ovat erillisiä ominaisuuksia, jotka lisätään myöhemmin, yksi kerrallaan.

Avaimet, osoitteet ja ainoa endpoint

Luo avainpari jokaiseen järjestelmään ja siirrä niiden välillä vain julkiset puoliskot. wg genkey | tee privatekey | wg pubkey > publickey on dokumentoitu yhden rivin komento, ja se jättää yksityisen avaimen tiedostoon, jonka voit sitten suojata. Valitse tunneliosoitteet alueelta, jota ei esiinny missään muussa omistamassasi kokoonpanossa, kuten 10.99.0.1/24 ja 10.99.0.2/24. Kirjoita muistiin, mikä osoite kuuluu millekin koneelle, koska jokainen myöhempi tarkistus riippuu siitä kuvauksesta.

Yksityiset avaimet eivät koskaan matkusta. Jos testi tarvitsee yhden kopioituna toiselle puolelle, testi on jo mennyt pieleen. Kun kaksi järjestelmää ovat NAT:n takana, ainakin toinen tarvitsee tavoitettavissa olevan UDP-portin, kun taas toinen kantaa Endpointia, joka osoittaa siihen, ja julkinen osoite ja portti kuuluvat muistiinpanoihisi eivätkä oletuksiisi 51820:stä.

Portin edelleenohjaus, joka kuvaa eri ulkoisen portin, toimii hyvin, kunhan Endpoint vastaa sitä. Epäsopivuudet täällä tuottavat hiljaisuutta eivätkä virheitä, siksi ne kannattaa tarkistaa paperilla ennen johdolla virheenjäljitystä.

Kentät, jotka kuuluvat wg:lle, ja ne, jotka eivät

Ydinkenttien joukko on pieni: PrivateKey ja ListenPort Interface-osiossa, PublicKey, AllowedIPs ja Endpoint Peer-osiossa. Address ja DNS kuuluvat wg-quickille eivätkä wg:lle itselleen, ja tuo ero puree heti, kun sama kokoonpano siirtyy toiseen työkaluun.

[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 hoitaa kahta tehtävää yhtä aikaa. Se valitsee, mitkä kohteet menevät tunneliin, ja se valtuuttaa peerin käyttämään näitä lähdeosoitteita saapuessaan. Siksi vastapuolen peilimerkinnän on nimettävä tunneliosoitteesi tarkasti; väärälle peerille annettu /32 luetaan reititysongelmaksi ja käyttäytyy kuin valtuutusongelma. WireGuardin pikakäynnistys näyttää saman kahden peerin muodon kanonisella sanamuodolla, jos haluat vertailla kenttien nimiä.

Kättelyn lukeminen kuvakkeen sijaan

Nosta liitäntä sen omistajan kautta ja lue sitten tila, älä merkkivaloa. wg show tulostaa viimeisimmän kättelyn peeriä kohden sekä tavulaskurit, ja kättely viimeisen muutaman minuutin sisällä tarkoittaa, että avaimet, endpoint ja UDP-reitti toimivat kaikki. Laskuri, joka nousee vain yhteen suuntaan, on oma vastauksensa, eikä se ole sama vika kuin kättely, jota ei koskaan tapahdu.

Kaksi vikaa merkitsevät erilaisia tutkimuksia. Kättelyn täydellinen puuttuminen viittaa avainten eroavuuteen, väärään Endpointiin, estettyyn UDP:hen tai palomuuriin, joka pudottaa itse kättelyn. Kättely, joka onnistuu mutta data ei mene mihinkään, viittaa AllowedIPs:iin, palveluun, joka ei kuuntele tunneliosoitteessa, tai isäntäkoneen palomuuriin, joka hyväksyy portin LAN:lle mutta ei tunneliliitännälle. Ne ovat järjestelmän eri puolia, ja perusta erottaa ne ennen kuin alat muuttaa sääntöjä.

Yhden sallitun palvelun todistaminen, sitten vastasuunta

Lähetä pyyntö toisen peerin tunneliosoitteeseen palvelulle, jonka pitäisi vastata, ja valitse jotain pingiä parempaa. Puuttuva ICMP-vastaus voi olla isännän suodatusta eikä tunnelin vika, joten äänetön ping ei todista kumpaakaan suuntaa. TCP-yhteys porttiin, jonka tiedät olevan auki, tai dataa palauttava pyyntö antaa sinulle vastauksen, jonka voit tulkita.

Aja vastasuunta erillisenä testinä omalla tuloksellaan, koska kahdella suunnalla on erilliset palomuurin ja AllowedIPs:n merkinnät ja ne voivat epäonnistua toisistaan riippumatta. Jos kättely toimii mutta pyyntö ei, ongelma on datareitillä eikä tunnelissa: AllowedIPs, kuunteleva palvelu tai isännän palomuuri. Korjaa se ennen edelleenohjauksen, NAT:n tai DNS:n lisäämistä, muuten vietät iltapäivän sellaisen ominaisuuden virheenjäljitykseen, joka ei koskaan ollut syyllinen.

Perustan pitäminen vertailukohtana

Tallenna toimiva topologia ja profiilin lähde paikkaan, josta voit palauttaa sen, ja pidä ne poissa jokaisesta hakemistosta, joka synkronoituu julkiseen palveluun. Lisää sitten yksi ominaisuus kerrallaan ja toista alkuperäinen pyyntö jokaisen jälkeen: edelleenohjaus, NAT, LAN-reitti ja vasta sitten DNS. Jokainen lisäys, joka rikkoo testin, on nyt tunnistettavissa, koska mikään muu ei liikkunut.

Perusta, joka vain muuttaa kuvakkeen vihreäksi, ei ole kertonut sinulle mitään siitä, mikä lisäys aiheutti seuraavan vian. Pidä ainoa sallittu reitti toiminnassa vertailukohtana, ja jokaista myöhempää muutosta mitataan sitä vasten.