IPv6 ટ્રાફિક VPNની બહાર: લીક થતો રૂટ શોધો

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

એ ક્રમમાં કામ કરો. તેમને ક્રમ વિના જવાબ આપવાથી એ બહસ લાંબી થાય છે કે ક્લાયન્ટમાં ખામી છે કે નહીં, જ્યારે સાચો જવાબ એ છે કે IPv6 રૂટ ક્યારેય ઇન્સ્ટોલ જ થયો નહીં.

કયો ફ્લો ખરેખર બહાર ગયો, અને કયા એડેપ્ટર પર

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

પૃષ્ઠ લોડ કરીને તેનું પરિણામ વાંચવાને બદલે દરેક ફેમિલી માટે એક વિનંતી મોકલો. એક જ પૃષ્ઠ v6 અને v4 સંસાધનો મિશ્ર કરી શકે છે, બેકગ્રાઉન્ડ પ્રક્રિયા તમારી સામેના ટૅબ કરતાં જુદી રીતે વર્તી શકે છે, અને કૅશ થયેલો જવાબ તમે ચકાસવા માગતા નેટવર્ક ફેરફાર કરતાં વધુ ટકી શકે છે. તમે ચકાસતા હો તે ગંતવ્ય નક્કી કરો અને તેને નોંધો, જેથી પુનરાવર્તિત રન એ જ માપે.

કર્નલે પસંદ કરેલો રૂટ વાંચવો

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

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

વધુ ચોક્કસ પ્રીફિક્સ એ સામાન્ય કારણ છે કે એક ગંતવ્ય ટનલની બહાર રહે છે જ્યારે બાકીનું બધું અંદર રહે છે, અને પૉલિસી નિયમ કોઈ પણ રૂટ કરતાં ઊંચી પ્રાથમિકતાએ એ જ કરી શકે છે. મેટ્રિક પણ વાંચો, કારણ કે એક જ પ્રીફિક્સની બે નોંધો સ્ક્રીન પરના ક્રમને બદલે મેટ્રિકથી નક્કી થાય છે. Windows પર સમાન યાદી Get-NetRoute -AddressFamily IPv6, નિર્ણય ક્રમ સાથે મેળ ખાવા માટે મેટ્રિક પ્રમાણે ગોઠવેલી. ટેબલમાં સાચો દેખાતો નિયમ પણ નીચા ક્રમાંકવાળા પૉલિસી નિયમ સામે હારી શકે છે, તેથી નિયમની યાદી રૂટની યાદી સાથે જ એક જ શ્વાસમાં આવે છે.

ક્લાયન્ટની IPv6 પૉલિસી ક્યાંથી આવે છે

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

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

સાંકડું અવલોકન, જ્યારે ટેબલ વિરોધાભાસ ધરાવે

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

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

અંતરાલ બંધ કરવાની ત્રણ રીતો

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

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