WireGuard mazgas nepasiekiamas, kai kitas veikia: kontrolinis sąrašas

Vienas WireGuard mazgas praleidžia srautą, o antrasis atlieka rankos paspaudimą, bet niekada nepasiekia nieko už tunelio. Veikiantis mazgas jums sako, kad sąsaja, UDP prievadas ir serverio raktas tikriausiai tvarkingi. Jis nieko nesako apie antrojo mazgo AllowedIPs, jo vidinį šaltinio adresą ar peradresavimo taisykles tarp jų. Peržiūrėkite sąrašą iš eilės ir sustokite ties pirmuoju žingsniu, kurio sąlyga netenkinama.

1 veiksmas: Užrašykite kelią, kuriuo turėtų eiti paketas

Du klientai tame pačiame koncentratoriuje nepasiekia vienas kito automatiškai. Koncentratoriaus ir spindulių schemoje serveris priima paketą wg0 ir turi jį perduoti atgal iš wg0 kitam mazgui, o tam reikia IP peradresavimo ir peradresavimo taisyklės. Tiesioginėje mazgo-su-mazgu schemoje kiekviena pusė turi turėti kitos pusės galinį tašką ir kitos pusės tunelio adresą AllowedIPs viduje. Prieš skaitydami bet kokią konfigūraciją nuspręskite, kurią schemą derinate.

Tikėtinas kelias taip pat pasako, kur žiūrėti. Jei paketas turi kirsti koncentratorių, nepavykęs šuolis yra arba siuntėjo AllowedIPs, arba koncentratoriaus peradresavimas, arba gavėjo AllowedIPs. Jei jis turi eiti tiesiogiai, koncentratorius nesvarbus, o abiejų mazgų galinio taško laukai yra svarbūs.

2 veiksmas: Palyginkite AllowedIPs abiejose pusėse, o ne tik vienoje

WireGuard naudoja AllowedIPs ir kaip maršrutų lentelę, ir kaip prieigos sąrašą. Siunčiant paskirties adresas ieškomas mazgo AllowedIPs, kad būtų pasirinktas tunelis; priimant vidinis šaltinio adresas turi patekti į siunčiančio mazgo AllowedIPs, kitaip paketas atmetamas. Trūkstamas diapazonas bet kurioje pusėje duoda tą patį simptomą: transportas veikia, turinys dingsta.

Skaitykite gyvą būseną, o ne failą, nes perkrovimas galėjo tyliai nepavykti: sudo wg show wg0 allowed-ips. Serveryje nepavykusio mazgo įrašas turi apimti jo tunelio adresą, pavyzdžiui 10.90.0.3/32. Kliente serverio mazgo įrašas turi apimti tikslą, kurį testuojate, nesvarbu, ar tai koncentratoriaus tunelio adresas, ar nuotolinis potinklis. Persidengiantys diapazonai daro paiešką dviprasmišką ir gali pasirinkti ne tą mazgą, todėl laikykite juos atskirai.

3 veiksmas: Patikrinkite vidinį šaltinio adresą

Klientas, kuris maršrutizuoja 10.90.0.3 per wg0, bet siunčia paketus iš savo Wi-Fi adreso, bus atmestas gavėjo, nes šaltinis neatitinka mazgo AllowedIPs. Patvirtinkite, ką branduolys iš tikrųjų pasirenka, naudodami ip route get 10.90.0.3 from 10.90.0.2, ir patvirtinkite tunelio sąsajai priskirtą adresą naudodami ip -brief addr show wg0.

Priimančiame Linux hoste atvirkštinio kelio filtravimas yra antrieji vartai. Griežtas rp_filter sąsajoje, kuriai priklauso grįžimo maršrutas, gali atmesti tunelio srautą, kurio grįžimo kelias neatitinka sąsajos, kuria jis atkeliavo. Prieš išjungdami patikrinkite efektyviąją reikšmę; daugelyje topologijų teisingas sprendimas yra maršrutas, o ne atlaisvintas filtras.

4 veiksmas: Peržiūrėkite koncentratoriaus peradresavimą ir grįžimo kelią

Jei koncentratorius turi perduoti tarp mazgų, branduoliui reikia net.ipv4.ip_forward=1, o ugniasienė turi priimti perduodamą srautą: įėjimas per wg0, išėjimas per wg0, nuo siuntėjo tunelio adreso iki gavėjo. Dažna klaida yra įvesties taisyklė, priimanti UDP 51820, bet be peradresavimo taisyklės], todėl rankos paspaudimas pavyksta, o turinys miršta. Išvardykite galiojančias taisykles naudodami sudo nft list ruleset arba atitikmenį jūsų ugniasienės tvarkyklėje.

Tada patikrinkite atsakymą. Paskirties hostas turi turėti grįžimo maršrutą į siuntėją, arba per koncentratorių, arba per savo šliuzą. Jei koncentratorius taip pat NATina tunelio potinklį, patvirtinkite, kad vertimas taikomas perduodamam srautui ir kad atsakymas pasiekia koncentratorių prieš pasibaigiant būsenai. Vienkryptė klaida, kuri atrodo kaip rakto problema, dažnai yra būtent šis grįžimo maršrutas.

Galiausiai atskirkite rankos paspaudimą nuo duomenų. Mazgas, kuris baigia rankos paspaudimą, bet stringa dideliuose perdavimuose, paprastai turi MTU ar MSS problemą būtent tame kelyje, o ne AllowedIPs problemą. Išbandykite pirmiausia mažu ping, paskui pilno dydžio, ir palyginkite abu mazgus.

5 veiksmas: Pakeiskite vieną dalyką ir palikite veikiantį mazgą nepažeistą

Atlikite vieną pakeitimą nepavykusiame kelyje ir iš naujo išbandykite abu mazgus. Visų mazgų AllowedIPs pakeitimas į 0.0.0.0/0 yra greičiausias būdas sugadinti jau veikusį mazgą, nes tai pakeičia maršrutizavimo sprendimą visam tos sąsajos srautui. Redaguokite tą vieną įrašą, įkelkite iš naujo ir perskaitykite gyvą būseną.

Užrašykite, kuris kelias pavyko, kuris nepavyko, ir tikslią kiekvieno komandos išvestį. Šis palyginimas vertingesnis už bendrą pranešimą, kad VPN sugedo, ir to pirmiausia paprašys kitas žmogus.