Kugawanya /64 yako hakuongozi IPv6 kwa wateja wa VPN

Mteja anaonyesha anwani ya kimataifa ya IPv6, makubaliano ya mkono yamekamilika, na hakuna kinachorudi kutoka mtandao. Mpangilio wa pool unaonekana sahihi kwa sababu ni sahihi; anwani ni halali na handaki inaibeba. Kinachoshindikana ni uwasilishaji, na uwasilishaji unategemea uamuzi uliofanywa juu ya seva ya VPN ambao hakuna usanidi wa upande wa mteja unaoweza kuathiri.

Hadithi potofu: sehemu ya /64 yako tayari inafikika

Hadithi inavutia: seva ina /64 ya umma, igawanye katikati, ipe nusu nyingine pool ya VPN, na wateja hao sasa wako mtandaoni. Kugawanya kiambishi awali hutenga anwani bila migongano. Lakini hakubadilishi jinsi mtandao wa upstream unaamua pakiti ya mmoja wa anwani hizo inapaswa kwenda wapi.

IPv6 haina tabaka la tafsiri la chaguo-msingi la kutegemea, kwa hivyo njia ya kurudi lazima iwepo kama uelekezaji au kama uwasilishaji wa ngazi ya kiungo. Pakiti iliyoelekezwa kwa anwani ya handaki ya mteja inafika kwa kipanga njia cha upstream, na kipanga njia hicho hufanya uamuzi wa usambazaji kutoka jedwali lake mwenyewe. Ikiwa jedwali linaelekeza kwenye kiungo halisi, pakiti huenda huko, bila kujali seva yako ya VPN inaamini nini.

Hiyo ni kushindikana kote: mwelekeo wa mbele hufanya kazi kwa sababu seva yako inaituma, na mwelekeo wa kurudi hufa hatua moja mbali kwa sababu upstream hakuwahi kujua kwamba mteja yuko.

Uwasilishaji kwenye kiungo unahitaji nini kwa kweli

Wakati upstream inachukulia /64 yote iko kwenye kiungo halisi, hutatua kila anwani ya lengwa kwa ugunduzi wa majirani. Hutuma ombi kwenye kiungo hicho na inatarajia mmiliki wa anwani ajibu. Mteja wa VPN aliye nyuma ya handaki hayuko kwenye kiungo hicho na hawezi kujibu, kwa hivyo ombi linabaki bila jibu na pakiti hutupwa.

Kukata /65 hakubadilishi matarajio hayo. Upstream bado inachukulia safu hiyo kama iko kwenye kiungo, kwa sababu kitu pekee kitakachobadilisha mawazo yake ni njia au proksi inayojibu kwa niaba ya mteja. Hakuna kinachoonekana kwa sababu ulihariri usanidi wa VPN. Pengo hilo ndilo linaloeleza kwa nini pool inaweza kufanya kazi kikamilifu kati ya wateja wake wenyewe na bado isifikike kutoka mahali popote pengine.

Ugunduzi wa majirani kwa proksi ndiyo utaratibu unaoweza kuunganisha dunia mbili. Lango hujibu maombi ya anwani mahususi za wateja ambazo linamiliki na husambaza trafiki ndani ya handaki. Inafanya kazi, na lazima iwekewe mipaka hasa kwa anwani hizo kwa mzunguko wa maisha unaofuata pool, kwa sababu kujibu kwa anwani usiyoitumikia tena hugeuza trafiki ya mtu mwingine kuwa shimo jeusi. Baadhi ya upstream haitakubali majibu ya proksi ambayo hayakutarajia, kwa hivyo muundo huu unahitaji pia idhini ya mtoa huduma.

Uwasilishaji wa uelekezaji unahitaji nini

Muundo safi zaidi ni mgao ambao upstream inauelekeza kweli kwenye lango lako. Unaweza kuwa kiambishi awali kilichokabidhiwa au njia tuli kwa kizuizi kidogo, na hitaji ni sawa katika hali zote mbili: jedwali la upstream lazima lielekeze kwenye seva yako kwa safu ya wateja. Kisha trafiki ya kurudi inafika kwenye lango na lango huisambaza ndani ya handaki.

Uwasilishaji wa uelekezaji huondoa kabisa swali la ugunduzi wa majirani, ndiyo sababu inafaa kuiomba mtoa huduma kabla ya kujenga kitu chochote cha werevu. Omba njia kwa maandishi, na uthibitisha kwamba hatua inayofuata ni anwani ambayo upstream inaweza kuifikia kweli.

Miundo yote miwili bado inahitaji usambazaji wa IPv6 umewashwa kwenye lango na kanuni za firewall zinazoruhusu mtiririko uliosambazwa katika pande zote mbili. Uwasilishaji ni sharti, si mbadala, kwa sehemu iliyobaki ya njia. Njia inayofanya kazi na usambazaji umezimwa hutoa ukimya sawa kabisa na njia iliyokosekana, kwa hivyo angalia zote mbili kabla ya kubuni upya chochote.

Njia mbili huru zinazopaswa kuwekwa sawa

Kiambishi awali cha pool na njia chaguo-msingi ya mteja mwenyewe ni mipangilio tofauti, na kuzichanganya hutoa muunganisho wa sehemu unaoonekana kama handaki iliyovunjika. Pool inaiambia seva anwani zipi zigawanywe. Njia za mteja huamua ni maeneo gani mteja anapeleka trafiki ndani ya handaki.

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

Kiambishi awali kilicho juu ni nafasi ya nyaraka, na uelekezaji upya unahusu IPv6 pekee, ambayo ndiyo hasa ambayo usambazaji wa tabaka mbili mara nyingi hutaka wakati uwasilishaji wa IPv6 bado unarekebishwa. Uelekezaji upya wa IPv4 hauanzishi ufunikaji wa IPv6, na hakuna mpangilio unaodokeza mwingine.

Weka trafiki ya udhibiti ambayo IPv6 inategemea ikiwa inafanya kazi chini ya sera yoyote unayotumia. Ujumbe wa Packet Too Big ni mwathirika wa kawaida wa firewall inayoruhusu TCP na UDP pekee, na kuzitupa hutoa miunganisho inayojengwa kisha kukwama kwenye uhamishaji mkubwa.

Matangazo ya kipanga njia ni sehemu ya tatu inayosonga. Ikiwa lango litaanza kutangaza kwenye kiungo cha juu, inaweza kubadilisha kile wateja na majirani wanachokiamini kuhusu viambishi awali kwenye kiungo, jambo ambalo linaweza kubatilisha kimyakimya muundo uliouandika hivi punde.

Rekodi muundo ili ujenzi upya uuzalishie upya

Andika vitu vitatu kando: mgao wa mteja, njia ya lengo la mteja, na mbinu ya uwasilishaji ya upstream kwa mgao huo. Msomaji aliye na vyote vitatu anaweza kujenga upya usambazaji; msomaji aliye na mpangilio wa pool pekee atazalisha upya hitilafu ya awali.

Kisha jaribu mwelekeo wa kurudi kwa uwazi, kwa pakiti ambayo lazima irudi kutoka nje. Mwongozo wa openvpn(8) unashughulikia chaguo za server-ipv6 na redirect, na uthibitisho wa uelekezaji kutoka kwa mtoa huduma wako unashughulikia nusu ambayo mwongozo hauwezi.