VPN ડિસ્કનેક્ટ થયા પછી Mac ની IPv6 સ્થિતિ કેવી રીતે ચકાસવી

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

ખરેખર તૂટેલા પરિવારથી શરૂ કરો

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

આખી તુલના દરમિયાન એ જ Wi-Fi નેટવર્ક અને એ જ એક્સેસ પોઇન્ટ રાખો. ગઈકાલે IPv6 આપતું કાફે નેટવર્ક હમણાં તમે જે નેટવર્ક પર છો તે વિશે કંઈ કહેતું નથી.

રૂટ પહેલાં સરનામું વાંચો

સિસ્ટમ સેટિંગ્સમાં, સક્રિય સેવાની TCP/IP પેનલ બતાવે છે કે IPv6 સ્વચાલિત, મેન્યુઅલ કે ફક્ત લિંક-લોકલ છે. તમે જે અપેક્ષા રાખો છો તેની સાથે તેની તુલના કરો, યાદ રાખો કે સંસ્થાએ જાણી જોઈને મેન્યુઅલ ગોઠવણ પસંદ કરી હોઈ શકે. પછી ifconfig ચલાવો અને સંબંધિત ઇન્ટરફેસ વાંચો. ફક્ત fe80:: સરનામું એટલે ઇન્ટરફેસ તેના પડોશીઓ સાથે વાત કરી શકે અને વધુ નહીં, તેથી લિંક-લોકલ હાજરી વાપરી શકાય તેવા માર્ગનો પુરાવો નથી.

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

નિષ્ફળ ગંતવ્ય માટે રૂટ ટેબલ વાંચો

કર્નલને નિષ્ફળ ગયેલા ગંતવ્ય વિશે પૂછો, ડિફૉલ્ટ રૂટ વિશે નહીં. route -n get 2001:db8::25 તે સરનામા માટે પસંદ કરેલ ઇન્ટરફેસ અને ગેટવે છાપે છે, અને netstat -rn -f inet6 તુલના માટે આખું ટેબલ બતાવે છે. ડિફૉલ્ટ રૂટ તમને કહે છે કે ડિફૉલ્ટ અસ્તિત્વમાં છે; તે કહેતું નથી કે આ ગંતવ્ય તેનો ઉપયોગ કરે છે.

DNS ને તેના પોતાના ખાનામાં રાખો. IPv4 દ્વારા પહોંચી શકાય તેવો રિઝોલ્વર હજી AAAA રેકોર્ડ પરત કરી શકે છે, તેથી લુકઅપ નિષ્ફળતા અને રૂટિંગ નિષ્ફળતા બ્રાઉઝરમાં એ જ લક્ષણ ઉત્પન્ન કરે છે.

ક્લાયન્ટની બ્લોક નીતિને બાકી રહેલા નિયમથી અલગ કરો

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

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

પુરાવા એકઠા કરો, પછી એક વસ્તુ બદલો

એક કનેક્ટ-ડિસ્કનેક્ટ ચક્રની બંને બાજુએ ક્લાયન્ટ આવૃત્તિ, macOS આવૃત્તિ, નેટવર્ક સેવા, ઇચ્છિત ડિસ્કનેક્ટ નીતિ અને સરનામા તથા રૂટનું આઉટપુટ નોંધો. એ જ નોંધ ફરિયાદને જીવનચક્રની સમસ્યામાં ફેરવે છે જે કોઈ તપાસી શકે. પછી એક જ ફેરફાર કરો અને ફરી માપો.

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