IPv6 përmes një tuneli OpenVPN: një xhiro në ruterin e shtëpisë

Laptopi ka një adresë IPv6, tuneli është ngritur mbi IPv4, dhe megjithatë çdo test IPv6 dështon. Ose më keq: testi kalon dhe trafiku doli nëpër rrugën e ofruesit pa hyrë kurrë në tunel. Të dyja rezultatet kthehen në një vendim që mungon: askush nuk i dha rutuesit një prefiks që mund ta rutonte drejt klientëve. Kalimi i rrugës nga klienti nga jashtë zbulon cila pjesë mungon.

Nis nga aty ku është klienti

Shiko klientin përpara se të prekësh serverin. ip -6 addr duhet të tregojë një adresë tuneli nga pishina, dhe ip -6 route duhet të tregojë prefiksin e shtyrë që tregon drejt pajisjes së tunelit. Kur adresa është aty por rruga jo, shtytja mungon ose klienti e ka injoruar. Kur nuk është asnjëra, serveri nuk ka caktuar absolutisht asgjë.

Më pas kontrollo çfarë mendon klienti për botën e jashtme. Një rrugë e paracaktuar përmes tunelit kërkon të gjithë trafikun IPv6, ndërsa një rrugë për 2000::/3 kërkon vetëm unicast global. Të dyja mund të jenë të sakta dhe përgjigjen pyetjeve të ndryshme për rrjedhjen.

Një klient pa asnjë rrugë të paracaktuar IPv6 dështon në çdo test publik, ndërsa vetë tuneli është plotësisht i shëndetshëm. Ky është një boshllëk politike, jo një tunel i prishur.

Kontrollo pishinën që serveri vërtet mund të rutojë

Një server mund të caktojë vetëm nga një prefiks që vërtet e kontrollon. Nëse ofruesi delegon një /56, rezervo një /64 për tunelin dhe lëre pjesën tjetër për LAN. Aty ku ofruesi dorëzon në WAN vetëm një /64 dhe nuk ruton asgjë më tej, lëre prefiksin e LAN në paqe dhe jepi tunelit një interval lokal unik, duke pranuar që klientët nuk do të kenë dalje globale.

Pishina dhe shtytja shkojnë bashkë. server-ipv6 2001:db8:80:10::/64 cakton adresa, dhe push "route-ipv6 2000::/3" u thotë klientëve çfarë të dërgojnë në tunel. Shtytja e 2000::/3 mbulon unicast-in global dhe i lë intervalet link-local dhe multicast jashtë tunelit.

Shkruaj prefiksin e zgjedhur në regjistrin e vendosjes. Kush ndryshon dorëzimin e ofruesit herën tjetër duhet të dijë cilin /64 tuneli tashmë zë.

Aktivizo përcjelljen për familjen e dytë

Përcjellja IPv4 nuk nënkupton përcjellje IPv6. Vendos net.ipv6.conf.all.forwarding=1 dhe pasqyro gjithçka që politika FORWARD e IPv4 tashmë lejon. Në një rutues, zinxhiri FORWARD i të cilit hedh poshtë si parazgjedhje, një grup rregullash që mungon duket saktësisht si një tunel i vdekur.

Shtrëngimi i duarve kalon, klienti merr një adresë dhe prapa nuk kthehet asgjë. Shto rregulla për të dy drejtimet dhe për krahun WAN, sepse një tunel që arrin LAN por jo internetin dështon në testin e tretë. Pas një përpjekjeje të dështuar shiko numëruesit e zinxhirit, sepse një rregull që nuk përputhej kurrë është problem tjetër nga ai që përputhej dhe hidhte poshtë.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Një efekt anësor kap ata që në fund fajësojnë tunelin. Aktivizimi i përcjelljes e bën kernelin të kalojë konfigurimin e adresës përmes Router Advertisement, përveç nëse i thuhet ndryshe, dhe një rrugë e paracaktuar e mësuar kështu zhduket bashkë me të. Ose fikso një rrugë të paracaktuar të qartë në ndërfaqen WAN, ose vendos atje accept_ra në 2 me qëllim. Pas çdo ndryshimi, konfirmo që rutuesi ende ka një rrugë IPv6 të përdorshme nga jashtë përpara se të testosh përsëri klientët.

Përgjigju zbulimit të fqinjëve kur ana e sipërme nuk ruton

Pajisjet e sipërme ndonjëherë e trajtojnë /64 e deleguar si pjesë të lidhjes së tyre dhe refuzojnë të rutojnë çdo nënprefiks drejt kutisë VPN. Kur kjo ndodh, diçka duhet t'u përgjigjet kërkesave të fqinjëve për çdo adresë klienti veç e veç.

OpenVPN e ekspozon adresën e caktuar ndaj një grep client-connect, kështu që regjistrimet mund të ndjekin pishinën e vërtetë në vend të një liste të mbajtur me dorë. Grepi shton ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, dhe një grep client-disconnect që përputhet e heq. Pa heqjen, tabela e proxy-t vjetërohet dhe një klient i mëvonshëm mund të trashëgojë një regjistrim për një adresë që nuk e mori kurrë. Konfirmo gjendjen me ip -6 neigh show proxy.

Trajto proxy-n si një zgjidhje anashkalimi. Një rrugë statike për /64 e tunelit e drejtuar te rutuesi i mbijeton ndryshimeve të klientëve dhe nuk kërkon fare ndonjë grep shell me privilegje.

Ndjek rrugën nga jashtë, hop pas hopi

Testo nga jashtë në tre hapa: së pari adresa e tunelit të rutuesit, pastaj një host LAN dhe së treti një destinacion publik përmes traceroute6. Pishina provohet nga i pari, përcjellja dhe firewalli i LAN nga i dyti, dhe rruga e kthimit përmes anës së sipërme nga i treti. Çdo dështim e ngushton kërkimin në një pajisje të vetme në vend që të rihapë gjithë dizajnin.

Vëzhgo MTU-në e tunelit, sepse rutuesit IPv6 në rrugë nuk do të fragmentojnë për ty. Një MTU shumë e madhe shfaqet si gabim packet-too-big dhe TLS i bllokuar në vend të një dështimi të pastër. Vendose në mënyrë eksplicite dhe testoj me një ngarkesë pranë kufirit.