તમારા /64 ને વિભાજિત કરવાથી IPv6 VPN ક્લાયન્ટ્સ સુધી રૂટ થતું નથી

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

ભ્રમ: તમારા /64 નો એક ભાગ પહેલેથી પહોંચી શકાય તેવો છે

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

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

આ સમગ્ર નિષ્ફળતા છે: આગળની દિશા કામ કરે છે કારણ કે તમારું સર્વર તેને મોકલે છે, અને પાછળની દિશા એક હોપ દૂર મૃત્યુ પામે છે કારણ કે અપસ્ટ્રીમને ક્યારેય ખબર પડી નહીં કે ક્લાયન્ટ અસ્તિત્વમાં છે.

લિંક પરની ડિલિવરી ખરેખર શું માંગે છે

જ્યારે અપસ્ટ્રીમ સમગ્ર /64 ને ભૌતિક લિંક પર માને છે, ત્યારે તે દરેક ગંતવ્ય સરનામાને પડોશી શોધ દ્વારા ઉકેલે છે. તે તે લિંક પર એક વિનંતી મોકલે છે અને અપેક્ષા રાખે છે કે સરનામાનો માલિક જવાબ આપશે. ટનલ પાછળ બેઠેલો VPN ક્લાયન્ટ તે લિંક પર નથી અને જવાબ આપી શકતો નથી, તેથી વિનંતી જવાબ વિનાની રહે છે અને પેકેટ કાઢી નાખવામાં આવે છે.

/65 કાપીને બહાર કાઢવાથી તે અપેક્ષા બદલાતી નથી. અપસ્ટ્રીમ હજુ પણ શ્રેણીને લિંક પરની તરીકે ગણે છે, કારણ કે તેનો મત બદલી શકે તેવી એકમાત્ર વસ્તુ એ રૂટ અથવા પ્રોક્સી છે જે ક્લાયન્ટ વતી જવાબ આપે. બંનેમાંથી કોઈ દેખાતું નથી કારણ કે તમે VPN રૂપરેખાંકન સંપાદિત કર્યું છે. તે જ અંતર એ સમજાવે છે કે કેમ પૂલ પોતાના ક્લાયન્ટ્સ વચ્ચે સંપૂર્ણ કામ કરી શકે અને તેમ છતાં અન્ય કોઈપણ જગ્યાએથી અપહોંચ હોઈ શકે.

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

રૂટેડ ડિલિવરી શું માંગે છે

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

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

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

બે સ્વતંત્ર રૂટ સાચા કરવાના છે

પૂલ પ્રીફિક્સ અને ક્લાયન્ટનું પોતાનું ડિફોલ્ટ રૂટ અલગ સેટિંગ્સ છે, અને તેમને ભેગા કરવાથી આંશિક કનેક્ટિવિટી ઉત્પન્ન થાય છે જે તૂટેલી ટનલ જેવી લાગે છે. પૂલ સર્વરને કહે છે કે કયા સરનામાં આપવા. ક્લાયન્ટના રૂટ નક્કી કરે છે કે ક્લાયન્ટ કયા ગંતવ્યો પર ટ્રાફિક ટનલમાં મોકલે છે.

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

ઉપરનું પ્રીફિક્સ દસ્તાવેજીકરણ જગ્યા છે, અને રીડાયરેક્ટ ફક્ત IPv6 પર લાગુ પડે છે, જે ડ્યુઅલ-સ્ટેક જમાવટ ઘણી વાર ઇચ્છે છે જ્યારે IPv6 ડિલિવરી હજુ ઠીક કરવામાં આવી રહી છે. IPv4 રીડાયરેક્ટ IPv6 કવરેજ સ્થાપિત કરતું નથી, અને બંનેમાંથી કોઈ સેટિંગ બીજાને અનુમાનિત કરતું નથી.

તમે લાગુ કરો તે કોઈપણ નીતિ હેઠળ IPv6 જે નિયંત્રણ ટ્રાફિક પર આધાર રાખે છે તેને ચાલુ રાખો. Packet Too Big સંદેશાઓ ફક્ત TCP અને UDP ને મંજૂરી આપતા ફાયરવોલના ઉત્તમ બલિદાન છે, અને તેમને કાઢી નાખવાથી એવા કનેક્શન બને છે જે સ્થપાય છે અને પછી મોટા સ્થાનાંતરણો પર અટકી જાય છે.

રાઉટર જાહેરાતો ત્રીજો ગતિશીલ ભાગ છે. જો ગેટવે અપલિંક પર જાહેર કરવાનું શરૂ કરે, તો તે બદલી શકે છે કે ક્લાયન્ટ્સ અને પડોશીઓ લિંક પરના પ્રીફિક્સ વિશે શું માને છે, જે તમે હમણાં દસ્તાવેજીકૃત કરેલી ડિઝાઇનને શાંતિથી રદ કરી શકે છે.

ડિઝાઇન નોંધો જેથી પુનર્નિર્માણ તેને પુનઃઉત્પાદિત કરે

ત્રણ વસ્તુઓ અલગથી લખો: ક્લાયન્ટ ફાળવણી, ક્લાયન્ટનું ગંતવ્ય રૂટ, અને ફાળવણી માટે અપસ્ટ્રીમની ડિલિવરી પદ્ધતિ. જેની પાસે ત્રણેય છે તે જમાવટ ફરીથી બનાવી શકે છે; જેની પાસે ફક્ત પૂલ સેટિંગ છે તે મૂળ બગ પુનઃઉત્પાદિત કરશે.

પછી પરત દિશાનું સ્પષ્ટ રીતે પરીક્ષણ કરો, એવા પેકેટ સાથે જે બહારથી પાછું આવવું પડે. openvpn(8) મેન્યુઅલ server-ipv6 અને redirect વિકલ્પોને આવરી લે છે, અને તમારા પ્રદાતાની રૂટિંગ પુષ્ટિ તે અડધું આવરી લે છે જે મેન્યુઅલ કરી શકતું નથી.