Jūsų /64 padalijimas nenumaro IPv6 VPN klientams

Klientas rodo visuotinį IPv6 adresą, rankos paspaudimas baigtas, o iš interneto nieko negrįžta. Telkinio nustatymas atrodo teisingas, nes jis teisingas; adresas galioja, ir tunelis jį perneša. Nepavyksta pristatymas, o pristatymas priklauso nuo sprendimo, priimto aukščiau už VPN serverį, kuriam jokia kliento pusės konfigūracija negali turėti įtakos.

Mitas: dalis jūsų /64 jau pasiekiama

Istorija patraukli: serveris turi viešą /64, perpjaukite jį pusiau, kitą pusę atiduokite VPN telkiniui, ir tie klientai jau internete. Prefiksą padalijus tikrai skiriami adresai be susidūrimų. Tačiau tai nekeičia, kaip upstream tinklas nusprendžia, kur turi eiti paketas vienam iš tų adresų.

IPv6 neturi numatytojo vertimo sluoksnio, kuriuo būtų galima remtis, todėl grįžimo kelias turi egzistuoti kaip maršrutizavimas arba kaip pristatymas ryšio lygiu. Paketas, adresuotas kliento tunelio adresui, pasiekia upstream maršrutizatorių, o tas maršrutizatorius priima persiuntimo sprendimą iš savo lentelės. Jei lentelė rodo į fizinį ryšį, paketas eina ten, nepaisant to, ką mano jūsų VPN serveris.

Tai ir yra visa klaida: tiesioginė kryptis veikia, nes ją siunčia jūsų serveris, o grįžimo kryptis miršta vieno šuolio atstumu, nes upstream niekada nesužinojo, kad klientas egzistuoja.

Ko iš tikrųjų reikalauja pristatymas ryšiu

Kai upstream visą /64 laiko esant fiziniame ryšyje, jis kiekvieną paskirties adresą išsprendžia kaimynų aptikimu. Jis siunčia užklausą į tą ryšį ir tikisi, kad adreso savininkas atsakys. VPN klientas už tunelio nėra tame ryšyje ir negali atsakyti, todėl užklausa lieka neatsakyta, o paketas išmetamas.

/65 išpjovimas tos vilties nekeičia. Upstream vis dar laiko diapazoną esant ryšyje, nes vienintelis dalykas, kuris pakeistų jo nuomonę, yra maršrutas arba tarpinis serveris, atsakantis kliento vardu. Niekas iš to neatsiranda todėl, kad redagavote VPN konfigūraciją. Būtent ši spraga paaiškina, kodėl telkinys gali puikiai veikti tarp savo klientų ir vis tiek būti nepasiekiamas iš jokios kitos vietos.

Tarpinių serverių kaimynų aptikimas yra mechanizmas, galintis sujungti abu pasaulius. Tinklų sietuvas atsako į užklausas dėl konkrečių jam priklausančių klientų adresų ir perduoda srautą į tunelį. Tai veikia, ir tai turi būti apribota būtent tais adresais su gyvavimo ciklu, kuris seka telkinį, nes atsakymas už adresą, kurio nebeatliekate, kito asmens srautą paverčia juodąja skyle. Kai kurie upstream nepriims tarpinio serverio atsakymų, kurių nesitikėjo, todėl šiam dizainui reikia ir teikėjo sutikimo.

Ko reikalauja maršrutizuotas pristatymas

Švaresnis dizainas yra paskirstymas, kurį upstream tikrai maršrutizuoja į jūsų tinklų sietuvą. Tai gali būti deleguotas prefiksas arba statinis maršrutas mažesniam blokui, o reikalavimas abiem atvejais tas pats: upstream lentelė turi rodyti į jūsų serverį klientų diapazonui. Tada grįžtamasis srautas pasiekia tinklų sietuvą, ir sietuvas perduoda jį į tunelį.

Maršrutizuotas pristatymas visiškai pašalina kaimynų aptikimo klausimą, todėl verta jo paprašyti teikėjo dar prieš statant ką nors gudraus. Paprašykite maršruto raštu ir patvirtinkite, kad kitas šuolis yra adresas, kurį upstream tikrai gali pasiekti.

Abiem dizainams vis dar reikia įjungto IPv6 persiuntimo tinklų sietuvo ir ugniasienės taisyklių, leidžiančių persiunčiamą srautą abiem kryptimis. Pristatymas yra būtina sąlyga, o ne pakaitalas, likusiam keliui. Veikiantis maršrutas su išjungtu persiuntimu sukuria lygiai tokią pačią tylą kaip ir trūkstamas maršrutas, todėl prieš ką nors pertvarkydami patikrinkite abu.

Du nepriklausomi maršrutai, kuriuos reikia suderinti

Telkinio prefiksas ir paties kliento numatytasis maršrutas yra atskiri nustatymai, o jų painiojimas sukuria dalinį ryšį, kuris atrodo kaip sugedęs tunelis. Telkinys pasakoja serveriui, kuriuos adresus išduoti. Kliento maršrutai nusprendžia, į kurias paskirties vietas klientas apskritai siunčia srautą į tunelį.

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

Aukščiau esantis prefiksas yra dokumentacijos erdvė, o peradresavimas taikomas tik IPv6, o tai yra būtent tai, ko dvigubo kamino diegimas dažnai nori, kol IPv6 pristatymas dar taisomas. IPv4 peradresavimas nesukuria IPv6 aprėpties, ir nė vienas nustatymas neimplikuoja kito.

Išlaikykite IPv6 priklausantį valdymo srautą veikiantį pagal bet kokią taikomą politiką. Packet Too Big pranešimai yra klasikinė ugniasienės, leidžiančios tik TCP ir UDP, auka, o jų išmetimas sukuria ryšius, kurie užmezgami ir tada sustoja didesniuose perdavimuose.

Maršrutizatoriaus skelbimai yra trečioji judanti dalis. Jei tinklų sietuvas pradeda skelbti viršutiniame ryšyje, tai gali pakeisti, ką klientai ir kaimynai mano apie prefiksus ryšyje, o tai gali tyliai panaikinti ką tik dokumentuotą dizainą.

Užrašykite dizainą, kad perstatymas jį atkurtų

Užrašykite tris objektus atskirai: kliento paskirstymą, kliento paskirties maršrutą ir upstream pristatymo būdą paskirstymui. Skaitytojas, turintis visus tris, gali perstatyti diegimą; skaitytojas, turintis tik telkinio nustatymą, atkartos pradinę klaidą.

Tada aiškiai išbandykite grįžimo kryptį su paketu, kuris turi grįžti iš išorės. openvpn(8) vadovas apima parinktis server-ipv6 ir redirect, o jūsų teikėjo maršrutizavimo patvirtinimas apima tą pusę, kurios vadovas negali.