Ar IPv6 srautas turi eiti per VPN, ar tiesiogiai?

Praėjusį mėnesį du žmonės paprašė manęs priešingų rezultatų: vienas norėjo, kad VPN apimtų IPv6, kitas norėjo, kad biuro spausdintuvas toliau veiktų. Vienas maršrutas ::/0 negali abiejų užtikrinti savarankiškai. Ar tas maršrutas priklauso tunelio viduje, priklauso nuo trijų sąlygų, o pirmoji jo neįtraukia daugumai komercinių išėjimų. Jei išėjimas neperduoda IPv6, numatytojo maršruto nukreipimas ten paslėps jūsų srautą tunelyje, kuris neturi kur jo siųsti.

Atsakymą nusprendžia trys sąlygos

Numatytasis maršrutas yra viena eilutė, ::/0, ir jis atitinka bet kurį IPv6 tikslą be konkretesnio maršruto (RFC 4291). Jį įdiegti lengva. Sprendimas, ar turėtumėte, susiveda į tris sąlygas.

Pirmoji sąlyga: išėjimas, prie kurio jungiatės, turi veikiantį IPv6 ir yra pasirengęs jį persiųsti. Antroji sąlyga: jūsų klientas gali išlaikyti kelią iki tunelio galinio taško, kuris paprastai yra diapazone, kurį ketinate maršrutizuoti. Trečioji sąlyga: galite įvardyti vietinius IPv6 tikslus, kurie turi likti už tunelio.

Kiekviena sąlyga nepavyksta savaip, todėl spėliojimas kainuoja visą vakarą. Nepavykusi pirmoji sąlyga duoda tyką ir maršrutų lentelę, kuri atrodo teisingai. Nepavykusi antroji sąlyga nužudo rankos paspaudimą po kelių sekundžių nuo pradžios. Nepavykusi trečioji sąlyga palieka veikiantį tunelį ir nepatenkintą kolegą prie spausdintuvo.

Ar išėjimas tikrai perduoda IPv6?

Tunelio sąsaja su IPv6 adresu nieko neįrodo apie kitą pusę. Daugelis komercinių profilių viduje yra tik IPv4: serveris duoda jums v4 adresą ir išmeta visa kita. Įdiekite viršuje numatytąjį maršrutą iš AllowedIPs ir branduolys mielai siqs IPv6 į sąsają, kurios partneris jo niekada nemato.

Testuokite iš kliento, kol tunelis pakeltas. ping -6 -c 3 2001:4860:4860::8888 ir ip -6 route get 2001:4860:4860::8888 atsako į skirtingus klausimus: ar grįžta atsakymas ir kurį įrenginį branduolys pasirinko. Kai antrasis įvardija jūsų tunelį, o pirmasis nieko negrąžina, problema yra išėjime, ne maršrute.

Jei išėjimą valdote patys, kliento testas gali praeiti, o kelias vis tiek atsidurti aklavietėje. Patvirtinkite net.ipv6.conf.all.forwarding=1 šliuze ir kad jo ugniasienė priima paketus, persiunčiamus iš tunelio. Teisingai maršrutizuotas paketas į išėjimą, kuris atsisako persiųsti, iš kliento pusės atrodo lygiai kaip maršrutizavimo klaida.

Ar klientas gali išlaikyti kelią iki galinio taško?

Tai atvejis, kuris mane sugavo nešiojamajame kompiuteryje su tik IPv6 WireGuard galiniu tašku. Galinio taško adresas yra įprastas globalus adresas, todėl jis patenka į ::/0. Maršrutizuokite visą priešdėlį į sąsają, ir rankos paspaudimo paketai nusivys patys į tunelį, kurį dar bando pastatyti. Tunelis niekada nepakyla, ir niekas kliento išvestyje nepasako kodėl.

wg-quick tai sprendžia Linux. Jis išveda maršrutus iš AllowedIPs, įdiegia juos savo lentelėje ir prideda politikos taisyklę, kad srautas į galinį tašką pirmiausia būtų sprendžiamas per pagrindinę lentelę: taisyklė suppress_prefixlength 0, kurią rasite ip -6 rule. Todėl wg-quick up pavyksta ten, kur ranka rašytas ip -6 route add default dev wg0 jus atkerta.

Patikrinkite abi būsenas naudodami ip -6 route get <endpoint-v6>, prieš pakeldami tunelį ir po to. Jei atsakymas pasikeičia į jūsų tunelio įrenginį, pašalinote kelią, kurio tuneliui reikia. Kai rašote maršrutus patys, pridėkite prieglobos maršrutą iki galinio taško per pradinį šliuzą arba prisijunkite prie galinio taško per IPv4 ir palikite IPv6 naudingajai apkrovai.

Kas turi likti už tunelio?

Konkretesni maršrutai nugali numatytąjį, todėl priešdėlis ant jungties arba ULA diapazonas su savo maršrutu toliau veikia be papildomų pastangų. Tai tylioji priežastis, kodėl tiek daug pilno tunelio IPv4 konfigūracijų išgyvena: LAN priešdėliai yra konkretesni už numatytąjį ir niekada nepatenka į tunelį.

Tai lūžta, kai vietinis įrenginys pasiekiamas per globalų adresą, o tai normalu spausdintuvui, kuriam tas pats maršrutizatorius davė viešą priešdėlį, NAS ar televizoriui. Tie adresai atitinka ::/0 ir nieko daugiau, todėl jie persikelia į tunelį su viskuo kitu ir išnyksta.

Spręskite pagal tikslą, ne pagal protokolą. Jei du ar trys vietiniai kompiuteriai svarbūs, duokite jų priešdėliams maršrutą per fizinę sąsają, arba pašalinkite juos iš suderinto rinkinio. Jei sąrašas toliau auga, sąžiningas atsakymas yra IPv6 split tunneling su rašytiniu išimčių sąrašu, o ne numatytasis maršrutas, kurį nuolat lopote.

Jei atsakymas ne, užblokuokite

Palikti IPv6 be maršruto nėra tas pats, kas palikti jį ramybėje. Kompiuteris su veikiančiu IPv6 numatytuoju maršrutu toliau jį naudoja, kol tunelis perduoda IPv4, todėl srautas išeina šalia VPN ir kiekviena paslauga, kuri teikia pirmenybę IPv6, mato jūsų tikrąjį adresą. Tai nutekėjimas, ne skaidytas tunelis.

Pasirinkite vieną ir užsirašykite, kurią pasirinkote. Maršrutizuokite numatytąjį ir priimkite aukščiau nurodytus kompromisus, arba išjunkite IPv6 tunelio trukmei. Priešdėlio praleidimas AllowedIPs nepakanka savaime, nes operacinė sistema laiko savo numatytąjį maršrutą. Linux atveju grubi versija yra sysctl -w net.ipv6.conf.all.disable_ipv6=1; subtilesnė versija numeta IPv6 už tunelio ugniasienės taisykle. Telefonų klientai turi aiškų IPv6 blokavimo jungiklį, kuris atlieka tą patį darbą.

Patikrinkite kaip nutekėjimą

Pakelkite tunelį ir skaitykite būseną, o ne pasitikėkite jungikliu. ip -6 route show default turėtų rodyti vieną numatytąjį, o ip -6 route get tikslui už jūsų LAN turėtų įvardyti tunelio įrenginį. Pakartokite abu po atsijungimo: numatytasis, kuris pergyvena tunelį, yra ta klaida, kurios ieškojote.

Tada išbandykite priešingą kryptį. Iš vietinio tinklo kompiuterio pasiekite klientą jo vietiniu IPv6 adresu. Jei tai nustoja veikti, trečioji sąlyga niekada nebuvo įvykdyta, kad ir ką tada teigė maršrutų lentelė.

Užrašykite rezultatą ten, kur jį ras kitas žmogus: kurie priešdėliai lieka vietiniai, kodėl ir ką klientas daro po atsijungimo. Dvi eilutės runbook'e sutaupo kitam inžinieriui laiko, kad nereikėtų vidurnaktį iš naujo atrasti galinio taško kilpos.