ഫോണിന് പേജ് തുറക്കാനാകുന്നില്ല: കേൾക്കുന്ന വിലാസം പരിശോധിക്കുക

ലാപ്ടോപ്പ് പേജ് localhost-ൽ നൽകുന്നു, ഫോൺ അതേ VPN-ലേക്ക് ചേരുന്നു, ഫോണിലെ ബ്രൗസർ സൈറ്റിൽ എത്താനാകുന്നില്ലെന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. ടണലിൽ ഇതുവരെ ഒന്നും തെറ്റല്ല, കാരണം ടണൽ പാക്കറ്റുകൾ മാത്രം എത്തിക്കുന്നു. loopback ഇന്റർഫേസിൽ ബന്ധിച്ച ഒരു ഡെവലപ്മെന്റ് സർവർ മറ്റൊന്നിനെ ലക്ഷ്യമിടുന്ന കണക്ഷൻ ഒരിക്കലും സ്വീകരിക്കുന്നില്ല, അതിനാൽ ആദ്യം നോക്കേണ്ടത് കേൾക്കുന്ന സോക്കറ്റാണ്, VPN അല്ല.

സോക്കറ്റ്, bind ക്രമീകരണം, ഫയർവാൾ നിയമം, URL എന്നിവ ഈ ക്രമത്തിൽ പരിശോധിക്കുക.

സോക്കറ്റ് കൂടുതൽ ഇടുങ്ങിയ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു

127.0.0.1-ൽ സൃഷ്ടിച്ച ഒരു ശ്രോതാവ് യന്ത്രത്തിൽ നിന്നുതന്നെ വരുന്ന ട്രാഫിക് സ്വീകരിക്കുകയും മറ്റൊരു വിലാസത്തിൽ എത്തുന്ന എല്ലാം നിരസിക്കുകയും ചെയ്യുന്നു. wildcard വിലാസത്തിലുള്ള ശ്രോതാവ് എല്ലാ പ്രാദേശിക ഇന്റർഫേസുകളിലും സ്വീകരിക്കുന്നു, VPN ഇന്റർഫേസ് ഉൾപ്പെടെ, ഇത് മിക്ക ഡെവലപ്മെന്റ് സെറ്റപ്പുകൾക്കും ആവശ്യമുള്ളതിനേക്കാൾ വിശാലമാണ്. ഒരു നിർദ്ദിഷ്ട VPN വിലാസത്തിൽ ബന്ധിച്ച ശ്രോതാവാണ് ഏറ്റവും ഇടുങ്ങിയ ഉപയോഗപ്രദമായ ഓപ്ഷൻ, അത് ആ വിലാസം നിലനിൽക്കുന്നിടത്തോളം മാത്രം പ്രവർത്തിക്കുന്നു.

അതിൽ നിന്ന് രണ്ട് നാമകരണ കെണികൾ ഉണ്ടാകുന്നു. ഫോണിലെ ബ്രൗസറിൽ localhost എന്നാൽ ഫോൺ, ലാപ്ടോപ്പ് അല്ല. wildcard വിലാസം ഒരു bind മൂല്യമാണ്, URL-ൽ ടൈപ്പ് ചെയ്യേണ്ട ഒന്നല്ല. ഇവയിലൊന്ന് ഉപയോഗിച്ച് പരിശോധിക്കുന്ന ആരും നെറ്റ്വർക്ക് ഒട്ടും പങ്കെടുക്കാത്ത ഒരു പരാജയം റിപ്പോർട്ട് ചെയ്യും.

IPv6 മൂന്നാമത്തെ കേസ് ചേർക്കുന്നു, കാരണം സോക്കറ്റിന് എളുപ്പത്തിൽ വീഴ്ച സംഭവിക്കാവുന്ന ഓപ്ഷനുകൾ അനുസരിച്ച് IPv4-ഉം IPv6-ഉം സ്വീകരിക്കാനാകും. ലിസ്റ്റിംഗിലെ വിലാസ കുടുംബം വായിക്കുക. ഒരു കുടുംബത്തിനുള്ള wildcard എൻട്രി മറ്റൊന്നിനെ വിവരിക്കുന്നില്ല.

കേൾക്കുന്ന വിലാസം വായിക്കുക

ക്രമീകരണം മാറ്റുന്നതിന് മുമ്പ് സോക്കറ്റ് പരിശോധിക്കുക. പ്രാദേശിക വിലാസം, പോർട്ട്, ഉടമസ്ഥ പ്രോസസ്സ് എന്നിവ ഒരുമിച്ച് സർവർ VPN-ൽ നിന്ന് എത്താനാകുമോ എന്ന് വ്യക്തമാക്കുന്നു.

Get-NetTCPConnection -State Listen -LocalPort 8080 | Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 8080).OwningProcess
ipconfig | Select-String -Pattern 'IPv4'
Get-NetFirewallRule -DisplayName '*8080*' | Format-Table DisplayName,Enabled,Profile,Direction,Action

127.0.0.1 എന്ന പ്രാദേശിക വിലാസം ചോദ്യം തീർക്കുന്നു: ഫയർവാളിലെ ഏത് മാറ്റവും സഹായിക്കില്ല, കാരണം ആപ്ലിക്കേഷൻ VPN ഇന്റർഫേസിൽ കേൾക്കുന്നില്ല. wildcard അല്ലെങ്കിൽ VPN വിലാസം എന്നാൽ സോക്കറ്റ് കുഴപ്പമില്ലെന്നും അടുത്ത അതിർത്തി ബാധകമാണെന്നും അർത്ഥം.

ഉടമസ്ഥ പ്രോസസ്സും സ്ഥിരീകരിക്കുക, കാരണം സാധാരണ പോർട്ടിലെ അസംബന്ധ സേവനം പട്ടിക ശരിയായി കാണിച്ചേക്കാം, എന്നാൽ ഉദ്ദേശിച്ച സർവർ ഒരിക്കലും ആരംഭിച്ചിട്ടില്ല. പേര് മാത്രമല്ല, എക്സിക്യൂട്ടബിളിന്റെ പാത്തും ഒത്തുനോക്കുക. മുൻ റൺ ബാക്കിയാക്കിയ പഴയ പ്രോസസ്സ് പതിവായി വരുന്ന വ്യാജനാണ്.

ആപ്ലിക്കേഷനിലൂടെ bind മാറ്റുക

ഫ്രെയിംവർക്കിന്റെ രേഖപ്പെടുത്തിയ കേൾക്കുന്ന വിലാസ ഓപ്ഷൻ ഉപയോഗിച്ച് പ്രോസസ്സ് പുനരാരംഭിക്കുക. ലാപ്ടോപ്പിന് സ്വകാര്യ വിലാസം 10.77.0.1 ഉണ്ടെങ്കിൽ, ഫോണിന്റെ URL http://10.77.0.1:8080/ ആകുന്നു, ആ വിലാസം VPN വഴി റൂട്ട് ചെയ്യണം; ക്രമീകരണത്തിൽ മറ്റൊന്നും മാറുന്നില്ല.

bind നിർബന്ധിക്കാൻ Windows-ലേക്ക് ഏകപക്ഷീയ വിലാസങ്ങൾ ചേർക്കരുത്, ഗേറ്റ്വേ മാറ്റരുത്. ആ മാറ്റങ്ങൾ ഡീബഗ്ഗിംഗ് സെഷനു ശേഷവും നിലനിൽക്കും, അടുത്ത വ്യക്തിയെ അത്ഭുതപ്പെടുത്തും. VPN വിലാസം ഉണ്ടാകുന്നതിന് മുമ്പ് ആരംഭിച്ച സർവറിനും bind ചെയ്യാനാകാതെ വരാം, അതിനാൽ താൽക്കാലിക ഇന്റർഫേസിന് ആരംഭ ക്രമം പ്രധാനമാണ്. അതിന് വീണ്ടും ശ്രമിക്കാനിട നൽകുക അല്ലെങ്കിൽ ടണലിന് ശേഷം ആരംഭിക്കുക. ബൂട്ടിൽ bind പരാജയം അടുത്ത ദിവസം രാവിലെ കൃത്യമായി ഫയർവാൾ പ്രശ്നം പോലെ തോന്നും.

HTTPS-ന് സേവനത്തിന്റെ ഹോസ്റ്റ്നാമും സർട്ടിഫിക്കറ്റ് സാധൂകരണവും അതേപടി നിലനിർത്തുക. അസംസ്കൃത വിലാസത്തിലെ സർട്ടിഫിക്കറ്റ് മുന്നറിയിപ്പ് ഒരു നാമകരണ പ്രശ്നമാണ്, ക്ലിക്ക് ചെയ്ത് കടക്കേണ്ട ഘട്ടമല്ല, കൂടാതെ സ്വകാര്യ DNS നിങ്ങൾ തിരഞ്ഞെടുത്ത ശ്രോതാവുമായി ഒത്തുപോകണം.

ഒരു നിയമം തുറക്കുക, മുഴുവൻ നെറ്റ്വർക്കുമല്ല

സോക്കറ്റ് VPN വിലാസത്തിൽ സ്വീകരിക്കാൻ തുടങ്ങിയാൽ, അഭ്യർത്ഥന എത്തുമോ എന്ന് ഫയർവാൾ തീരുമാനിക്കുന്നു. ഈ ആപ്ലിക്കേഷൻ, ഈ പ്രോട്ടോക്കോൾ, ഈ പ്രാദേശിക പോർട്ട്, അനുവദനീയമായ ദൂര സ്രോതസ്സ് എന്നിവയിലേക്ക് നിയമം പരിമിതപ്പെടുത്തുക, VPN അഡാപ്റ്ററിൽ ഏത് പ്രൊഫൈൽ സജീവമാണെന്ന് സ്ഥിരീകരിക്കുക.

Windows യഥാർത്ഥത്തിൽ കാണുന്ന സ്രോതസ്സ് വിലാസം ഉപയോഗിക്കുക, ഗേറ്റ്വേ നടത്തുന്ന ഏത് വിവർത്തനവും ഉൾപ്പെടെ, കാരണം യഥാർത്ഥ ക്ലയന്റ് വിലാസത്തിനായി എഴുതിയ നിയമം വിവർത്തനം ചെയ്തതുമായി ഒത്തുപോകില്ല.

ലോഡ് ചെയ്ത് ആപ്ലിക്കേഷൻ പിശക് കാണിക്കുന്ന പേജ് പുരോഗതിയാണ്: HTTP നിരസിക്കൽ TCP കണക്ഷൻ ഇല്ലാത്തതിൽ നിന്ന് വ്യത്യസ്തമായ പരാജയമാണ്, അടുത്ത അന്വേഷണം നെറ്റ്വർക്കിന്റേതല്ല, ആപ്ലിക്കേഷന്റെ സ്വന്തം ആക്സസ് നയത്തിന്റേതാണ്.

ഉദ്ദേശിച്ച ഫോണിൽ നിന്ന് പേജ് അഭ്യർത്ഥിച്ചും ഒഴിവാക്കിയ ഉപകരണത്തിന് ഇപ്പോഴും അതിൽ എത്താനാകില്ലെന്ന് സ്ഥിരീകരിച്ചും അവസാനിപ്പിക്കുക. എല്ലാം അനുവദിക്കുന്ന നിയമത്തോടെ പ്രവർത്തിക്കുന്ന ശ്രോതാവ് അതേ ഫലമല്ല.