പുതിയ ഹോട്ട്‌സ്‌പോട്ട് ക്ലയന്റ് IP ലഭിക്കുന്നതിൽ കുടുങ്ങുന്നത് VPN കുറ്റമല്ല

ഒരു ഫോൺ ഹോട്ട്സ്പോട്ടിൽ ചേരുന്നു, «IP വിലാസം ലഭിക്കുന്നു» എന്ന് നിന്നുപോകുന്നു, ഒടുവിൽ വിട്ടുകളയുന്നു. സ്വാഭാവിക നിഗമനം ഫോണിന്റെ VPN DNS-നെ തടസ്സപ്പെടുത്തുന്നു എന്നതാണ്, അതിനാൽ ആളുകൾ റിസോൾവറുകളും ചേർത്ത നിയമങ്ങളും എഡിറ്റ് ചെയ്യാൻ തുടങ്ങുന്നു. അത് തെറ്റായ ഘട്ടമാണ്. ക്ലയന്റ് ഒരിക്കലും പ്രാദേശിക വിലാസം സ്വീകരിച്ചിട്ടില്ല, അതില്ലാതെ അതിന് ഗേറ്റ്വേയും ഇല്ല, റിസോൾവറും ഇല്ല, കൈമാറാൻ ഒന്നുമില്ല, അതിനാൽ ഹോസ്റ്റ് ഫോണിലെ ഒരു VPN ക്രമീകരണത്തിനും ഈ പരാജയം വിശദീകരിക്കാനാവില്ല. കണക്ഷൻ, പ്രാദേശിക വിലാസ നിയോഗം, കൈമാറ്റം എന്നിവ മൂന്ന് വേറിട്ട ഘട്ടങ്ങളാണ്, അവസാനത്തേതിന് മാത്രമാണ് ടണലുമായി ബന്ധമുള്ളത്.

മൂന്ന് ഘട്ടങ്ങൾ, നിങ്ങൾ ഏതിലാണ്

ആദ്യം കണക്ഷൻ വരുന്നു: ക്ലയന്റ് ഹോട്ട്സ്പോട്ടിന്റെ വയർലെസ് നെറ്റ്വർക്കിൽ ചേരുന്നു. തെറ്റായ പാസ്വേഡ്, WPA3 പൊരുത്തക്കേട് അല്ലെങ്കിൽ റേഡിയോ അനുയോജ്യത പ്രശ്നം ഇവിടെ പരാജയപ്പെടുന്നു, ക്ലയന്റ് സാധാരണയായി അത് പറയും. രണ്ടാമത് വിലാസ നിയോഗം: IPv4-ന് ക്ലയന്റ് ലീസ് ആവശ്യപ്പെട്ട് വിലാസവും പ്രാദേശിക ഗേറ്റ്വേ ക്രമീകരണങ്ങളും സ്വീകരിക്കുന്നു, അതേസമയം IPv6 സാധാരണയായി DHCP-ക്ക് പകരം റൗട്ടർ പ്രഖ്യാപനങ്ങൾ ഉപയോഗിക്കുന്നു, എന്ന് AOSP-യുടെ ടെതറിംഗ് രേഖകൾ വിശദീകരിക്കുന്നു. മൂന്നാമത് പുറത്തേക്കുള്ള പ്രവേശനം: ഹോസ്റ്റ് ഫോൺ അനുവദിച്ച ട്രാഫിക് താൻ തിരഞ്ഞെടുത്ത മുകളിലേക്കുള്ള പാതയിലേക്ക് കൈമാറുന്നു, അത് അതിന്റെ ടണലാകാം, അല്ലായിരിക്കാം.

ക്ലയന്റിലെ വാചകം ഘട്ടം പറയുന്നു. വിലാസം ലഭിക്കുന്നതിൽ കുടുങ്ങുന്നത് രണ്ടാം ഘട്ടമാണ്, ഇന്റർനെറ്റിലേക്ക് ഒരു പാക്കറ്റും പോകുന്നതിന് മുമ്പ്. ബന്ധിപ്പിച്ചു, വിലാസമുണ്ട, പക്ഷേ ഒന്നും ലോഡ് ചെയ്യുന്നില്ല എന്നത് മൂന്നാം ഘട്ടമാണ്, അവിടെ റൂട്ടിംഗ്, പേരുകൾ, ടണൽ പരിധി എല്ലാം പ്രധാനമാണ്. ക്ലയന്റ് രണ്ടാം ഘട്ടത്തിൽ കുടുങ്ങിയിരിക്കെ മൂന്നാം ഘട്ടം രോഗനിർണയം ചെയ്യുന്നത് അഞ്ച് മിനിറ്റത്തെ ലീസ് പ്രശ്നം DNS എഡിറ്റിംഗ് നിറഞ്ഞ ഉച്ചകഴിഞ്ഞയാക്കുന്ന വഴിയാണ്.

മിത്ത്: റൂട്ട് ചെയ്ത VPN പ്രാദേശിക DHCP-യെ ദൂര ആവശ്യമാക്കി മാറ്റുന്നു

റൂട്ട് ചെയ്ത ടണൽ താൻ തിരഞ്ഞെടുക്കുന്ന ലക്ഷ്യങ്ങൾക്കായി IP പാക്കറ്റുകൾ നീക്കുന്നു. DHCP കണ്ടെത്തൽ ഹോട്ട്സ്പോട്ടിന്റെ സ്വന്തം സെഗ്മെന്റിലെ പ്രക്ഷേപണമാണ്, ഫോണിലെ ടെതറിംഗ് സേവനം അതിന് പ്രാദേശികമായി ഉത്തരം നൽകുന്നു, അതിനാൽ ടണൽ ഓണായിരിക്കെ ക്ലയന്റിന് വിലാസം ലഭിക്കാം. ബോധപൂർവം ബ്രിഡ്ജ് ചെയ്തതോ റിലേ ചെയ്തതോ ആയ രൂപകൽപ്പന മാത്രമാണ് ആ കൈമാറ്റം മറ്റെവിടെയോ അയക്കുന്നത്, അത് വേറെ പരാജയ ഒപ്പുള്ള വേറെ ക്രമീകരണമാണ്.

അതിനാൽ «VPN സെർവർ DHCP-ക്ക് ഉത്തരം നൽകുന്നില്ല» എന്നത് രോഗനിർണയമല്ല, മോഡൽ പിശകാണ്. പ്രാദേശിക ഇടനിലക്കാരൻ ഫോണിലുണ്ട്. അത് ഉത്തരം നൽകുന്നത് നിർത്തിയാൽ, കാരണങ്ങൾ പ്രാദേശികമാണ്: ടെതറിംഗ് സേവനം, ക്ലയന്റ് പരിധി, ലീസ് പൂൾ, അല്ലെങ്കിൽ കണക്ഷൻ ശരിയായി പൂർത്തിയാക്കാത്ത ക്ലയന്റ്. ഇവയൊന്നും ടണലിന്റെ അകലെയുള്ള വശത്ത് ജീവിക്കുന്നില്ല.

നിലവിലുള്ള ക്ലയന്റ് പ്രവർത്തിക്കുന്നത് യഥാർത്ഥത്തിൽ എന്താണ് തെളിയിക്കുന്നത്

മുമ്പേ ബന്ധിപ്പിച്ച ലാപ്ടോപ്പ് ഇപ്പോഴും പ്രവർത്തിക്കുകയും പുതിയ ഫോൺ പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്താൽ, ഹോട്ട്സ്പോട്ടും മുകളിലേക്കുള്ള പാതയും പൊതുവേ ജീവനോടെയുണ്ട്. ആ താരതമ്യം ഉപയോഗപ്രദമാണ്, ഏത് ഘടകമാണ് കുറ്റക്കാരൻ എന്നതിന്റെ തെളിവല്ല, കാരണം പ്രവർത്തിക്കുന്ന ക്ലയന്റ് മാറ്റത്തിന് മുമ്പുള്ള ലീസ് സൂക്ഷിച്ച് നിശബ്ദമായി പുതുക്കുന്നതാകാം.

അവിടെയുള്ളപ്പോൾ രണ്ട് പ്രാദേശിക പരിധികൾ പരിശോധിക്കേണ്ടതുണ്ട്. ഹോട്ട്സ്പോട്ട് പരിമിതമായ ലീസ് പൂളും ക്രമീകരിക്കാവുന്ന ക്ലയന്റ് പരിധിയും നൽകുന്നു, അതിനാൽ ചേർന്ന് ഉറങ്ങിയ ഉപകരണം വിലാസം സൂക്ഷിക്കാം, പുതിയത് കാത്തിരിക്കും. മറ്റൊരു നെറ്റ്വർക്കിലെ സ്റ്റാറ്റിക് കോൺഫിഗറേഷൻ ഓർക്കുന്ന ക്ലയന്റ് ലീസ് ആവശ്യപ്പെടുകയേ ഇല്ല, അത് പുറത്തുനിന്ന് ഒരുപോലെ തോന്നും, ഫോണിലല്ല, ക്ലയന്റിൽ തിരുത്തുന്നു.

താരതമ്യം പ്രാദേശികവും പഴയപടിയാക്കാവുന്നതുമായി നിർത്തുക

നയം അനുവദിക്കുന്ന ഉപകരണത്തിൽ, ടണൽ ഓഫും പിന്നീട് ഓണും ആക്കി ഒരു പുതിയ ക്ലയന്റ് കണക്ഷൻ താരതമ്യം ചെയ്യുക, ഹോട്ട്സ്പോട്ടും ക്ലയന്റും ബാക്കിയെല്ലാം മാറ്റമില്ലാതെ നിർത്തി. ഫോണിന്റെയും ക്ലയന്റിന്റെയും പതിപ്പുകൾ, തിരഞ്ഞെടുത്ത പ്രൊഫൈൽ, പരാജയപ്പെട്ട കൃത്യമായ ഘട്ടം എന്നിവ രേഖപ്പെടുത്തുക. മാനേജുചെയ്യുന്ന ഫോണിൽ, വ്യക്തമായ പരിശോധനയ്ക്കായി നിർവഹണം ഓഫ് ചെയ്യുന്നതിന് പകരം അംഗീകരിച്ച താരതമ്യം അഭ്യർത്ഥിക്കുക.

ടണലിനെ ആശ്രയിക്കുന്ന സ്ഥിരമായ ലീസ് പരാജയം പ്രാദേശിക നയത്തെക്കുറിച്ചോ നടപ്പാക്കൽ പരസ്പരപ്രവർത്തനത്തെക്കുറിച്ചോ ഉള്ള ഉപയോഗപ്രദമായ തെളിവാണ്. ഉപകരണത്തിലെ ഓരോ കൈമാറ്റ, NAT നിയമവും മായ്ക്കാനുള്ള അനുമതിയല്ല അത്. ആ നിയമങ്ങൾ അസംബന്ധ ട്രാഫിക് സംരക്ഷിക്കുന്നു, വിശാലമായ കൈമാറ്റാനുമതി പ്രാദേശിക DHCP സേവനം എന്തുകൊണ്ട് ഉത്തരം നൽകുന്നത് നിർത്തി എന്ന് വിശദീകരിക്കുന്നുമില്ല.

കാണാത്ത ലീസ് ഊഹിച്ച സ്റ്റാറ്റിക് വിലാസം കൊണ്ട് മൂടരുത്. ബോധപൂർവമായ സ്റ്റാറ്റിക് കോൺഫിഗറേഷന് യഥാർത്ഥ സബ്നെറ്റ്, ഗേറ്റ്വേ, വിഭജന പദ്ധതി, കൂട്ടിയിടി പരിശോധന എന്നിവ വേണം. ക്ലയന്റിന്റെ DNS മാറ്റുന്നത് അവയൊന്നും നൽകുന്നില്ല, അടുത്ത ഉപകരണത്തെ അതേ പരാജയത്തോടെ വിടുന്നു.

ലീസ് എന്താണ് തെളിയിക്കാത്തത്

വിലാസം ലഭിക്കുന്നത് പ്രാദേശിക നെറ്റ്വർക്കിലേക്കുള്ള പ്രവേശനം തെളിയിക്കുന്നു, ഫോണിന്റെ ടണൽ സംരക്ഷണമല്ല. ക്ലയന്റിന് ലീസ് ലഭിച്ചാൽ, താഴേക്കുള്ള പാത പ്രത്യേകം വിലയിരുത്തുക: ക്ലയന്റിന്റെ ട്രാഫിക് യഥാർത്ഥത്തിൽ ഫോൺ വഴി പോകുന്നുണ്ടോ, നിങ്ങൾ പ്രതീക്ഷിക്കുന്നിടത്ത് ലുക്കപ്പുകൾ പരിഹരിക്കുന്നുണ്ടോ, പുറത്തെ വിലാസം നിങ്ങൾ ഉദ്ദേശിച്ച എക്സിറ്റുമായി യോജിക്കുന്നുണ്ടോ? ഇവ മൂന്നാം ഘട്ടത്തിലെ ചോദ്യങ്ങളാണ്, കണക്ഷനിൽ മടക്കുന്നതിന് പകരം അവയുടെ സ്വന്തം പരിശോധന അർഹിക്കുന്നു.

ഘട്ടങ്ങൾ ക്രമത്തിൽ ചെയ്യുക, പരാജയം സ്ഥലം മാറുന്നത് നിർത്തും. വിലാസം ലഭിക്കുന്നതിൽ കുടുങ്ങിയ ക്ലയന്റ് പ്രാദേശിക ടെതറിംഗ് ചോദ്യമാണ്; വിലാസമുണ്ടെങ്കിലും പേജുകളില്ലാത്ത ക്ലയന്റ് കൈമാറ്റത്തിന്റെയോ പേരിടലിന്റെയോ ചോദ്യമാണ്; പേജുകളുണ്ടെങ്കിലും എക്സിറ്റ് തെറ്റായ ക്ലയന്റ് ടണൽ പരിധിയുടെ ചോദ്യമാണ്. ഇവ വേർതിരിച്ച് നിർത്തുന്നതാണ് ഡീബഗ്ഗിംഗിന്റെ ഭൂരിഭാഗവും.