IPv4 VPN સર્વર દ્વારા IPv6 હજી પણ અલગ IPv6 એક્ઝિટ માંગે છે

ટ્યુનલ ઉપર આવે છે, ક્લાયન્ટને પૂલમાંથી IPv6 સરનામું મળે છે, અને તો પણ દરેક IPv6 ગંતવ્યનો સમય પૂરો થઈ જાય છે. ટ્યુનલમાં કંઈ તૂટેલું નથી: IPv6 સંપૂર્ણ સારી રીતે IPv4 પરિવહનની અંદર ચાલે છે, અને તે ક્યારેય મુશ્કેલ ભાગ ન હતો. તેં આપેલું સરનામું એવું વચન છે જે સર્વર પાળી શકતું નથી, કારણ કે એક્ઝિટ પાસે કોઈ IPv6 અપસ્ટ્રીમ નથી જ્યાં તેને મોકલી શકાય. સુધારો એક્ઝિટ પર થવો જોઈએ, ક્લાયન્ટ પ્રોફાઇલમાં નહીં.

લક્ષણ: સરનામું છે, માર્ગ નથી

ક્લાયન્ટ બાજુની ચકાસણી ટ્યુનલ ઉપકરણ પર વૈશ્વિક દેખાતું IPv6 સરનામું અને તેની તરફ નિર્દેશ કરતો રૂટ દર્શાવે છે, તેથી આને ભૂલથી ક્લાયન્ટની ખામી તરીકે વાંચવામાં આવે છે. ટ્રાફિક ટ્યુનલમાં પ્રવેશે છે, સર્વર તેને ડીકેપ્સ્યુલેટ કરે છે, અને પછી પેકેટ એવા હોસ્ટ પર પહોંચે છે જેની રૂટિંગ કોષ્ટકમાં કોઈપણ વાસ્તવિક જગ્યા તરફ IPv6 ડિફોલ્ટ રૂટ નથી. સ્ટેકના આધારે તમને તાત્કાલિક અપ્રાપ્યતા કે શાંત ડ્રોપ મળે છે, અને બંને સ્થિતિમાં ક્લાયન્ટ ફાયરવોલ જેવો જ દેખાતો સમય-સમાપ્તિ જુએ છે.

ક્લાયન્ટને અડકતા પહેલાં સર્વરનું પોતાનું રૂટિંગ કોષ્ટક વાંચો, કારણ કે માર્ગનો ખૂટતો અડધો ભાગ ત્યાં જ રહે છે. એક IPv4 ડિફોલ્ટ રૂટ ધરાવતું સર્વર તમને જવાબ પહેલેથી આપી ચૂક્યું છે.

ડીકેપ્સ્યુલેશન પછી પેકેટને અનુસરો

ટ્યુનલની અંદર પેકેટ સામાન્ય IPv6 છે અને તેનો સ્રોત ક્લાયન્ટનું સરનામું છે. સર્વર પરિવહન એન્કેપ્સ્યુલેશન ઉતારી લે છે અને પછી એક મૂળ IPv6 પેકેટ પકડી રાખે છે જેને આગલા IPv6 હોપ પર મોકલવું પડે. IPv4 ડિફોલ્ટ રૂટ તેને વહન કરી શકતો નથી, અને તેને IPv4માં અનુવાદિત કરવું એ બીજું કાર્ય છે જે કોઈએ તૈનાત કર્યું નથી. આખી નિષ્ફળતા એ જ છે, અને VPN સાંભળનારાએ IPv4 પર જવાબ આપ્યો હતો કે નહીં તેની સાથે તેનો કોઈ સંબંધ નથી.

IPv4 પર IPv6 એન્કેપ્સ્યુલેશનની કાર્યપદ્ધતિ RFC 4213માં વર્ણવેલી છે, અને ત્યાંની મહત્ત્વની વિગત એ છે કે અંતિમ બિંદુઓને હજી પણ ટ્યુનલની બીજી બાજુએ સાચી IPv6 કનેક્ટિવિટી જોઈએ. હેડર લપેટવાથી અપસ્ટ્રીમ જાદુથી ઉત્પન્ન થતું નથી.

બે ટ્યુનલ સ્તર, બે સ્વતંત્ર ચકાસણી

દરેક સ્તરને અલગથી ચકાસો, કારણ કે કામ કરતું બાહ્ય ટ્યુનલ તૂટેલું આંતરિક ટ્યુનલ છુપાવે છે. ક્લાયન્ટથી સર્વર સુધી IPv4 પિંગથી બાહ્ય માર્ગ ચકાસો અને તમે વાપરો છો તે પોર્ટની પુષ્ટિ કરો. પછી સર્વર પર આંતરિક માર્ગ ચકાસો, જ્યાં ip -6 route ડિફોલ્ટ કે વાસ્તવિક અપસ્ટ્રીમથી શીખેલો ચોક્કસ રૂટ દર્શાવવો જોઈએ, અને ip -6 addr એવું સ્રોત પ્રીફિક્સ દર્શાવવું જોઈએ જે અપસ્ટ્રીમ સ્વીકારે. તેનાથી ઓછું કંઈ પણ ઇન્ટરફેસ પરનું શણગાર છે.

એક અનન્ય-સ્થાનિક સરનામું, અથવા વૈશ્વિક દેખાતું પ્રીફિક્સ જેની તરફ કંઈ પાછું રૂટ થતું નથી, ખુશીથી ઇન્ટરફેસ પર દેખાશે અને ક્યાંય નહીં જાય. જાહેર પહોંચ અપસ્ટ્રીમ આપે છે, સરનામાનો આકાર નહીં.

તે જ ક્લાયન્ટ પર લાગુ પડે છે: ip -6 route get 2001:4860:4860::8888 ટ્યુનલ ઉપકરણનું નામ આપવું જોઈએ, અને જો તે ભૌતિક ઉપકરણનું નામ આપે, તો ક્લાયન્ટ IPv6 માટે VPN બિલકુલ વાપરતું નથી.

સ્રોત પ્રીફિક્સ, કદ અને ICMPv6

અપસ્ટ્રીમને પૂછો કે તે ફોરવર્ડિંગ માટે કયા સ્રોત પ્રીફિક્સ સ્વીકારશે, અને તેમાંથી એક ક્લાયન્ટ પૂલ માટે વાપરો. જે પ્રદાતા તમને સર્વરના પોતાના ઇન્ટરફેસ માટે /64 આપે છે તે જરૂરી નથી કે તમને બીજું /64 કે મોટો બ્લોક રૂટ કરે, અને આ તફાવત એક બપોરનું ડિબગિંગ છે જે સપોર્ટ ટિકિટ એક પ્રશ્નમાં પતાવે છે. લખીને પૂછો અને જવાબ કન્ફિગરેશન સાથે રાખો.

તમારો સ્ટેક ખરેખર જે વધારાનું એન્કેપ્સ્યુલેશન વાપરે છે તેના માટે બજેટ રાખો, અને ICMPv6 ચાલુ રાખો, Packet Too Big સહિત. બીજું હેડર વાપરી શકાય તેવો પેલોડ નાનો કરે છે, તેથી નાના પિંગનો જવાબ આપતો માર્ગ ફાઇલ ટ્રાન્સફરમાં તો પણ નિષ્ફળ જઈ શકે છે, અને બધું ICMPv6 ફેંકી દેતો ફાયરવોલ સુધારી શકાય એવી કદની સમસ્યાને કાળા છિદ્રમાં ફેરવે છે. સેવા જાહેર કરતા પહેલાં એક મોટું ટ્રાન્સફર ચકાસો.

કઈ વસ્તુ સાવ બીજી સમસ્યા છે

ફક્ત IPv4 ચાલતી એપ્લિકેશન સુધી ફક્ત IPv6 ચાલતા ક્લાયન્ટથી પહોંચવું એ અનુવાદ છે, ટ્યુનલિંગ નહીં, અને તેને જાણી જોઈને તૈનાત કરેલી NAT64 ગોઠવણ જેવું કંઈક જોઈએ. ગંતવ્ય ફક્ત એટલા માટે વધારાનું ટ્યુનલ હેડર નહીં સમજે કે તેં એક ઉમેર્યું છે. ઐતિહાસિક સંક્રમણ સેવાઓને પણ એટલી જ કાળજી જોઈએ: RFC 7526એ 6to4 એનીકાસ્ટ રિલે મોડેલ રદ કર્યું, તેથી તેની આસપાસ લખાયેલી માર્ગદર્શિકા એવી વસ્તુ વર્ણવે છે જેની પાસે હવે જાળવેલો જાહેર રિલે નથી.

જો સર્વર પાસે વાપરી શકાય એવું IPv6 અપસ્ટ્રીમ ન હોય, તો વિકલ્પો છે સમર્થિત અપસ્ટ્રીમ, બીજું એક્ઝિટ, અથવા IPv6 ટ્યુનલની બહાર રહે તેવો દસ્તાવેજી નિર્ણય. અસ્વીકાર્ય એ છે કે ક્લાયન્ટને કહેવું કે IPv6 સેવા અસ્તિત્વમાં છે, જ્યારે તેમનું સામાન્ય IPv6 કનેક્શન ચૂપચાપ VPNને ટાળે છે.