WireGuard pilnas tunelis: AllowedIPs 0.0.0.0/0 nepakanka

Įrašyti 0.0.0.0/0, ::/0 į partnerio AllowedIPs yra žingsnis, kurį visi prisimena, ir jis nusprendžia tik tai, kokį srautą partneriui leidžiama perduoti. Šie prefiksai nesukuria maršrutų, nieko nepersiunčia kitoje pusėje ir palieka kiekvienos programos resolverį tiksliai ten, kur jis buvo. Keturi atskiri dalykai turi galioti vienu metu, kad pilnas tunelis būtų tikrai pilnas, ir juos geriausia tikrinti žemiau nurodyta tvarka, nes vėlesnis patikrinimas negali išgelbėti ankstesnio. Kiekvienas žemiau esantis patikrinimas yra faktas, kurį galima perskaityti iš mašinos, o ne nustatymas, kurį tikimasi, kad buvo pritaikytas.

Ką partnerio prefiksas pasirenka, o ko ne

AllowedIPs yra kartu ir parinkiklis, ir leidimas. Jis vietinei pusei nurodo, į kuriuos tikslus galima siųsti šiam partneriui, o priimančiai pusei – kokius šaltinio adresus šis partneris gali pateikti. Tai ir yra visas darbas. Niekas tame apraše nesukuria maršruto pagrindiniame kompiuteryje, neįjungia persiuntimo nutolusioje pusėje ir neliečia vardų skyrimo.

Štai kodėl konfigūracija gali atrodyti išsami ir elgtis kaip skaidytas tunelis. Prefiksas sako, kad partneris priimtų viską; pagrindinio kompiuterio maršrutų lentelė nusprendžia, kas ten iš tikrųjų patenka, o šliuzas – ar kas nors išeina. Nė vienas iš šių trijų sprendimų negyvena partnerio sekcijoje.

Maršrutizuoti klientą, o ne tik partnerių sąrašą

Tvarkyklės, tokios kaip wg-quick programuoti pagrindinio kompiuterio maršrutų lentelę už jus, todėl du identiški konfigūracijos failai elgiasi skirtingai priklausomai nuo to, kaip sąsaja pakilo. Minimalus profilis yra pakankamai trumpas perskaityti vienu prisėdimu:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Darbą neša dvi detalės. Laukas Address yra vienas pagrindinio kompiuterio prefiksas, o ne potinklis, kurį klientas mano turįs, ir būtent tvarkyklė paverčia numatytuosius AllowedIPs tikru numatytuoju maršrutu. Pakelkite tą patį failą su ip link ir wg setconf ir neatsiras joks maršrutas, o tai atrodo kaip sugedęs tunelis, nors iš tikrųjų tai sveikas tunelis, kuriame praleistas maršrutizavimo žingsnis. wg-quick vadovas dokumentuoja maršrutizavimą ir Table elgseną, kurią šios tvarkyklės prideda.

Skaitykite rezultatą, o ne failą: ip route get 1.1.1.1 turėtų įvardyti tunelio sąsają, o wg show turėtų pranešti apie neseniai įvykusį rankos paspaudimą su judančiu perdavimo skaitikliu. Rankos paspaudimas be maršruto reiškia, kad tvarkyklė niekada nebuvo paleista, ir pakartotinis profilio redagavimas to nepataisys. Paleiskite sąsają taip, kaip ją paleis naudotojas, kitaip testas matuoja jūsų apvalkalą, o ne diegimą.

Laikyti galinį tašką už tunelio ribų

Pilnas tunelis pagauna kiekvieną tikslą, įskaitant tą, su kuriuo jis turi kalbėtis, kad egzistuotų. Tvarkyklės tai sprendžia pridėdamos pagrindinio kompiuterio maršrutą galiniam taškui per pradinį šliuzą, todėl teisinga konfigūracija beveik visada turi vieną sąmoningą išimtį. Pusės konfigūracijos taikymas su tvarkykle, o kitos pusės rankiniu būdu yra įprastas būdas, kuriuo ši išimtis pametama.

Jei galinis taškas yra pagrindinio kompiuterio vardas, kuris sprendžiamas į kelis adresus arba į šeimą, kurios neperduodate, išimtis blogai senėja ir tunelis gali sugesti po įprastai atrodžiusio prisijungimo iš naujo. Prisekite galinį tašką prie adreso, kurį kontroliuojate, arba patvirtinkite, kad tvarkyklė jį įvertina iš naujo, ir po kiekvieno tinklo pakeitimo dar kartą perskaitykite pagrindinio kompiuterio maršrutą.

Tas pats mechanizmas paaiškina, kodėl pilnas tunelis ir belaisvis portalas kovoja. Portalas tikisi perimti srautą, kurį dabar pagauna jūsų tunelis, todėl viešbučių ir oro uostų tinkluose tunelį pakeliate po prisijungimo prie portalo, niekada prieš tai.

Persiuntimas ir grįžimo kelias šliuze

Šliuze įjunkite persiuntimą šeimai, kurią perduodate, leiskite forward grandinei abiem kryptimis, kai verčiate, ir patvirtinkite grįžimo kelią šaltiniui specifine paieška. Niekas iš to neišplaukia iš sėkmingo rankos paspaudimo, nes rankos paspaudimas tik įrodo, kad du partneriai gali keistis UDP. Jis nieko nesako apie tai, kas vėliau nutinka dekapsuliuotam paketui.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Paieška vykdoma šliuze, o ne kliente, kitaip skaitysite kitą maršrutų lentelę. Jei ji įvardija netinkamą sąsają arba praneša, kad maršruto nėra, tada joks kliento pusės pakeitimas nesukurs išėjimo į internetą. Kai šliuzas verčia klientų adresus išeinant, atsakymas priklauso nuo to vertimo būsenos, todėl taisyklė turi egzistuoti abiem srauto kryptims, o ne tik išeinančiai.

DNS ir gedimo būsena, tikrinami atskirai

Pats protokolas nesukonfigūruoja nė vienos programos resolverio. wg-quick taiko eilutę DNS per distribucijos resolverio integraciją, konteineriai ir naršyklės su savo dėklais gali ją ignoruoti, todėl vardas gali sugesti, nors tunelis paketus perduoda nepriekaištingai. Tikrinkite su pagrindinio kompiuterio vardu, o ne adresu, ir užsirašykite, kuris serveris atsakė, o ne manykite, kad tai padarė profilio serveris.

Adresų šeimos yra atskiras testas su atskiru atsakymu. Numatytasis v4 maršrutas nieko nesako apie tai, ką darys programos v6 ryšys, o tunelis, kuris tyliai nutekina antrąją šeimą, yra blogesnis už tą, kuris garsiai sugenda. Klauskite vardo per kiekvieną šeimą, skaitykite sąsają, kurią naudojo kiekviena užklausa, ir patikrinkite vertimo skaitiklius prieš ir po, nes taisyklė, kuri nieko neatitinka, atrodo lygiai taip pat, kaip trūkstama taisyklė.

Galiausiai patikrinkite būseną, kurios norite, kai tunelis sustoja. Pilnas tunelis turėtų sugesti uždarai dėl srauto, kurį jis teigia: jei sąsaja nukrenta ir programos tyliai tęsia per fizinę jungtį, dizainas yra skaidytas tunelis su papildomais žingsniais. Užrašykite numatomą gedimo elgseną, sąmoningai ją patikrinkite ir pabaikite užfiksuodami keturis atsakymus — kuri tvarkyklė pakelia sąsają, kuris maršrutas neša numatytąjį, kas persiunčia ir verčia šliuze, ir kuris resolveris atsako.