വിശാല 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 ഒഴിവാക്കുന്നതോ ആ വിലാസത്തെ ഇപ്പോഴും ടണലിലേക്ക് അയക്കുന്ന പ്രിഫിക്സ് തിരുത്തില്ല. ആദ്യം തിരഞ്ഞെടുപ്പ് പരിശോധിക്കുക, പിന്നെ പാത.