WireGuardi hosti prefiks: miks üks aadress töötab ja ülejäänud mitte

Tunnel on üleval, handshake toimub iga kahe minuti järel ja täpselt üks aadress teisel pool vastab. Pingid peeri tunneli aadressile töötavad; mitte miski selle taga ei tööta. Keegi loeb liidese konfiguratsiooni, näeb hosti prefiksit ja järeldab, et mask on vale. Selle laiendamine /24-le parandab pingi mõneks ajaks ja rikub siis midagi muud. Prefiks ei olnud kunagi süüdlane ja puuduv marsruut ei ole see, mida mask juhib.

Mida liidese prefiks tegelikult loob

Linuxis loob aadressi liidesele omistamine selle prefiksi jaoks ühendatud marsruudi. Kui omistate hosti prefiksi, katab ühendatud marsruut ühe aadressi. Kui omistate /24, katab see 256, ja igaüht neist peetakse nüüd selle lingi kaudu kättesaadavaks.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Hosti prefiks on punkt-punkt-tunneli jaoks täiesti tavaline valik, sest teises otsas on täpselt üks peer. Kolmas käsk on see, mis vastab kasutaja küsimusele: see ütleb, millist liidest kernel selle sihtkoha jaoks kasutaks, ja ei näita midagi kasulikku, kui ükski marsruut ei sobitu.

See on kogu sümptomi seletus. Üks aadress vastab, sest selle jaoks on ühendatud marsruut, või sellepärast, et peeri lubatud nimekiri juhtumisi sisaldab seda. Kõigel muul puudub marsruut ja see visatakse ära enne, kui WireGuard üldse mängu tuleb. Tunnel on kogu aeg terve, mistõttu handshake’i loendur näib jätkuvalt julgustav.

AllowedIPs on kaks reeglit ühe nime all

WireGuardi peeripõhine lubatud nimekiri teeb korraga kahte tööd ja konfiguratsiooni süntaks paneb need paistma ühena. Sissetuleval suunal lubab see, milliseid lähteaadresse peer esitada tohib. Väljuvas suunas valib see, millisele peerile pakett saadetakse, leides kõige täpsema vastavuse.

Kumbki neist töödest ei ole marsruutimine. Kernel peab ikkagi otsustama, et pakett kuulub tunneli liidesele, enne kui WireGuard seda vaatab, ja see otsus tuleb marsruutimistabelist. Peerikirje laia lubatud nimekirjaga ei paigalda iseenesest marsruuti.

Seetõttu võib konfiguratsioon paista täielik ja käituda asümmeetriliselt. Klient saadab teisele poole, sest marsruut on olemas, ja vastused ei jõua kunagi kohale, sest teise poole lubatud nimekiri ei luba kliendi lähtet, või sest teisel poolel pole tagasiteed. Mõlemad suunad on eraldi otsused eraldi rikkerežiimidega. Kirja panemine, millist neist testite, on pool diagnoosi.

Kust marsruut tuleb

Kui kasutate wg-quicki, genereeritakse marsruudid teie jaoks iga peeri lubatud nimekirjast, välja arvatud juhul, kui olete seadnud Table = off ja võtnud juhtimise ise üle. See on tööriista dokumenteeritud käitumine ja põhjus, miks konfiguratsioon ilma selgete marsruudikorraldusteta siiski töötab.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Võrrelge lubatud nimekirja tegelikult olemasolevate marsruutidega. Peer, mis lubab tervet alamvõrku, kuid lõi ainult hosti marsruudi, tähendab, et abiline ei käivitunud kunagi, või et haldate liidest otse wg ja ip abil, ja sel juhul ei genereeri miski teie jaoks marsruute.

Kui haldate seda käsitsi, on marsruut üks rida ja selle kuju on selge: sihtkoht läbi liidese, ilma lüüsita, sest link on punkt-punkt. Selle lisamine ei ole halva prefiksi möödaminek; see on puuduv pool konstruktsioonist, mis otsustas marsruutimise ise enda peale võtta.

Laiem prefiks ei lisa peerikirjet

Ahvatlev parandus on muuta aadress /24-ks, et ühendatud marsruut kataks serveri lokaalvõrgu. See näib töötavat, ja põhjus, miks see näib töötavat, on see, et ühendatud marsruut sobib nüüd, mitte see, et WireGuard oleks midagi uut õppinud.

Mida te samuti tegite, on kogu vahemiku nõudmine otse selle lingi kaudu kättesaadavana, sealhulgas aadressid, mis kuuluvad teistele peeridele või lokaalvõrgule, mis on tegelikult serveri taga. Liiklus nendele aadressidele siseneb nüüd tunnelisse, ja kas see tuleb teisel pool välja, sõltub serveri enda marsruutimisest ja lubatud nimekirjadest.

Krüptograafiline pool ei ole mingil juhul mõjutatud. WireGuard vajab endiselt lubatud nimekirja kirjet, mis katab sihtkoha, et peeri valida, ja teine pool vajab endiselt kirjet, mis katab teie lähte, et seda aktsepteerida. Laiem liidese prefiks ei suuda pakkuda kumbagi.

Kinnitage mõlemad suunad enne, kui midagi muudate

Käsitlege kahte otsa eraldi ja kirjutage üles, mida kumbki ütleb. Kliendis marsruut ja peerikirje; serveris peegelpilt pluss selle enda tagasitee:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

Püüdmine on see, mis lahendab vaidlused suuna üle. Kui väljuvad paketid ilmuvad tunneli liidesele ja server ei logi midagi, lükkab kaugem ots need tagasi, tavaliselt sellepärast, et teie lähe on väljaspool selle lubatud nimekirja. Kui midagi üldse ei ilmu, puudub marsruut või osutab see mujale.

Seejärel parandage kitsam ots. Kirje lubatud nimekirjas serveri poolel teie kliendi aadressi jaoks ja kirje kliendi poolel sihtalamvõrgu jaoks on tavaline kuju, ja see jätab liidese prefiksi puutumata. Laiendage prefiksit ainult siis, kui aadressiplaan tõesti soovib sellel lingil jagatud alamvõrku, ja tehke seda plaani muudatusena, mitte silumissammuna.