പേജുകൾ ലോഡ് ആകുന്നു, പക്ഷേ VPN-ൽ അപ്ലോഡുകൾ നിലയ്ക്കുന്നു: ഏത് കാരണം വിജയിക്കുന്നു
വലിപ്പത്തെ ആശ്രയിക്കുന്ന നിർത്തം പാതയുടെ MTU തകരാറിന് യോജിക്കുന്നു, കൂടാതെ DNS, ആപ്പ് പരിധി അല്ലെങ്കിൽ അസ്ഥിര ടണലിനും യോജിക്കുന്നു. ഏതെന്ന് നാല് നിരീക്ഷണങ്ങൾ തീരുമാനിക്കുന്നു.
പേജുകൾ ലോഡ് ആകുന്നു, VPN കണക്ട് ചെയ്തതായി അറിയിക്കുന്നു, ഫയൽ അപ്ലോഡ് ഓരോ തവണയും അതേ സ്ഥലത്ത് മരവിക്കുന്നു. ഈ വിവരണത്തിന് നാല് വിശദീകരണങ്ങൾ യോജിക്കുന്നു: പാക്കറ്റ് വലിപ്പത്തിന്റെ പ്രശ്നം, പേര് പരിഹരിക്കാനുള്ള പ്രശ്നം, ആപ്പ് പരിധി, ആവർത്തിച്ച് പുനഃസജ്ജീകരിക്കുന്ന ടണൽ. ഓരോന്നും വ്യത്യസ്ത നിരീക്ഷണത്തിലൂടെ സ്ഥിരീകരിക്കാനോ ഒഴിവാക്കാനോ കഴിയും, അതിനാൽ തീരുമാനം കാരണം ഊഹിക്കലല്ല, ശരിയായ പരീക്ഷ തിരഞ്ഞെടുക്കലാണ്.
നാല് സ്ഥാനാർത്ഥികളും ഒരു രൂപവും
പരാജയത്തിന്റെ രൂപത്തിൽ തുടങ്ങുക, കാരണം ഏതെങ്കിലും ഉപകരണം തുറക്കുന്നതിന് മുമ്പ് അത് പട്ടികയുടെ ഭൂരിഭാഗവും ഒഴിവാക്കുന്നു. സ്ഥിരമായ വലിപ്പത്തിൽ സംഭവിക്കുന്ന നിർത്തം വിപരീതം തെളിയുന്നതുവരെ വലിപ്പത്തിന്റെ പ്രശ്നമാണ്. ക്രമരഹിതമായ സ്ഥലങ്ങളിൽ സംഭവിക്കുന്ന നിർത്തം നഷ്ടമോ സ്ഥിരതയോ ഉള്ള പ്രശ്നമാണ്. കണക്ഷൻ തുറക്കുന്നതിന് മുമ്പുള്ള പരാജയം പേരിന്റെ പ്രശ്നമാണ്.
നാലാമത്തെ സ്ഥാനാർത്ഥി ആപ്പാണ്. അപ്ലോഡ് പരിധികൾ, അഭ്യർത്ഥനകളുടെ സമയപരിധികൾ, പ്രോക്സിയുടെ ബോഡി വലിപ്പ പരിധികൾ എന്നിവ ബ്രൗസറിൽ നിന്ന് നെറ്റ്വർക്ക് തകരാറിനോട് സാമ്യമുള്ള പരാജയങ്ങൾ സൃഷ്ടിക്കുന്നു, അവ സാധാരണയായി നിർത്തത്തിന് പകരം നിരസിക്കലായാണ് വരുന്നത്.
എന്തെങ്കിലും പരീക്ഷിക്കുന്നതിന് മുമ്പ് നിരീക്ഷിച്ച രൂപം എഴുതിവയ്ക്കുക. "ഏകദേശം അതേ ബൈറ്റ് സംഖ്യയിൽ, ഓരോ തവണയും, ടണൽ ഓണായിരിക്കെ നിലയ്ക്കുന്നു" എന്നത് "അപ്ലോഡുകൾ പ്രവർത്തിക്കുന്നില്ല" എന്നതിനേക്കാൾ വളരെ ശക്തമായ തുടക്കമാണ്.
തുടർന്ന് പരീക്ഷിക്കുമ്പോൾ പാത സ്ഥിരമായി നിർത്തുക. എക്സിറ്റ്, പ്രോട്ടോക്കോൾ, സർവർ എന്നിവ ഒരുമിച്ച് മാറ്റുന്നത് അവയിലൊന്നിനും ആരോപിക്കാനാകാത്ത ഫലം നൽകുന്നു. ഓരോ പ്രവർത്തനത്തിനും ഒരു ചരം, അത് എഴുതിവയ്ക്കുക.
നയം തൊടുന്നതിന് മുമ്പ് വലിപ്പം പകുതിയാക്കുക
ഏറ്റവും വിലകുറഞ്ഞ വേർതിരിക്കൽ ഒരു സംഖ്യ മാറ്റുന്ന പരിശോധനയാണ്. ലക്ഷ്യസ്ഥാനത്തേക്ക് വർധിച്ചുവരുന്ന വലിപ്പത്തിൽ, ഖണ്ഡിക്കൽ വിലക്കിയ ping അയയ്ക്കുക, നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഫയൽ അതേ സേവനത്തിലേക്ക് അപ്ലോഡ് ചെയ്യുക, എന്നിട്ട് ഓരോന്നും എവിടെ നിലയ്ക്കുന്നു എന്ന് താരതമ്യം ചെയ്യുക.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadആദ്യ കമാൻഡ് പൂർണ വലിപ്പത്തിലുള്ള പാക്കറ്റ് പാതയിലൂടെ കടക്കുന്നുണ്ടോ എന്ന് അറിയിക്കുന്നു. 1500 ബൈറ്റ് MTU-യിൽ, ഖണ്ഡിക്കപ്പെടാത്ത ഏറ്റവും വലിയ ICMP പേലോഡ് 1472 ബൈറ്റാണ്, അകത്തെ പാക്കറ്റ് തുടങ്ങുന്നതിന് മുമ്പ് ടണൽ ആ ബജറ്റിൽ നിന്ന് കൂടുതൽ എടുക്കുന്നു. രണ്ടാമത്തേത് ആപ്പ് തലത്തിലുള്ള കൈമാറ്റത്തിന് വലിപ്പവും കാലയളവും നൽകുന്നു, യഥാർത്ഥത്തിൽ പ്രധാനമായ സംഖ്യ അതാണ്.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
രണ്ടും ഒരുമിച്ച് വായിക്കുക. പരിധിക്ക് മുകളിൽ പരാജയപ്പെടുന്ന പരിശോധനകളും അതേ പരിധിക്ക് സമീപം നിലയ്ക്കുന്ന അപ്ലോഡും സുസ്ഥിരമായ ഒരു കഥയാണ്. എല്ലാ പരിശോധനകളും വിജയിക്കുമ്പോൾ അപ്ലോഡ് പാത വ്യക്തമായി വഹിക്കുന്ന ബൈറ്റ് സംഖ്യയിൽ നിലയ്ക്കുന്നുവെങ്കിൽ, അത് ആപ്പിനെയോ സർവറിനെയോ സൂചിപ്പിക്കുന്നു, MTU-യിൽ എത്ര ജോലി ചെയ്താലും അത് മാറ്റില്ല. ആ നെഗറ്റീവ് ഫലം പോസിറ്റീവിന് തുല്യം വിലയുള്ളതാണ്. അത് അന്വേഷണത്തിന്റെ ഏറ്റവും ചെലവേറിയ ശാഖ ഒഴിവാക്കുന്നു.
തുടർന്ന് കൈമാറ്റത്തിനിടയിലെ സ്ഥിരത പരിശോധിക്കുക, കാരണം വലിയ അപ്ലോഡിന്റെ നടുവിൽ കീ പുതുക്കുന്ന ടണൽ വലിപ്പാധിഷ്ഠിതമായി തോന്നുന്ന, എന്നാൽ അല്ലാത്ത പരാജയം സൃഷ്ടിക്കുന്നു. പ്രവർത്തനസമയം വായിക്കുന്നതാണ് അത് സ്ഥിരീകരിക്കാനുള്ള ഏറ്റവും വിലകുറഞ്ഞ വഴി.
നന്നാക്കലും പരിഹാര മാർഗവും തമ്മിൽ തിരഞ്ഞെടുക്കുക
തെളിവുകൾ വലിപ്പത്തെ സൂചിപ്പിക്കുന്നുവെങ്കിൽ, രണ്ട് സത്യസന്ധമായ ഉത്തരങ്ങളും ഒരു അസത്യസന്ധമായ ഉത്തരവുമുണ്ട്. സത്യസന്ധമായവ: ആവശ്യമായ ICMP പ്രതികരണം അനുവദിച്ച് പാത-MTU കണ്ടെത്തൽ പുനഃസ്ഥാപിക്കുക, അല്ലെങ്കിൽ പ്രഖ്യാപിത സെഗ്മെന്റ് വലിപ്പം പരിമിതപ്പെടുത്തി പങ്കാളികൾ ചെറിയ സെഗ്മെന്റുകൾ അയയ്ക്കാൻ ഇടയാക്കുക. അസത്യസന്ധമായത്: ഇന്റർഫേസ് MTU ഫോറത്തിൽ നിന്ന് പകർത്തിയ മൂല്യത്തിലേക്ക് താഴ്ത്തി, അത് എന്താണ് മാറ്റിയതെന്ന് ഒരിക്കലും പരിശോധിക്കാതിരിക്കുക.
തിരഞ്ഞെടുപ്പ് നിങ്ങൾ എന്ത് നിയന്ത്രിക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന നെറ്റ്വർക്കിൽ ICMP സന്ദേശങ്ങൾ അനുവദിക്കുന്നതാണ് വൃത്തിയായ പരിഹാരം, കാരണം അത് ഓരോ പ്രോട്ടോക്കോളിനും സംവിധാനം പ്രവർത്തനക്ഷമമായി നിർത്തുന്നു. നിങ്ങൾ നിയന്ത്രിക്കാത്ത പാതയിൽ പരിമിതപ്പെടുത്തലാണ് പ്രായോഗിക ഓപ്ഷൻ, അത് മുഴുവൻ സർവറിനും അല്ല, ഇടുങ്ങിയതായി പ്രയോഗിക്കണം.
തെളിവുകൾ ആപ്പിനെ സൂചിപ്പിക്കുന്നുവെങ്കിൽ, ആപ്പോ അതിന്റെ പ്രോക്സി കോൺഫിഗറേഷനോ ശരിയാക്കുക. 413 പ്രതികരണവും തൂങ്ങിക്കിടക്കുന്ന കണക്ഷനും വ്യത്യസ്ത പരാജയങ്ങളാണ്, രണ്ടാമത്തേത് സാധാരണയായി സ്വന്തം പരിധികളുള്ള പ്രോക്സി ഉൾപ്പെടുന്ന ചങ്ങലയിൽ എവിടെയോ ഉള്ള സമയപരിധിയാണ്.
ഏതായാലും, യഥാർത്ഥ മൂല്യങ്ങൾ സൂക്ഷിച്ച് തിരികെയെത്തിയ ശേഷം വീണ്ടും പരീക്ഷിക്കുക. വിജയകരമായ കൈമാറ്റവുമായി ഒത്തുവരുന്ന മാറ്റം അതാണ് കാരണമെന്നതിന് തെളിവല്ല, മാറ്റം പിൻവലിക്കാനുള്ള കഴിവാണ് രോഗനിർണയത്തെ യാദൃച്ഛികതയിൽ നിന്ന് വേർതിരിക്കുന്നത്.
അടുത്ത സംഭവം വരെ നിലനിൽക്കാൻ തീരുമാനം രേഖപ്പെടുത്തുക
നാല് വസ്തുതകൾ മതി: നിരീക്ഷിച്ച പരാജയത്തിന്റെ രൂപം, പരിശോധനകളുടെ ഫലങ്ങൾ, നിങ്ങൾ വരുത്തിയ മാറ്റം, വീണ്ടും പരീക്ഷിച്ച ഫലം. അവ ഉപയോഗിച്ച് അടുത്ത ആൾക്ക് പ്രശ്നം അതേതാണോ അതേ ലക്ഷണമുള്ള പുതിയതാണോ എന്ന് പറയാം.
പാതയുടെ സന്ദർഭവും രേഖപ്പെടുത്തുക, കാരണം MTU കണ്ടെത്തൽ ഒരു നിർദ്ദിഷ്ട ലിങ്കിന് മാത്രമുള്ളതാണ്. വീട്ടിൽ പ്രവർത്തിച്ച് ഹോട്ടലിൽ പരാജയപ്പെടുന്ന ലാപ്ടോപ്പിന് രണ്ട് പാതകളുണ്ട്, ഒന്നിൽ പ്രയോഗിച്ച പരിഹാരം മറ്റൊന്നിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
അവസാനമായി, "VPN അപ്ലോഡുകൾ തകർത്തു" എന്ന സംഗ്രഹത്തെ എതിർക്കുക. ടണൽ പ്രവർത്തിച്ച കേസിലും പരാജയപ്പെട്ട കേസിലും ഉണ്ടായിരുന്നു; മാറിയത് പാത വഹിക്കേണ്ടിയിരുന്ന പാക്കറ്റിന്റെ വലിപ്പമോ കൈമാറ്റം നിർത്തിയ സ്ഥലമോ ആണ്. യഥാർത്ഥ സംവിധാനത്തെ പേരിടുന്നതാണ് കുറിപ്പിനെ ഉപയോഗപ്രദമാക്കുന്നത്.