WireGuard hosto priešdėlis: kodėl vienas adresas veikia, o kiti ne

Tunelis pakeltas, handshake vyksta kas dvi minutes, ir lygiai vienas adresas kitoje pusėje atsako. Pingai į peer’o tunelio adresą veikia; niekas už jo neveikia. Kažkas perskaito sąsajos konfigūraciją, pamato hosto priešdėlį ir padaro išvadą, kad kaukė neteisinga. Jo išplėtimas iki /24 pingą sutvarko kuriam laikui ir tada sugadina ką nors kita. Priešdėlis niekada nebuvo priežastis, o trūkstamas maršrutas nėra tas, kurį valdo kaukė.

Ką iš tikrųjų sukuria sąsajos priešdėlis

Linux sistemoje adreso priskyrimas sąsajai sukuria prijungtą maršrutą tam priešdėliui. Jei priskirsite hosto priešdėlį, prijungtas maršrutas apima vieną adresą. Jei priskirsite /24, jis apima 256, ir kiekvienas jų dabar laikomas pasiekiamu per tą jungtį.

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

Hosto priešdėlis yra visiškai normalus pasirinkimas taškas-taškas tuneliui, nes kitame gale yra lygiai vienas peer’as. Trečioji komanda yra ta, kuri atsako į naudotojo klausimą: ji nurodo, kurią sąsają branduolys naudotų tam tikslui, ir neparodys nieko naudingo, jei joks maršrutas neatitinka.

Tai yra visas simptomo paaiškinimas. Vienas adresas atsako todėl, kad jam yra prijungtas maršrutas, arba todėl, kad peer’o leidžiamų sąrašas atsitiktinai jį apima. Visa kita neturi maršruto ir yra išmetama dar prieš WireGuard įsitraukiant. Tunelis visą laiką sveikas, todėl handshake skaitiklis ir toliau atrodo raminantis.

AllowedIPs yra dvi taisyklės po vienu pavadinimu

WireGuard leidžiamų sąrašas kiekvienam peer’ui atlieka du darbus vienu metu, ir konfigūracijos sintaksė leidžia jiems atrodyti kaip vienam. Įeinant, jis leidžia, kokius šaltinio adresus peer’as gali pateikti. Išeinant, jis pasirenka, kuriam peer’ui siunčiamas paketas, radęs tiksliausią atitikimą.

Nė vienas iš šių darbų nėra maršrutizavimas. Branduolys vis tiek turi nuspręsti, kad paketas priklauso tunelio sąsajai, prieš WireGuard jam pažvelgiant, ir šis sprendimas ateina iš maršrutizavimo lentelės. Peer’o įrašas su plačiu leidžiamų sąrašu pats maršruto neįdiegia.

Todėl konfigūracija gali atrodyti išsami, o elgtis asimetriškai. Klientas siunčia į kitą pusę, nes maršrutas egzistuoja, o atsakymai niekada neateina, nes kitos pusės leidžiamų sąrašas neleidžia kliento šaltinio, arba nes kita pusė neturi grįžimo kelio. Abi kryptys yra atskiri sprendimai su atskirais gedimo režimais. Užsirašyti, kurią iš jų tikrinate, yra pusė diagnozės.

Iš kur atsiranda maršrutas

Jei naudojate wg-quick, maršrutai jums sugeneruojami iš kiekvieno peer’o leidžiamų sąrašo, nebent nustatėte Table = off ir patys perėmėte valdymą. Tai yra dokumentuotas įrankio elgesys ir priežastis, kodėl konfigūracija be aiškių maršrutų nurodymų vis tiek veikia.

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

Palyginkite leidžiamų sąrašą su maršrutais, kurie iš tikrųjų yra. Peer’as, leidžiantis visą potinklį, bet sukūręs tik hosto maršrutą, reiškia, kad pagalbininkas niekada neveikė, arba kad sąsają valdote tiesiogiai su wg ir ip, ir tokiu atveju niekas jums maršrutų nekuria.

Kai valdote rankiniu būdu, maršrutas yra viena eilutė ir jo forma aiški: tikslas per sąsają, be šliuzo, nes jungtis yra taškas-taškas. Jo pridėjimas nėra apėjimas dėl blogo priešdėlio; tai trūkstama pusė projekto, kuris sąmoningai ėmėsi maršrutizavimo pats.

Platesnis priešdėlis neprideda peer’o įrašo

Viliojantis pataisymas yra pakeisti adresą į /24, kad prijungtas maršrutas apimtų serverio vietinį tinklą. Atrodo, kad veikia, ir priežastis, kodėl atrodo, kad veikia, yra ta, kad prijungtas maršrutas dabar atitinka, o ne tai, kad WireGuard ko nors naujo išmoko.

Ką taip pat padarėte, tai pareikalavote viso diapazono kaip tiesiogiai pasiekiamo per tą jungtį, įskaitant adresus, priklausančius kitiems peer’ams arba vietiniam tinklui, kuris iš tikrųjų yra už serverio. Srautas į tuos adresus dabar patenka į tunelį, ir ar jis išeis kitoje pusėje, priklauso nuo paties serverio maršrutizavimo ir leidžiamų sąrašų.

Kriptografinė pusė jokiu būdu nepažeidžiama. WireGuard vis dar reikia leidžiamų sąrašo įrašo, apimančio tikslą, kad pasirinktų peer’ą, o kitai pusei vis dar reikia įrašo, apimančio jūsų šaltinį, kad jį priimtų. Platesnis sąsajos priešdėlis negali suteikti nė vieno.

Patvirtinkite abi kryptis prieš ką nors keisdami

Nagrinėkite abu galus atskirai ir užsirašykite, ką kiekvienas sako. Kliente maršrutas ir peer’o įrašas; serveryje veidrodinis vaizdas plius jo paties grįžimo kelias:

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

Užfiksavimas yra tai, kas išsprendžia ginčus dėl krypties. Jei išeinantys paketai pasirodo tunelio sąsajoje, o serveris nieko neįrašo, tolimas galas juos atmeta, dažniausiai todėl, kad jūsų šaltinis yra už jo leidžiamų sąrašo ribų. Jei apskritai nieko nepasirodo, maršruto trūksta arba jis rodo kitur.

Tada sutaisykite siauresnį galą. Įrašas leidžiamų sąraše serverio pusėje jūsų kliento adresui ir įrašas kliento pusėje tiksliniam potinkliui yra įprasta forma, ir ji palieka sąsajos priešdėlį ramybėje. Plėskite priešdėlį tik jei adresų planas tikrai nori bendro potinklio toje jungtyje, ir darykite tai kaip plano pakeitimą, o ne derinimo žingsnį.