Ĉu IPv6-trafiko iru tra la VPN aŭ rekte?

Du homoj petis min pasintmonate pri kontraŭaj rezultoj: unu volis, ke IPv6 estu kovrita de la VPN, la alia volis, ke la oficeja printilo daŭre funkciu. Unu sola itinero ::/0 ne povas liveri ambaŭ memstare. Ĉu tiu itinero apartenas ene de la tunelo dependas de tri kondiĉoj, kaj la unua ekskludas ĝin por la plej multaj komercaj elirejoj. Se la elirejo ne portas IPv6, enkursigi la defaŭltan itinieron en ĝin kaŝas vian trafikon en tunelo, kiu havas nenie por sendi ĝin.

Tri kondiĉoj decidas la respondon

La defaŭlta itinero estas unu linio, ::/0, kaj ĝi kongruas kun ĉiu IPv6-celo sen pli specifa itinero (RFC 4291). Instali ĝin estas facile. Decidi, ĉu vi devus, reduktiĝas al tri kondiĉoj.

Kondiĉo unu: la elirejo, al kiu vi konektiĝas, havas funkciantan IPv6 kaj pretas plusendi ĝin. Kondiĉo du: via kliento povas konservi vojon al la tunela finpunkto, kiu kutime kuŝas ene de la gamo, kiun vi baldaŭ enkursigos. Kondiĉo tri: vi povas nomi la lokajn IPv6-celojn, kiuj devas resti ekster la tunelo.

Ĉiu kondiĉo malsukcesas laŭ sia maniero, tial divenado kostas tutan vesperon. Malsukcesinta kondiĉo unu donas al vi silenton kaj itinertabelon, kiu aspektas ĝusta. Malsukcesinta kondiĉo du mortigas la manpremon kelkajn sekundojn post ĝia komenco. Malsukcesinta kondiĉo tri lasas funkciantan tunelon kaj malfeliĉan kolegon ĉe la printilo.

Ĉu la elirejo efektive portas IPv6?

Tunela interfaco kun IPv6-adreso pruvas nenion pri la alia flanko. Multaj komercaj profiloj estas interne nur IPv4: la servilo donas al vi v4-adreson kaj forĵetas ĉion alian. Instalu defaŭltan itinieron el AllowedIPs supre de tio, kaj la kerno volonte sendos IPv6 en interfacon, kies kontraŭulo neniam vidas ĝin.

Testu de la kliento dum la tunelo estas aktiva. ping -6 -c 3 2001:4860:4860::8888 kaj ip -6 route get 2001:4860:4860::8888 respondas malsamajn demandojn: ĉu respondo revenas, kaj kiun aparaton la kerno elektis. Kiam la dua nomas vian tunelon kaj la unua redonas nenion, la problemo estas la elirejo, ne la itinero.

Se vi mem administras la elirejon, la klienta testo povas sukcesi kaj la vojo tamen finiĝi en sakstrato. Konfirmu net.ipv6.conf.all.forwarding=1 sur la pordego kaj ke ĝia fajrmuro akceptas pakaĵojn plusenditajn el la tunelo. Ĝuste enkursigita pakaĵo en elirejon, kiu rifuzas plusendi, aspektas de la klienta flanko precize kiel enkursiga cimo.

Ĉu la kliento povas konservi sian vojon al la finpunkto?

Jen la kazo, kiu kaptis min sur tekkomputilo kun nur-IPv6 WireGuard-finpunkto. La adreso de la finpunkto estas ordinara tutmonda adreso, do ĝi falas ene de ::/0. Enkursigu la tutan prefikson en la interfacon, kaj la manpremaj pakaĵoj ĉasos sin mem en la tunelon, kiun ili ankoraŭ provas konstrui. La tunelo neniam leviĝas, kaj nenio en la eligo de la kliento diras kial.

wg-quick traktas tion sur Linukso. Ĝi derivas itinerojn el AllowedIPs, instalas ilin en sian propran tabelon kaj aldonas politikan regulon, por ke trafiko al la finpunkto unue solviĝu tra la ĉefa tabelo: la regulo suppress_prefixlength 0, kiun vi trovas en ip -6 rule. Tial wg-quick up sukcesas tie, kie permane skribita ip -6 route add default dev wg0 fortranĉas vin.

Kontrolu ambaŭ statojn per ip -6 route get <endpoint-v6>, antaŭ kaj post levi la tunelon. Se la respondo ŝanĝiĝas al via tunela aparato, vi forigis la vojon, kiun la tunelo bezonas. Kiam vi mem skribas la itinerojn, aldonu gastigan itinieron al la finpunkto tra la origina pordego, aŭ konektiĝu al la finpunkto per IPv4 kaj lasu IPv6 al la ŝarĝo.

Kio devas resti ekster la tunelo?

Pli specifaj itineroj venkas la defaŭltan, do surliga prefikso aŭ ULA-gamo kun propra itinero daŭre funkcias sen plia peno. Tio estas la kvieta kialo, ke tiom da plentunelaj IPv4-agordoj postvivas: la LAN-prefiksoj estas pli specifaj ol la defaŭlta kaj neniam eniras la tunelon.

Ĝi rompiĝas, kiam loka aparato estas atingebla per tutmonda adreso, kio normalas por printilo ricevinta publikan prefikson de la sama enkursigilo, NAS aŭ televido. Tiuj adresoj kongruas kun ::/0 kaj nenio alia, do ili translokiĝas en la tunelon kun ĉio alia kaj malaperas.

Decidu laŭ celo, ne laŭ protokolo. Se du aŭ tri lokaj gastigantoj gravas, donu al iliaj prefiksoj itinieron ekster la fizika interfaco, aŭ forigu ilin el la intertraktita aro. Se la listo daŭre kreskas, la honesta respondo estas split tunneling por IPv6 kun skribita listo de esceptoj, ne defaŭlta itinero, kiun vi senĉese flikas.

Se la respondo estas ne, bloku ĝin

Lasi IPv6 sen itinero ne samas kiel lasi ĝin trankvila. Gastiganto kun funkcianta IPv6-defaŭlto daŭre uzas ĝin dum la tunelo portas IPv4, do la trafiko eliras apud la VPN kaj ĉiu servo, kiu preferas IPv6, vidas vian veran adreson. Tio estas liko, ne split-tunelo.

Elektu unu kaj skribu, kiun vi elektis. Enkursigu la defaŭltan kaj akceptu la kompromisojn supre, aŭ malŝaltu IPv6 dum la daŭro de la tunelo. Forlasi la prefikson el AllowedIPs ne sufiĉas sola, ĉar la operaciumo konservas sian propran defaŭlton. Sur Linukso la maldelikata versio estas sysctl -w net.ipv6.conf.all.disable_ipv6=1; la pli fajna faligas IPv6 ekster la tunelon per fajrmura regulo. Telefonaj klientoj havas eksplicitan blok-IPv6-ŝaltilon, kiu faras la saman laboron.

Kontrolu ĝin kiel likon

Levu la tunelon kaj legu la staton anstataŭ fidi la ŝaltilon. ip -6 route show default devus montri unu defaŭlton, kaj ip -6 route get por celo ekster via LAN devus nomi la tunelan aparaton. Ripetu ambaŭ post malkonekto: defaŭlto, kiu postvivas la tunelon, estas la cimo, kiun vi serĉis.

Poste testu la alian direkton. De gastiganto en la loka reto, atingi la klienton per ĝia loka IPv6-adreso. Se tio ĉesas funkcii, kondiĉo tri neniam estis plenumita, kion ajn la itinertabelo tiam asertis.

Skribu la rezulton tie, kie la sekva persono trovos ĝin: kiuj prefiksoj restas lokaj, kial, kaj kion la kliento faras post malkonekto. Du linioj en runbook ŝparas al la sekva inĝeniero retrovon de la finpunkta buklo noktomeze.