WireGuard rankos paspaudimas veikia, bet interneto nėra: sekite paketą

Tunelis veikia, wg show rodo neseniai įvykusį rankos paspaudimą, galite pinginti serverio tunelio adresą, o už jo niekas neatsako. Pirmoji mintis – iš naujo sugeneruoti raktus arba dar kartą pasidalyti konfigūracija. Tai keičia būtent tą kelio dalį, kuri jau įrodyta veikianti.

Baigtas rankos paspaudimas sako, kad abi pusės sutaria dėl raktų, kad UDP pasiekia galinį tašką ir kad kriptografinis maršrutizavimas priima paketą. Jis nieko nesako apie tai, ar paketas po to gali palikti serverį.

Todėl sekite vieną paketą, o ne spėliokite. Yra keturios vietos, kur jis gali žūti, ir kiekviena palieka skirtingą pėdsaką.

Ką rankos paspaudimas iš tikrųjų įrodo

WireGuard yra UDP protokolas, kuris Noise rankos paspaudimu užmezga sesiją ir tada šifruoja paketus partneriui. Kai wg show rodo kelių sekundžių senumo rankos paspaudimą ir augantį perdavimo skaitiklį, galinis taškas, raktai ir partnerio viešasis raktas visi yra teisingi.

Ko jis neįrodo: kad jūsų klientas apskritai siunčia į internetą nukreiptą srautą į sąsają, kad serveris pasirengęs jį persiųsti arba kad atsakymas gali rasti kelią atgal. Tai branduolio maršrutizavimo ir užkardos sprendimai, ir jie priimami už tunelio ribų.

Štai kodėl ping į serverio tunelio adresą yra toks klaidinantis bandymas. Tas paketas yra adresuotas pačiam serveriui, todėl jis baigiasi lokaliai. Jam niekada nereikia persiuntimo, niekada vertimo ir niekada grįžimo maršruto iš interneto.

AllowedIPs yra maršrutizavimo sprendimas

Kliente AllowedIPs atlieka du darbus. Tai kriptografinio rakto maršrutizavimo lentelė, kuri nusprendžia, kurie paskirties adresai siunčiami į šio partnerio tunelį, ir tai šaltinio adresų, kuriuos partneris priims iš jūsų, sąrašas. Jei kliento konfigūracijoje nurodytas tik 10.8.0.0/24, viešos paskirties vietos niekada nepatenka į sąsają, o įprastas numatytasis maršrutas jas nuneša už tunelio. Tada tunelis veikia nepriekaištingai ir nedaro nieko, ko norėjote.

Žiūrėkite, ką klientas iš tikrųjų įdiegė, o ne ką sako konfigūracijos failas:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Antroji komanda yra lemiama. Jei atsakyme nurodyta fizinė sąsaja ir įprasti tinklo vartai, paketas nekeliauja tuneliu ir joks pakeitimas serverio pusėje to nepataisys. Pridėkite 0.0.0.0/0 IPv4 ir ::/0 IPv6 atskirai; taisyklė, kuri vienai šeimai apima viską, palieka kitą pirminiame kelyje, ir tai dažna veikiančio IPv4 tunelio ir sustingusios IPv6 paieškos priežastis.

Kur paketas žūva tinklo vartuose

Jei maršrutas teisingas, o paketas vis tiek niekur neina, jis pasiekia serverį ir ten sustoja. Keturi patikrinimai apima daugumą tinklo vartų.

Persiuntimas. sysctl net.ipv4.ip_forward grąžinantis 0 yra klasikinis atsakymas, ir daugelis distribucijų vis dar pagal numatytuosius nustatymus yra 0. Jis turi būti 1 ir turi būti nustatytas visam laikui sysctl faile, o ne komanda, kuri dingsta paleidus iš naujo. IPv6 persiuntimas yra atskiras jungiklis.

Filtravimo politika. Grandinė FORWARD su numatytąja atmetimo politika atmes tunelio srautą, bet praleis srautą į patį mazgą, ir tai tiksliai atitinka simptomą. Skaitykite gyvą taisyklių rinkinį, o ne išsaugotą failą: nft list ruleset arba iptables -S.

Vertimas arba maršrutizavimas. Klientams su privačiais tunelio adresais reikia arba šaltinio NAT serverio išėjimo sąsajoje, arba maršrutizuoto prefikso, kurį viršutinis tinklas moka grąžinti. Pasirinkimas tarp jų seka adresų planą. MASQUERADE pridėjimas prie tinklo, kuris jau maršrutizuoja jūsų prefiksą atgal, yra nekenksmingas, bet beprasmis, o jo praleidimas ten, kur maršruto nėra, palieka atsakymus adresuotus į nemaršrutizuojamą privatų diapazoną.

Grįžimo kelias. Maršrutizuotuose sprendimuose viršutiniam maršrutizatoriui reikia maršruto, nukreipto į jūsų serverį. Teikėjo tinklas taip pat gali tai blokuoti: kelios debesys įjungia šaltinio ir paskirties patikrinimą instancijoje, kuris tyliai atmeta paketus, kurių šaltinis nėra pats instancijos adresas, kol tas patikrinimas neišjungiamas.

DNS nepavyksta kitaip nei maršrutizavimas

Paketas į žinomą adresą ir vardo paieška yra dvi atskiros klaidos, o klaidų pranešimai klaidina priešingomis kryptimis. Jei ping 1.1.1.1 veikia, o naršyklė nieko nepakrauna, maršrutas geras, o vardų skyrimas ne. Jei pats ping nepavyksta, DNS nesvarbus ir jūs grįžote į ankstesnį skyrių.

wg-quick gali nustatyti resolverį iš konfigūracijos eilutės DNS =, o systemd-resolved turi savo elgesį kiekvienai jungčiai. VPN, kuris perrašo resolverį adresu, pasiekiamu tik tunelio viduje, nepavykdys kiekviena paieška tą akimirką, kai tunelis krenta, ir tai atrodo tarsi tunelis gadintų internetą.

Tvarka, kuri duoda įrodymus

Pirmiausia atlikite kliento pusės patikrinimą, nes tai viena komanda ir ji pašalina pusę galimybių. Tada patvirtinkite, ar serveris apskritai skirtas būti interneto išėjimu; privatiems prisijungimams sukurti tinklo vartai nesugedę, kai viešos paskirties vietos nepasiekiamos.

Serveryje stebėkite sąsają, kol siunčiate ping iš kliento: tcpdump -ni wg0 icmp turėtų rodyti užklausą, o tcpdump -ni eth0 icmp turėtų rodyti, kad ji išeina, išversta ar ne. Jei ji pasirodo pirmame ir niekada antrame, sustojimas yra lokalus serveriui. Jei ji išeina ir atsakymas nebegrįžta, problema yra aukščiau, ir tai jau kitas pokalbis.

Galiausiai pasirūpinkite, kad pataisa išliktų po paleidimo iš naujo. Persiuntimas priklauso sysctl failui, užkardos taisyklės – tarnybai, kuri jas įkelia, o kliento maršrutai – konfigūracijai, kuri pakelia sąsają, o ne apvalkalui, kurį pamiršite. Prisijunkite iš naujo, pakartokite tuos pačius du bandymus ir patvirtinkite, kad skaitikliai juda.