Teie /64 jagamine ei suuna IPv6-t VPN-klientideni

Klient näitab globaalset IPv6-aadressi, käepigistus on lõppenud ja internetist ei tule midagi tagasi. Basseini säte näeb õige välja, sest see on õige; aadress on kehtiv ja tunnel kannab seda. Ebaõnnestub kohaletoimetamine, ja kohaletoimetamine sõltub otsusest, mis on tehtud VPN-serverist kõrgemal ja mida ükski kliendipoolne konfiguratsioon ei saa mõjutada.

Müüt: tükk teie /64-st on juba kättesaadav

Lugu on ahvatlev: serveril on avalik /64, lõigake see pooleks, andke teine pool VPN-i basseinile ja need kliendid on nüüd internetis. Prefiksi jagamine eraldab tõesti aadresse ilma kokkupõrgeteta. See ei muuda aga seda, kuidas upstream-võrk otsustab, kuhu peab minema ühele neist aadressidest adresseeritud pakett.

IPv6-l puudub vaikimisi tõlkekiht, millele toetuda, seega peab tagasitee eksisteerima marsruutimisena või lülitasandi kohaletoimetamisena. Kliendi tunneli aadressile adresseeritud pakett jõuab upstream-ruuterini ja see ruuter teeb edastusotsuse oma tabeli põhjal. Kui tabel osutab füüsilisele lülile, läheb pakett sinna, olenemata sellest, mida teie VPN-server arvab.

See ongi kogu tõrge: edasisuund töötab, sest teie server saadab selle, ja tagasisuund sureb ühe hüppe kaugusel, sest upstream ei saanud kunagi teada, et klient on olemas.

Mida lülil kohaletoimetamine tegelikult nõuab

Kui upstream peab kogu /64-t füüsilisel lülil asuvaks, lahendab see iga sihtaadressi naabrite avastamisega. See saadab sellele lülile päringu ja ootab, et aadressi omanik vastaks. Tunnelis istuv VPN-klient ei ole sellel lülil ega saa vastata, seega päring jääb vastuseta ja pakett visatakse ära.

/65 väljalõikamine ei muuda seda ootust. Upstream kohtleb vahemikku endiselt lülil asuvana, sest ainus, mis muudaks selle meelt, on marsruut või puhverserver, mis vastab kliendi nimel. Kumbki ei ilmu, sest te redigeerisite VPN-konfiguratsiooni. Just see lünk selgitab, miks bassein võib oma klientide vahel suurepäraselt töötada ja olla siiski mujalt kättesaamatu.

Puhverserveri naabrite avastamine on mehhanism, mis võib kaks maailma ühendada. Lüüs vastab päringutele konkreetsete kliendiaadresside kohta, mida ta omab, ja edastab liikluse tunnelisse. See töötab, ja see tuleb piirata täpselt nende aadressidega, mille elutsükkel järgib basseini, sest aadressi eest vastata, mida te enam ei teeninda, muudab kellegi teise liikluse mustaks auguks. Mõned upstreamid ei võta vastu puhverserveri vastuseid, mida nad ei oodanud, seega vajab see disain ka teenusepakkuja nõusolekut.

Mida nõuab marsruuditud kohaletoimetamine

Puhtam lahendus on eraldis, mille upstream tõesti teie lüüsile marsruudib. See võib olla delegeeritud prefiks või väiksema ploki staatiline marsruut, ja nõue on mõlemal juhul sama: upstreami tabel peab kliendivahemiku jaoks osutama teie serverile. Siis jõuab tagasiliiklus lüüsile ja lüüs edastab selle tunnelisse.

Marsruuditud kohaletoimetamine kõrvaldab naabrite avastamise küsimuse täielikult, mistõttu tasub seda teenusepakkujalt küsida enne, kui midagi nutikat ehitada. Küsige marsruuti kirjalikult ja kinnitage, et järgmine hüpe on aadress, millele upstream tõesti ulatub.

Mõlemad lahendused vajavad endiselt lüüsil lubatud IPv6-edastust ja tulemüürireegleid, mis lubavad edastatavat voogu mõlemas suunas. Kohaletoimetamine on eeldus, mitte asendus ülejäänud tee jaoks. Töötav marsruut väljalülitatud edastusega tekitab täpselt sama vaikuse kui puuduv marsruut, seega kontrollige mõlemat enne millegi ümberkujundamist.

Kaks sõltumatut marsruuti, mis tuleb paika saada

Basseini prefiks ja kliendi enda vaikemarsruut on eraldi sätted, ja nende segamine tekitab osalise ühenduvuse, mis näeb välja nagu katkine tunnel. Bassein ütleb serverile, milliseid aadresse välja jagada. Kliendi marsruudid otsustavad, millistesse sihtkohtadesse klient üldse tunnelisse liiklust saadab.

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

Ülaltoodud prefiks on dokumentatsiooniruum ja ümbersuunamine kehtib ainult IPv6-le, mis on täpselt see, mida kahe virna juurutus sageli tahab, kuni IPv6 kohaletoimetamine on veel parandamisel. IPv4 ümbersuunamine ei loo IPv6 katvust ja kumbki säte ei eelda teist.

Hoidke juhtimisliiklus, millest IPv6 sõltub, töös ükskõik millise poliitika korral. Packet Too Big sõnumid on klassikaline ohver tulemüürist, mis lubab ainult TCP-d ja UDP-d, ja nende äraviskamine tekitab ühendusi, mis luuakse ja seejärel takerduvad suuremate ülekannete juures.

Ruuteriteated on kolmas liikuv osa. Kui lüüs hakkab üleslülil teatama, võib see muuta seda, mida kliendid ja naabrid lülil olevate prefiksite kohta arvavad, mis võib vaikselt tühistada just dokumenteeritud lahenduse.

Kirjutage lahendus üles, et ülesehitamine selle taastoodaks

Kirjutage kolm objekti eraldi üles: kliendi eraldamine, kliendi sihtkoha marsruut ja upstreami kohaletoimetamise meetod eraldamise jaoks. Lugeja, kellel on kõik kolm, saab juurutuse uuesti üles ehitada; lugeja, kellel on ainult basseini säte, taastoodab algse vea.

Seejärel testige tagasisuunda selgesõnaliselt paketiga, mis peab väljastpoolt tagasi tulema. openvpn(8) käsiraamat hõlmab valikuid server-ipv6 ja redirect, ja teie teenusepakkuja marsruutimise kinnitus katab selle poole, mida käsiraamat ei suuda.