વિશાળ VPN રૂટ કેટલીક જાહેર સાઇટ્સને કેમ તોડે છે

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

નિષ્ફળ જતું નામ ઉકેલો, પછી બ્રાઉઝરને બદલે રાઉટિંગ કોષ્ટકમાં જુઓ.

સરનામાની સરખામણી કરો, સાઇટના નામની નહીં

ક્લાયન્ટે ખરેખર જે સરનામું અજમાવ્યું તે શોધો, પછી તપાસો કે કયો રૂટ તેની સાથે મેળ ખાય છે. 45.61.20.10 ની અંદરનું લક્ષ્ય 45.0.0.0/8 હેઠળ આવે છે જો તે પ્રીફિક્સ હાજર હોય, પછી ભલે સાઇટનો પોતાનો ટનલ સાથે કોઈ સંબંધ ન હોય. નિષ્ફળ સરનામાની ઇન્સ્ટોલ કરેલા પ્રીફિક્સ સાથે સરખામણી કરવી એ બાદબાકીની સમસ્યા છે, અનુમાન નહીં.

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

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

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

પ્રીફિક્સ, તેનું ઇન્ટરફેસ અને ઉકેલાયેલું સરનામું લખો. તે ત્રણ મૂલ્યો જ આખું નિદાન છે.

રૂટ કોણે ઇન્સ્ટોલ કર્યો તે શોધો

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

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

મૂળ વર્ગ-આધારિત વર્તન કાળજીપૂર્વક વાંચો

મૂળ Windows પ્રોફાઇલમાં એક દસ્તાવેજીકૃત સેટિંગ છે, NativeProfile/DisableClassBasedDefaultRoute, જે ઇન્ટરફેસ સરનામેથી અનુમાનિત સ્વયં રૂટ નિયંત્રિત કરે છે. 45 થી શરૂ થતું પ્રોફાઇલ સરનામું તે વર્તન હેઠળ 45.0.0.0/8 એન્ટ્રી બનાવી શકે છે, અને એ રીતે એક જાહેર સરનામું આખી વર્ગ-A શ્રેણી પકડે છે.

ગુણધર્મનું નામ ખોટા વાંચનનું આમંત્રણ આપે છે: તેને true પર સેટ કરવાથી અનુમાન બંધ થાય છે, અને false તેને ચાલુ કરે છે. તે ડિફોલ્ટ રૂટ જેવી જ વસ્તુ નથી, અને પોતાના પ્રીફિક્સ ઇન્સ્ટોલ કરતા તૃતીય-પક્ષ ક્લાયન્ટને તે નિયંત્રિત કરતું નથી.

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

સ્રોત સુધારો, પછી બંને માર્ગ ફરી તપાસો

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

તે જ સમયે સર્વરની સરનામા યોજના સમીક્ષા કરો. જાહેર જગ્યા સાથે ઓવરલેપ થતો પૂલ આ પ્રકારની સમસ્યા વારંવાર સર્જે છે. ઓપરેટરે ઇરાદાપૂર્વક પસંદ કરેલી શ્રેણી બીજી ચર્ચાને લાયક છે, સ્વયં ફરી-ક્રમાંકનને નહીં.

MTU વધારવાથી કે DNS ખાલી કરવાથી એ પ્રીફિક્સ સુધરશે નહીં જે હજી પણ તે સરનામાને ટનલમાં મોકલે છે. પહેલા પસંદગી કસોટી કરો, પછી માર્ગ.