JConsole രജിസ്ട്രിയിലേക്ക് കണക്റ്റ് ചെയ്യുന്നു, പിന്നീട് RMI അതിനെ മറ്റൊരിടത്തേക്ക് അയയ്ക്കുന്നു

ടണൽ വഴി രജിസ്ട്രി പോർട്ടിലേക്ക് കണക്റ്റ് ചെയ്യുക, ഹാൻഡ്ഷേക്ക് തുടങ്ങുന്നത് കാണുക, പിന്നീട് JConsole എങ്കിലും സമയം കഴിഞ്ഞ് നിൽക്കുന്നത് കാണുക. ഇത് സംഭവിക്കുന്നതിന് കാരണം ആദ്യ TCP കണക്ഷൻ മാനേജ്മെന്റ് കണക്ഷനല്ല: അത് ഒരു തിരയലാണ്. RMI രജിസ്ട്രി ഒരു ഹോസ്റ്റും രണ്ടാമത്തെ പോർട്ടും പേരിടുന്ന ഒരു റഫറൻസോടെ മറുപടി നൽകുന്നു, പിന്നീട് JConsole പറഞ്ഞ സ്ഥലത്തേക്ക് പോകുന്നു. ടണൽ സെർവറിന്റെ ആദ്യ പോർട്ടിൽ മാത്രം എത്തുന്നുവെങ്കിൽ, അല്ലെങ്കിൽ റഫറൻസ് സെർവറിന്റെ സ്വന്തം പ്രാദേശിക നെറ്റ്വർക്കിൽ മാത്രം ഉള്ള വിലാസം പേരിടുന്നുവെങ്കിൽ, ക്ലയന്റ് ബാഹ്യമായി വിജയിച്ചതിന് ശേഷം നിലയ്ക്കുന്നു.

കെട്ടുകഥ: ഒരു തുറന്ന പോർട്ട് എന്നത് ഒരു കണക്ഷനാണ്

RMI വഴി ദൂരസ്ഥ JMX കുറഞ്ഞത് രണ്ട് അന്ത്യബിന്ദുക്കൾ ഉൾക്കൊള്ളുന്നു, അവ സിസ്റ്റത്തിന്റെ വ്യത്യസ്ത ഭാഗങ്ങൾ തിരഞ്ഞെടുക്കുന്നു. രജിസ്ട്രി പോർട്ട് നിങ്ങൾ ക്ലയന്റിൽ ടൈപ്പ് ചെയ്യുന്നതാണ്, അത് യഥാർത്ഥ കണക്ടറെ വിവരിക്കുന്ന stub നൽകാൻ നിലകൊള്ളുന്നു. ആദ്യത്തെ വിജയകരമായ സോക്കറ്റിനെ മാനേജ്മെന്റ് പാത തുറന്നിരിക്കുന്നതിന്റെ തെളിവായി കണക്കാക്കുന്നത് രണ്ട് മിനിറ്റ് നീളുന്ന രോഗനിർണയത്തെ ഫയർവാൾ ടിക്കറ്റുകൾ നിറഞ്ഞ ഒരു ഉച്ചയാക്കി മാറ്റുന്നു.

സെർവറിന്റെ കേൾക്കുന്നവരുടെ പട്ടികയ്ക്ക് പകരം ക്ലയന്റിന്റെ സ്വന്തം പിശക് നോക്കുക. ഹാൻഡ്ഷേക്ക് തുടങ്ങിയതിന് ശേഷമുള്ള പരാജയം രണ്ടാമത്തെ കണക്ഷൻ പൂർത്തിയായില്ലെന്ന് പറയുന്നു, ആദ്യത്തേതല്ല.

രജിസ്ട്രി എന്ത് തിരികെ നൽകുന്നു

stub ഒരു വിലാസവും പോർട്ടും ഉൾക്കൊള്ളുന്നു, അവ കണക്ടർ സൃഷ്ടിച്ച നിമിഷത്തിൽ ക്രമീകരിച്ചതാണ്. പല ഇന്റർഫേസുകളുള്ള സെർവറിൽ, പ്രാദേശിക നെറ്റ്വർക്കിൽ നിന്ന് എത്താവുന്നതും നിങ്ങളുടേതിൽ നിന്ന് എത്താനാകാത്തതുമായ വിലാസം സ്റ്റാക്ക് തിരഞ്ഞെടുത്തിരിക്കാം. ക്ലയന്റിന് വ്യത്യാസം അറിയില്ല; അത് ലഭിച്ച മൂല്യം തന്നെ ഡയൽ ചെയ്യുന്നു, പാക്കറ്റ് ആ വിലാസത്തിനായി നിലവിലുള്ള പാത പിന്തുടരുന്നു, VPN ക്ലയന്റിൽ അത് പലപ്പോഴും ഒന്നുമല്ല. രണ്ടാമത്തെ കണക്ഷൻ ശ്രമിക്കുന്ന നിമിഷം അതാണ്.

പരാജയം പരിതസ്ഥിതികൾക്കിടയിൽ ഇടയ്ക്കിടെ സംഭവിക്കാനുള്ള കാരണവും ഇതാണ്: അതേ സെർവർ JMX കോൺഫിഗറേഷനിൽ യാതൊരു മാറ്റവുമില്ലാതെ പ്രാദേശിക നെറ്റ്വർക്കിലെ ഉപയോക്താവിനും ടണലിലെ ഉപയോക്താവിനും വ്യത്യസ്തമായി പെരുമാറാം.

രണ്ട് പോർട്ടുകളും അവയെ ഉറപ്പിക്കുന്ന രണ്ട് ഗുണങ്ങളും

രജിസ്ട്രി പോർട്ട് com.sun.management.jmxremote.port ൽ നിന്ന് വരുന്നു, കണക്ടറെ സ്റ്റാക്ക് അനുവദിക്കുന്നതിന് വിടാതെ com.sun.management.jmxremote.rmi.port ഉപയോഗിച്ച് ഉറപ്പിക്കാം. ക്ലയന്റും സെർവറും തമ്മിൽ ഫയർവാൾ അല്ലെങ്കിൽ സുരക്ഷാ ഗ്രൂപ്പ് ഉള്ളപ്പോൾ രണ്ടും വ്യക്തമായി സജ്ജമാക്കുക, കാരണം പ്രവചിക്കാനാകാത്ത രണ്ടാമത്തെ പോർട്ട് മുൻകൂട്ടി അനുവദിക്കാനാവില്ല, അതിനെ ഉൾക്കൊള്ളാൻ തുറക്കുന്ന വിശാലമായ ശ്രേണി ഒരു മൂല്യം ഉറപ്പിക്കുന്നതിനേക്കാൾ മോശമാണ്.

പിന്നീട് സെർവറിൽ ss -ltn അല്ലെങ്കിൽ netstat -an ഉപയോഗിച്ച് രണ്ട് പോർട്ടുകളും കേൾക്കുന്നുണ്ടോ, ഏത് വിലാസങ്ങളിൽ എന്ന് ഉറപ്പാക്കുക. loopback-ലേക്ക് ബന്ധിച്ച കേൾവിക്കാരൻ പ്രാദേശിക വിന്യാസത്തിന് മാത്രം ശരിയാണ്, ഇതിന് ഉപയോഗശൂന്യമാണ്.

പ്രഖ്യാപിത പേര് തെറ്റായിരിക്കുമ്പോൾ

ദൂരസ്ഥ റഫറൻസിൽ കാണുന്ന ഹോസ്റ്റ് പേര് java.rmi.server.hostname നിർണ്ണയിക്കുന്നു. ഇത് stub എന്ത് പ്രഖ്യാപിക്കുന്നു എന്നതിനെ സ്വാധീനിക്കുന്നു; ഇത് സ്വയം ഓരോ കേൾവിക്കാരനെയും ഒരു ഇന്റർഫേസിലേക്ക് ബന്ധിക്കാനുള്ള നിർദ്ദേശമല്ല, അതിനാൽ അത് സജ്ജമാക്കുന്നത് എപ്പോഴും പ്രതീക്ഷിക്കുന്ന ഒറ്റ-പോർട്ട് സ്വഭാവം നൽകുന്നില്ല. അത് സജ്ജമാക്കുക, പ്രക്രിയ പുനരാരംഭിക്കുക, പിന്നീട് stub യഥാർത്ഥത്തിൽ എന്ത് ഉൾക്കൊള്ളുന്നു എന്ന് പരിശോധിക്കുക. ക്ലയന്റിന് പരിഹരിക്കാനാകുന്നതും ടണൽ വഴി എത്താനാകുന്നതുമായ പേരോ വിലാസമോ തിരഞ്ഞെടുക്കുക, stub വീണ്ടും നിർമ്മിക്കപ്പെടാൻ പ്രക്രിയ പുനരാരംഭിക്കുക.

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

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

ലളിതമാക്കാൻ മാനേജ്മെന്റ് സുരക്ഷ ഓഫ് ചെയ്യരുത്

പ്രാമാണീകരണവും TLS-ഉം ഓഫ് ചെയ്യുന്ന സ്നിപ്പറ്റുകൾ എളുപ്പത്തിൽ കണ്ടെത്താം, അവ പിന്നീട് പിൻവലിക്കേണ്ട രീതിയിൽ കണക്ഷൻ പ്രവർത്തിപ്പിക്കുന്നു. ദൂരസ്ഥ JMX എന്നത് അത് പരിശോധിക്കുന്ന പ്രക്രിയയ്ക്ക് തുല്യമായ അധികാരങ്ങളുള്ള ഒരു മാനേജ്മെന്റ് ഇന്റർഫേസാണ്; അതിന്റെ ആക്സസ് നിയന്ത്രണങ്ങൾ നിലനിർത്തുക, ക്ലയന്റിന് ക്രെഡൻഷ്യലുകൾ നൽകാനാകുന്നില്ലെങ്കിൽ അത് തന്നെ ശരിയാക്കുക.

അന്ത്യബിന്ദുക്കൾ ശരിയായതിന് ശേഷം, അടുത്തതായി നിങ്ങൾ കാണുന്ന പിശക് സൂക്ഷിക്കുക. ട്രസ്റ്റ് സ്റ്റോർ അല്ലെങ്കിൽ അക്കൗണ്ടിൽ നിന്നുള്ള നിരാകരണം എത്താനാകാത്ത കണക്ടറിനേക്കാൾ പിന്നീടുള്ള ഘട്ടമാണ്, അതായത് നെറ്റ്വർക്ക് ജോലി തീർന്നു.