/64 zatitzeak ez ditu IPv6 VPN bezeroengana bideratzen

Bezeroak IPv6 helbide globala erakusten du, eskuko ukipena osatu da, eta ezer ez da itzultzen internetetik. Poolaren ezarpena zuzena dirudi zuzena delako; helbidea baliozkoa da eta tunelak eramaten du. Huts egiten duena entrega da, eta entrega VPN zerbitzariaren gainetik hartutako erabaki baten mende dago, eta bezeroaren aldeko konfigurazio batek ere ezin du eragin.

Mitoa: zure /64 zati bat jada iristeko modukoa da

Istorioa erakargarria da: zerbitzariak /64 publiko bat du, erdibanatu, beste erdia VPN poolari eman, eta bezero horiek orain interneten daude. Prefijoak zatitzeak talkarik gabeko helbideak esleitzen ditu. Baina ez du aldatzen upstream sareak helbide horietako baterako pakete bat norantz joan behar den erabakitzen duen modua.

IPv6-k ez du itzultzeko geruza lehenetsirik, beraz itzulera-bideak bideratze gisa edo esteka mailako entrega gisa existitu behar du. Bezero baten tunel helbidera zuzendutako paketea upstream bideratzailera iristen da, eta bideratzail horrek bere taulatik aurreraeramateko erabakia hartzen du. Taulak esteka fisikora seinalatzen badu, paketea hara doa, zure VPN zerbitzariak zer pentsatzen duen edozein dela ere.

Hori da huts egite osoa: aurreranzko norabidea funtzionatzen du zure zerbitzariak bidaltzen duelako, eta atzeranzko norabidea jauzi bakarrera hiltzen da upstream-ak inoiz ez zuelako jakin bezeroa existitzen denik.

Zer eskatzen duen estekako entrega-ak benetan

Upstream-ak /64 osoa esteka fisikoan dagoela uste duenean, helmuga-helbide bakoitza bizilagunen aurkikuntzaz ebazten du. Esteka horretan eskaera bat bidaltzen du eta helbidearen jabeak erantzutea espero du. Tunel baten atzean dagoen VPN bezeroa ez dago esteka horretan eta ezin du erantzun, beraz eskaera erantzunik gabe geratzen da eta paketea baztertu egiten da.

/65 bat mozterik ez du itxaropen hori aldatzen. Upstream-ak barrutia estekan dagoen bezala tratatzen jarraitzen du, bere iritzia aldatuko lukeen gauza bakarra bezeroaren izenean erantzuten duen bide edo proxy bat delako. Bat ere ez da agertzen VPN konfigurazio bat editatu duzulako. Hutsune horrek azaltzen du zergatik pool batek bere bezeroen artean primeran funtziona dezakeen eta hala ere beste inondik iristezina izan.

Proxy bizilagunen aurkikuntza bi munduak zubiratu ditzakeen mekanismoa da. Ateak berak dituen bezero-helbide zehatzetarako eskaerei erantzuten die eta trafikoa tunelera birbidaltzen du. Funtzionatzen du, eta helbide horietara zehazki mugatu behar da poolari jarraitzen dion bizitza-ziklo batekin, zerbitzatzen ez duzun helbide baten izenean erantzuteak beste norbaiten trafikoa zulo beltz bihurtzen duelako. Upstream batzuek ez dituzte espero ez zituzten proxy erantzunak onartuko, beraz diseinu honek hornitzailearen adostasuna ere behar du.

Zer eskatzen duen entrega bideratuak

Diseinu garbiagoa upstream-ak zure ateraino benetan bideratzen duen esleipena da. Delegatutako prefijo bat edo bloke txikiago baterako bide estatiko bat izan daiteke, eta baldintza bera da bi kasuetan: upstream-aren taulak zure zerbitzaria seinalatu behar du bezeroen barrutirako. Orduan itzulera-trafikoa ateraino iristen da eta ateak tunelera birbidaltzen du.

Entrega bideratuak bizilagunen aurkikuntzaren gaia erabat ezabatzen du, eta horregatik merezi du hornitzaileari hura eskatzea zerbait adimentsua eraiki aurretik. Eskatu bidea idatziz, eta egiaztatu hurrengo jauzia upstream-ak benetan irits dezakeen helbidea dela.

Bi diseinuek IPv6 aurreraeramatea gaituta behar dute atean eta bi norabideetan birbidalitako fluxua onartzen duten suebaki arauak. Entrega aurrebaldintza bat da, ez ordezko bat, bidearen gainerakoarentzat. Aurreraeramatea desaktibatuta duen bide funtzional batek falta den bide baten isiltasun bera sortzen du, beraz egiaztatu biak ezer berridatzi aurretik.

Asmatu beharreko bi bide independente

Poolaren prefijoak eta bezeroaren bere bide lehenetsiak ezarpen bereiziak dira, eta haiek nahasteak tunel hautsia dirudien konektibitate partziala sortzen du. Poolak zerbitzariari esaten dio zein helbide banatu. Bezeroaren bideek erabakitzen dute bezeroak zein helmugatara bidaltzen duen trafikoa tunelera, batere bidaltzen badu.

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

Goiko prefijoa dokumentazio-espazioa da, eta birbideratzea IPv6ri soilik aplikatzen zaio, hau da, pila bikoitzeko inplementazio batek sarritan nahi duena IPv6 entrega oraindik konpontzen ari den bitartean. IPv4 birbideratzeak ez du IPv6 estaldura ezartzen, eta bi ezarpenek ez dute bestea suposatzen.

Mantendu IPv6-k behar duen kontrol-trafikoa funtzionatzen aplikatzen duzun politika edozein dela ere. Packet Too Big mezuak TCP eta UDP soilik onartzen dituen suebaki baten biktima klasikoa dira, eta haiek baztertzeak ezartzen diren eta gero transferentzia handiagoetan trabatzen diren konexioak sortzen ditu.

Bideratzailearen iragarkiak hirugarren pieza mugikorra dira. Ateak uplink-ean iragartzen hasten bada, bezeroek eta bizilagunek estekako prefijoei buruz dutena alda dezake, eta horrek isilka desegin dezake oraintxe dokumentatu duzun diseinua.

Erregistratu diseinua berreraikitze batek erreproduzi dezan

Idatzi hiru objektu bereizita: bezeroaren esleipena, bezeroaren helmuga-bidea eta upstream-aren esleipenaren entrega-metodoa. Hirurak dituen irakurleak inplementazioa berreraiki dezake; poolaren ezarpena soilik duen irakurleak jatorrizko errorea erreproduzituko du.

Ondoren probatu atzeranzko norabidea espresuki, kanpotik itzuli behar duen pakete batekin. openvpn(8) eskuliburuak server-ipv6 eta redirect aukerak jasotzen ditu, eta zure hornitzailearen bideratze-berrespenak eskuliburuak ezin duen erdia jasotzen du.