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

સાધને ખરેખર શું માપ્યું તે ઓળખો

સૌથી સામાન્ય ખોટો અલાર્મ લિંક-લોકલ સરનામું છે, જે fe80: થી શરૂ થાય છે અને દરેક IPv6-સક્ષમ ઇન્ટરફેસ પર હોય છે, મશીન IPv6 દ્વારા ઇન્ટરનેટ સુધી પહોંચે કે ન પહોંચે. તે ઇન્ટરફેસ યાદીમાં અને કેટલાક એપ્લિકેશન નિદાનમાં દેખાય છે, અને તમારા ટ્રાફિક માર્ગ વિશે કંઈ કહેતું નથી.

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

ત્રીજું કંઈ પણ ખોટો અલાર્મ નથી. ટનલની બહાર ઇન્ટરનેટ સુધી પહોંચતું ગ્લોબલ સરનામું જ સાચી લીક છે, અને કંઈ પણ નક્કી કરતાં પહેલાં તેને માપવા યોગ્ય છે:

ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co

જો પહેલો આદેશ ગ્લોબલ સરનામું છાપે અને ત્રીજો ટનલનું ન હોય એવું જાહેર IPv6 સરનામું પરત આપે, તો ટનલની બહાર તમારો સાચો માર્ગ છે. જો પહેલો લિંક-લોકલ એન્ટ્રી સિવાય કંઈ ન છાપે, તો ઠીક કરવા જેવી કોઈ લીક ક્યારેય નહોતી.

નિયંત્રણ ત્રણ શરતો નક્કી કરે છે

નિર્ણય "IPv6 સારું" કે "IPv6 ખરાબ" નથી. નિર્ણય એ છે કે તમે ત્રણ પરિસ્થિતિઓમાંથી કઈમાં છો, અને દરેકનો સાચો જવાબ અલગ છે અને ભૂલ કરો તો કિંમત પણ અલગ છે.

SituationCorrect controlCost if you disable IPv6 instead
Exit has no IPv6, host doesBlock IPv6 deliberately in the tunnel policySame visible result, no documentation of intent
Exit carries IPv6, host leaksRoute IPv6 into the tunnel and verifyYou lose IPv6 reachability entirely
Access network is IPv6-onlyChange nothing; use the tunnel's IPv6Machine loses connectivity completely

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

ત્રીજી પંક્તિ એ છે જ્યાં સામાન્ય સલાહ સક્રિયપણે હાનિકારક બને છે. મોબાઇલ ઓપરેટરો અને કેટલાક ઘરેલું જોડાણો IPv4 ગંતવ્યો માટે અનુવાદ સાથે IPv6-only નેટવર્ક ચલાવે છે. ત્યાં IPv6 દૂર કરો તો નેટવર્ક આપતું એકમાત્ર વહન દૂર થાય છે, જે તમે ડિબગ કરતા હતા તેના કરતાં ઘણું ખરાબ વિક્ષેપ ઊભો કરે છે.

જો એગ્ઝિટમાં IPv6 ન હોય, તો જાણી જોઈને બ્લોક કરો

ક્લાયન્ટની પોતાની પદ્ધતિને પ્રાધાન્ય આપો, કારણ કે તે ટનલ ચાલુ હોય ત્યાં સુધી જ લાગુ પડે છે અને તે પડે ત્યારે પાછી ખસે છે. OpenVPN પાસે આ માટે વિકલ્પ છે, અને iptables પાસે અન્ય ક્લાયન્ટ માટે સમકક્ષ નિયમ છે:

block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachable

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

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

જો એગ્ઝિટ IPv6 વહન કરે, તો તેને રૂટ કરો અને બંને ફેમિલી ચકાસો

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

ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.co

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

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

જો એક્સેસ નેટવર્ક ફક્ત IPv6 હોય, તો તેને અસ્પર્શ રાખો

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

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

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

સંબંધિત લેખો