ആരോ ഒരു പോർട്ട് പരിശോധന നടത്തുന്നു, തുറന്നിരിക്കുന്നു എന്ന വാക്ക് കാണുന്നു, സെർവർ പരിഹരിക്കപ്പെട്ടതായി കരുതുന്നു. ആ ഫലത്തിന്റെ യഥാർത്ഥ അർത്ഥം ഇടുങ്ങിയതാണ്: ചെക്കറിന്റെ സ്ഥാനത്തുനിന്ന്, ആ നിമിഷത്തിൽ, ആ വിലാസത്തിലേക്കും പോർട്ടിലേക്കും ഒരു TCP കണക്ഷൻ സ്വീകരിച്ചു. Minecraft പ്രോട്ടോക്കോൾ ഹാൻഡ്ഷേക്ക്, അക്കൗണ്ട് പ്രാമാണീകരണം, അല്ലെങ്കിൽ സെർവർ കളിക്കാരനെ ഒരു ലോകത്തിലേക്ക് അനുവദിച്ചുവോ എന്നിവയെക്കുറിച്ച് ഇത് ഒന്നും പറയുന്നില്ല.

ഇവ നാല് വ്യത്യസ്ത പാളികളാണ്, അവയിലേതിലെങ്കിലും പരാജയം കളിക്കാരനിൽനിന്ന് അതേ വാക്യം ഉണ്ടാക്കുന്നു: അത് പ്രവർത്തിച്ചില്ല.

ഒരു പ്രോബ് കാണാൻ കഴിയുന്നത് മാത്രം പരിശോധിക്കുന്നു

TCP കണക്ഷൻ പൂർത്തിയാകുന്നത് ഇരു വശങ്ങളും ത്രീ-വേ ഹാൻഡ്ഷേക്ക് പൂർത്തിയാക്കുമ്പോഴാണ്, അത് ഗെയിമിന് അറിയാവുന്ന എല്ലാത്തിനും താഴെയാണ്. പ്രോബ് ഒരു ശ്രോതാവ് ഉണ്ടായിരുന്നു എന്നും അത് അതിന്റെ നെറ്റ്വർക്ക് സ്ഥാനത്തുനിന്ന് പ്രതികരിച്ചു എന്നും റിപ്പോർട്ട് ചെയ്യുന്നു. ശ്രോതാവ് ഗെയിമാണെന്ന് അതിന് പറയാൻ കഴിയില്ല, കാരണം ഏത് പ്രോസസ്സിനും ഒരു പോർട്ട് എടുത്ത് കണക്ഷനുകൾ സ്വീകരിക്കാം.

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

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

സോക്കറ്റും കളിക്കാരനും ഇടയിൽ നാല് പാളികൾ

ചേരുന്ന ക്ലയന്റ് യഥാർത്ഥത്തിൽ നിർവ്വഹിക്കുന്ന ക്രമം സങ്കൽപ്പിക്കുക. ആദ്യം അത് വിലാസം പരിഹരിക്കുന്നു, പിന്നെ പ്രസിദ്ധീകരിച്ച പോർട്ടിലേക്ക് TCP കണക്ഷൻ തുറക്കുന്നു, പിന്നെ ചർച്ചയ്ക്കും പ്രാമാണീകരണത്തിനുമായി ഗെയിമിന്റെ സ്വന്തം പ്രോട്ടോക്കോൾ സംസാരിക്കുന്നു, ഒടുവിൽ സെർവർ ആ ഐഡന്റിറ്റിക്ക് ലോകത്തിലേക്ക് പ്രവേശനം അനുവദിക്കണോ എന്ന് തീരുമാനിക്കുന്നു. ഓരോ പാളിക്കും സ്വന്തം പരാജയ ഒപ്പുണ്ട്, ആദ്യത്തേത് മാത്രമാണ് പോർട്ട് ചെക്കറിന് ദൃശ്യമാകുന്നത്.

Java Edition ന്റെ സ്ഥിരസ്ഥിതി പോർട്ട് 25565 ആണ്, പക്ഷേ ഓപ്പറേറ്റർക്ക് മറ്റൊരു ബാഹ്യ പോർട്ട് പ്രസിദ്ധീകരിച്ച് അത് ഉള്ളിലേക്ക് ഫോർവേഡ് ചെയ്യാം, അതിനാൽ കളിക്കാരൻ ടൈപ്പ് ചെയ്യുന്ന സംഖ്യ സെർവർ കാണുന്ന സംഖ്യ തന്നെയായിരിക്കണമെന്നില്ല. തെറ്റായ ബാഹ്യ പോർട്ടിലേക്ക് ലക്ഷ്യമിട്ട ചെക്കർ സെർവർ തികച്ചും ആരോഗ്യകരമായിരിക്കുമ്പോൾ അടച്ചിരിക്കുന്നു എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, ഇതാണ് ഈ മേഖലയിലെ ഏറ്റവും സാധാരണമായ തെറ്റായ അലാറം.

പേരുകൾ പോർട്ടിന് മുകളിൽ ഒരു ഘട്ടം കൂടി ചേർക്കുന്നു. കളിക്കാരൻ ഒരു ഹോസ്റ്റ്നെയിം ടൈപ്പ് ചെയ്താൽ, പരിഹാരം പ്രസിദ്ധീകരിച്ച വിലാസം തിരികെ നൽകണം, നെറ്റ്വർക്കിനുള്ളിലെ ഒരു മെഷീനിൽ അത് പകരം ഒരു സ്വകാര്യ വിലാസം നൽകിയേക്കാം. അത് ഫയർവാൾ പരാജയമല്ല, എത്ര പോർട്ട് ഫോർവേഡിംഗും അത് മാറ്റില്ല.

ഉള്ളിലെ കളിക്കാരൻ എന്തുകൊണ്ട് വേറെ വഴി എടുക്കുന്നു

അതേ LAN-ലോ ആ LAN-ലേക്ക് എത്തുന്ന VPN-ലോ ഉള്ള കളിക്കാരൻ ഉള്ളിൽനിന്ന് പൊതു വിലാസത്തിലേക്ക് എത്താൻ ശ്രമിക്കുന്നു. അഭ്യർത്ഥന റൂട്ടറിന്റെ ബാഹ്യ വിലാസത്തിലേക്ക് പോകുന്നു, റൂട്ടർ അത് തിരികെ ഉള്ളിലേക്ക് വിവർത്തനം ചെയ്യണം, ഇതിനെ സാധാരണയായി hairpinning അല്ലെങ്കിൽ NAT പ്രതിഫലനം എന്ന് വിളിക്കുന്നു. ഇത് പ്രവർത്തിക്കാൻ മുന്നോട്ടുള്ള വിവർത്തനവും തിരിച്ചുള്ള വഴിയും ഒത്തുപോകണം, ഒട്ടേറെ ഗാർഹിക റൂട്ടറുകൾ ഇത് ഒട്ടും നടപ്പാക്കുന്നില്ല.

അതുകൊണ്ടാണ് പുറത്തുനിന്നുള്ള അതിഥി ചേരുന്നതും സെർവറിന് അടുത്തിരിക്കുന്ന ആൾക്ക് ചേരാൻ കഴിയാത്തതും. ബാഹ്യ വഴി യഥാർത്ഥത്തിൽ കുഴപ്പമില്ല; പരാജയപ്പെടുന്നത് ആന്തരിക വളവഴിയാണ്, അത് കളിക്കാരന്റെ സ്ക്രീനിൽനിന്ന് സെർവർ പ്രശ്നമായി തോന്നുന്ന രീതിയിൽ പരാജയപ്പെടുന്നു. ഏതാണ് സംഭവിച്ചതെന്ന് സെർവറിന്റെ സ്വന്തം ലോഗ് തീരുമാനിക്കുന്നു, ഒരിക്കലും വിവർത്തനം ചെയ്യപ്പെടാത്ത കണക്ഷൻ ഒരിക്കലും അതിൽ എത്തുന്നില്ല.

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

Netgate ന്റെ NAT പ്രതിഫലന രേഖകൾ ബാഹ്യവും ആന്തരികവും തമ്മിലുള്ള വ്യത്യാസവും split-DNS ബദലും കൂടുതൽ വിശദമായി വിവരിക്കുന്നു. അത് സംവിധാനത്തിന്റെ വിവരണമായി വായിക്കുക, ഏതെങ്കിലും പ്രത്യേക VPN ദാതാവോ റൂട്ടറോ എല്ലാ loopback വകഭേദങ്ങളും പിന്തുണയ്ക്കുന്നു എന്ന വാഗ്ദാനമായി അല്ല.

ഓരോ കാഴ്ചപ്പാടിൽനിന്നും തെളിവുകൾ ശേഖരിക്കുക

ഓരോ പരിശോധനയ്ക്കും ആരാണ് നടത്തിയത്, എവിടെനിന്ന്, ഏത് സമയത്ത്, ഏത് വിലാസത്തിനും പോർട്ടിനുമെതിരെ, സെർവർ എന്താണ് ലോഗ് ചെയ്തത് എന്നിവ എഴുതുക. സെർവർ കൺസോളിൽ വ്യക്തമായ കാരണത്തോടെയുള്ള ഗെയിം നിരസിക്കൽ ഒരിക്കലും എത്താത്ത കണക്ഷനിൽനിന്ന് വ്യത്യസ്തമായ കണ്ടെത്തലാണ്, രണ്ടും വിപരീത ദിശകളിലേക്ക് നയിക്കുന്നു.

അനുവദിക്കപ്പെട്ട വിദൂര കളിക്കാർ ചേരുകയും ഒരു പ്രാദേശിക കളിക്കാരന് ചേരാൻ കഴിയാതിരിക്കുകയും ചെയ്താൽ, ബാക്കിയുള്ള ചോദ്യം പ്രാദേശിക വഴിയാണ്, അത് സ്വന്തം അന്വേഷണത്തിന് അർഹമാണ്: ക്ലയന്റ് ഏത് വിലാസം ഉപയോഗിച്ചു, റൂട്ടർ വിവർത്തനത്തിൽ എന്ത് ചെയ്തു, സെർവർ എന്തെങ്കിലും കണക്ഷൻ ശ്രമം രേഖപ്പെടുത്തിയോ. പോർട്ടുകൾ ക്രമരഹിതമായി വീണ്ടും തുറക്കുന്നതിനുപകരം ഈ മൂന്ന് വസ്തുതകൾ നെറ്റ്വർക്ക് ഉടമയ്ക്ക് നൽകുക.

അനുബന്ധ ലേഖനങ്ങൾ