Ndarja e /64-së tuaj nuk rrugëzon IPv6 drejt klientëve të VPN

Klienti shfaq një adresë globale IPv6, shtrëngimi i duarve ka përfunduar dhe asgjë nuk kthehet nga interneti. Cilësimi i grupit duket i saktë sepse është i saktë; adresa është e vlefshme dhe tuneli e mbart atë. Ajo që dështon është dorëzimi, dhe dorëzimi varet nga një vendim i marrë mbi serverin VPN të cilin asnjë konfigurim nga ana e klientit nuk mund ta ndikojë.

Miti: një pjesë e /64-së tuaj është tashmë e arritshme

Historia është tërheqëse: serveri ka një /64 publike, prisni atë në dysh, jepni gjysmën tjetër grupit të VPN, dhe ata klientë tani janë në internet. Ndarja e parashtesës vërtet cakton adresa pa përplasje. Por nuk ndryshon mënyrën se si rrjeti upstream vendos ku duhet të shkojë një paketë për një nga ato adresa.

IPv6 nuk ka një shtresë standarde përkthimi ku të mbështetet, prandaj rruga e kthimit duhet të ekzistojë si rrugëzim ose si dorëzim në nivel lidhjeje. Një paketë e adresuar drejt adresës së tunelit të një klienti arrin në ruterin upstream, dhe ai ruter merr një vendim përcjelljeje nga tabela e tij. Nëse tabela tregon lidhjen fizike, paketa shkon atje, pavarësisht nga ajo që beson serveri juaj VPN.

Ky është i gjithë dështimi: drejtimi përpara funksionon sepse serveri juaj e dërgon, dhe drejtimi i kthimit vdes një kërcim larg sepse upstream nuk mësoi kurrë se klienti ekziston.

Çfarë kërkon vërtet dorëzimi në lidhje

Kur upstream e konsideron të gjithë /64-në si të vendosur në lidhjen fizike, zgjidh çdo adresë destinacioni me zbulimin e fqinjëve. Dërgon një kërkesë në atë lidhje dhe pret që pronari i adresës të përgjigjet. Një klient VPN pas një tuneli nuk është në atë lidhje dhe nuk mund të përgjigjet, prandaj kërkesa mbetet pa përgjigje dhe paketa hidhet.

Prerja e një /65 nuk e ndryshon atë pritshmëri. Upstream vazhdon ta trajtojë intervalin si në lidhje, sepse e vetmja gjë që do t'i ndryshonte mendjen është një rrugë ose një proxy që përgjigjet në emër të klientit. Asnjëra nuk shfaqet sepse keni redaktuar një konfigurim VPN. Pikërisht ky hendek shpjegon pse një grup mund të funksionojë në mënyrë të përsosur midis klientëve të vet dhe gjithsesi të jetë i paarritshëm nga kudo tjetër.

Zbulimi i fqinjëve përmes proxy është mekanizmi që mund të lidhë dy botët. Porta përgjigjet kërkesave për adresat specifike të klientëve që zotëron dhe përcjell trafikun në tunel. Funksionon, dhe duhet të kufizohet saktësisht në ato adresa me një cikël jete që ndjek grupin, sepse përgjigjja për një adresë që nuk e shërbeni më e kthen trafikun e dikujt tjetër në një vrimë të zezë. Disa upstream nuk do të pranojnë përgjigje proxy që nuk i kishin pritur, prandaj ky dizajn kërkon edhe miratimin e ofruesit.

Çfarë kërkon dorëzimi i rrugëzuar

Dizajni më i pastër është një caktim që upstream e rrugëzon vërtet drejt portës tuaj. Mund të jetë një parashtesë e deleguar ose një rrugë statike për një bllok më të vogël, dhe kërkesa është e njëjtë në të dyja rastet: tabela e upstream duhet të tregojë serverin tuaj për intervalin e klientëve. Pastaj trafiku i kthimit arrin në portë dhe porta e përcjell atë në tunel.

Dorëzimi i rrugëzuar e eliminon plotësisht çështjen e zbulimit të fqinjëve, prandaj ia vlen t'i kërkosh ofruesit përpara se të ndërtosh diçka të zgjuar. Kërkoni rrugën me shkrim dhe konfirmoni se kërcimi tjetër është adresa që upstream vërtet mund ta arrijë.

Të dyja dizajnet ende kanë nevojë për përcjellje IPv6 të aktivizuar në portë dhe rregulla të firewall-it që lejojnë rrjedhën e përcjellë në të dy drejtimet. Dorëzimi është një parakusht, jo një zëvendësues, për pjesën tjetër të rrugës. Një rrugë funksionale me përcjelljen e çaktivizuar prodhon saktësisht të njëjtin heshtje si një rrugë që mungon, prandaj kontrolloni të dyja përpara se të ridizajnoni çdo gjë.

Dy rrugë të pavarura për t'i bërë mirë

Parashtesa e grupit dhe rruga standarde e vetë klientit janë cilësime të ndara, dhe ngatërrimi i tyre prodhon lidhshmëri të pjesshme që duket si një tunel i prishur. Grupi i thotë serverit cilat adresa të ndajë. Rrugët e klientit vendosin drejt cilave destinacione klienti dërgon trafik në tunel.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Parashtesa më sipër është hapësirë dokumentacioni, dhe ridrejtimi vlen vetëm për IPv6, që është pikërisht ajo që shpesh kërkon një vendosje me dy shtresa ndërsa dorëzimi IPv6 është ende duke u rregulluar. Një ridrejtim IPv4 nuk vendos mbulim IPv6, dhe asnjëri prej cilësimeve nuk nënkupton tjetrin.

Mbajeni trafikun e kontrollit nga i cili varet IPv6 duke funksionuar nën çdo politikë që aplikoni. Mesazhet Packet Too Big janë viktima klasike e një firewall-i që lejon vetëm TCP dhe UDP, dhe hedhja e tyre prodhon lidhje që vendosen dhe më pas ngecin në transferime më të mëdha.

Shpalljet e ruterit janë pjesa e tretë lëvizëse. Nëse porta fillon të shpallë në lidhjen e sipërme, mund të ndryshojë atë që klientët dhe fqinjët besojnë për parashtesat në lidhje, gjë që mund të anulojë në heshtje dizajnin që sapo dokumentuat.

Regjistroni dizajnin që një rindërtim ta riprodhojë

Shkruani tre objekte veçmas: caktimin e klientit, rrugën e destinacionit të klientit dhe metodën e dorëzimit të upstream për caktimin. Një lexues që i ka të treja mund të rindërtojë vendosjen; një lexues që ka vetëm cilësimin e grupit do të riprodhojë gabimin origjinal.

Pastaj provoni drejtpërdrejt drejtimin e kthimit, me një paketë që duhet të kthehet nga jashtë. Manuali i openvpn(8) mbulon opsionet server-ipv6 dhe redirect, dhe konfirmimi i rrugëzimit nga ofruesi juaj mbulon gjysmën që manuali nuk mundet.