OpenVPN വഴി LAN ഗെയിം ലിസ്റ്റ് ശൂന്യമോ? കണ്ടെത്തൽ പാത പരിശോധിക്കുക

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

ഒരു സെഷനിൽ ചേരുന്നതിനെ അത് കണ്ടെത്തുന്നതിൽ നിന്ന് വേർതിരിക്കുക

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

VPN കോൺഫിഗറേഷൻ തൊടുന്നതിന് മുമ്പ് ഫലം എഴുതിവയ്ക്കുക. ഇത് മുഴുവൻ അന്വേഷണത്തിലെയും ഏറ്റവും വിലകുറഞ്ഞ പരീക്ഷണമാണ്, ഡിസൈൻ ഇടത്തിന്റെ പകുതി ഇത് ഒഴിവാക്കുന്നു. നിങ്ങൾ ഉപയോഗിച്ച വിലാസവും രേഖപ്പെടുത്തുക, കാരണം അത് പിന്നീടുള്ള ഓരോ പരീക്ഷണത്തിന്റെയും റഫറൻസ് പോയിന്റാകും. നിങ്ങളുടെ കുറിപ്പുകളിൽ ആ വരി ഇല്ലെങ്കിൽ അടുത്ത താരതമ്യം ഊഹമാണ്.

ടണൽ തൊടുന്നതിന് മുമ്പ് നേരിട്ടുള്ള ചേരൽ പരീക്ഷിക്കുക

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

കണ്ടെത്തൽ പോർട്ടും സെഷൻ പോർട്ടും ഒരേ സംഖ്യയാണെന്ന് കരുതരുത്. ഗെയിമുകൾ സാധാരണയായി ഒരു UDP പോർട്ടിൽ പ്രഖ്യാപിക്കുകയും മറ്റൊന്നിൽ കളിക്കാരെ സ്വീകരിക്കുകയും ചെയ്യുന്നു, തെറ്റായ പോർട്ടിനായി നിർമ്മിച്ച റിലേ ഇപ്പോഴും ശൂന്യമായി നിൽക്കുന്ന ലിസ്റ്റ് നൽകുന്നു.

ഹോസ്റ്റിംഗ് പ്രോസസ് ഏത് അഡാപ്റ്റർ തിരഞ്ഞെടുത്തു എന്നും പരിശോധിക്കുക. വീട്ടിലെ LAN വിലാസത്തിൽ ബന്ധിപ്പിച്ച പ്രോസസ് ആ വിലാസം പ്രഖ്യാപിക്കും, പ്രഖ്യാപനം എത്തിയാലും വിദൂര കളിക്കാരന് അവിടേക്ക് റൂട്ട് ചെയ്യാനാകില്ല. ലിസ്റ്റ് നിറയാം, ആ കാരണം കൊണ്ട് മാത്രം ചേരൽ പരാജയപ്പെടാം.

ബ്രോഡ്കാസ്റ്റ് എവിടെ നിൽക്കുന്നു എന്ന് മനസ്സിലാക്കുക

റൂട്ട് ചെയ്ത TUN ടണൽ പിയറുകൾക്കിടയിൽ IP പാക്കറ്റുകൾ കൊണ്ടുപോകുന്നു, ഓരോ പിയറിന്റെയും നെറ്റ്വർക്കിൽ പ്രാദേശിക ബ്രോഡ്കാസ്റ്റ് പുനർനിർമ്മിക്കുന്നില്ല. പരിമിത ബ്രോഡ്കാസ്റ്റ് വിലാസം 255.255.255.255 അത് പുറപ്പെടുവിക്കുന്ന ഇന്റർഫേസിനുള്ളിൽ തന്നെ നിൽക്കുന്നു, കൂടാതെ സബ്നെറ്റിലേക്ക് നയിക്കുന്ന ബ്രോഡ്കാസ്റ്റ് വേറിട്ട ഒരു കേസാണ്, റൂട്ടറുകൾക്ക് പ്രഖ്യാപനങ്ങൾ കൊണ്ട് വെള്ളപ്പൊക്കം ഉണ്ടാക്കാനുള്ള പൊതു അനുമതിയല്ല.

ഇത് ഡിസൈനിന്റെ സ്വഭാവമാണ്, ഒരു ഓപ്ഷൻ കൊണ്ട് പാച്ച് ചെയ്യേണ്ട വീഴ്ചയല്ല. OpenVPN എന്നതിന്റെ client-to-client ക്രമീകരണം ടണലിനുള്ളിലെ പിയർ ട്രാഫിക് നിയന്ത്രിക്കുന്നു, അത് കണ്ടെത്തൽ റിലേ അല്ല; പല ത്രെഡുകളിലും ഈ ആവശ്യത്തിന് ഇത് നിർദ്ദേശിക്കപ്പെടുന്നുണ്ടെങ്കിലും. റിലേ എന്നത് സ്വന്തം കോൺഫിഗറേഷനും സ്വന്തം പരാജയ മോഡുകളുമുള്ള വേറിട്ട ഘടകമാണ്. നിലവിലുള്ള ഒരു ഓപ്ഷൻ ഇത് ഇതിനകം ഉൾക്കൊള്ളുന്നു എന്ന അനുമാനമാണ് ഈ അന്വേഷണം കുടുങ്ങാനുള്ള ഏറ്റവും സാധാരണ കാരണം.

മൾട്ടികാസ്റ്റ് കണ്ടെത്തലിന് വേറെ വിലാസ വർഗ്ഗത്തോടെ അതേ പ്രശ്നമുണ്ട്, അതിന് ബ്രോഡ്കാസ്റ്റ് ഒഴിവാക്കലിന് പകരം മൾട്ടികാസ്റ്റ് റൂട്ടിംഗ് അല്ലെങ്കിൽ റിലേ വേണം.

റിലേ ന്യായീകരിക്കപ്പെടുമ്പോൾ അത് ഇടുങ്ങിയതായി നിർത്തുക

സ്വയമേവയുള്ള കണ്ടെത്തൽ ആവശ്യമാണെങ്കിൽ, ആദ്യം യഥാർത്ഥ കൈമാറ്റം തിരിച്ചറിയുക: ബ്രോഡ്കാസ്റ്റോ മൾട്ടികാസ്റ്റോ, ലക്ഷ്യ വിലാസം, UDP പോർട്ട്, അത് അയയ്ക്കുന്ന ഇന്റർഫേസ്, മറുപടിയിലെ വിലാസം. ഈ അഞ്ച് വസ്തുതകളിൽ പരിമിതപ്പെടുത്തിയ പ്രോട്ടോക്കോളിന് അനുയോജ്യമായ റിലേ മുഴുവൻ Ethernet സെഗ്മെന്റും വികസിപ്പിക്കുന്നതിനേക്കാൾ വളരെ ഇടുങ്ങിയതാണ്.

പാക്കറ്റ് മാറ്റമില്ലാതെ കൈമാറുന്നത് മതിയാകണമെന്നില്ല. പേലോഡ് സ്വീകർത്താവിനോട് എത്തിച്ചേരാനാകാത്ത ഒരു വിലാസത്തിലേക്ക് കണക്ട് ചെയ്യാൻ പറഞ്ഞാൽ, റിലേ ഉപയോഗശൂന്യമായ മറുപടി നൽകുന്നു, അതിനാൽ ഏതെങ്കിലും റിലേ ഉണ്ടാകുന്നതിന് മുമ്പ് ഗെയിമിന്റെ സ്വന്തം ഇന്റർഫേസോ പ്രഖ്യാപിത വിലാസ ക്രമീകരണമോ പരീക്ഷിക്കണം.

റിലേ അത് ആവശ്യമുള്ള ഇന്റർഫേസുകളിലേക്കും പിയറുകളിലേക്കും പരിമിതപ്പെടുത്തുക, മറുപടികൾ ആവശ്യക്കാരനെ എങ്ങനെ കണ്ടെത്തുന്നു എന്ന് നിർവചിക്കുക. ബന്ധമില്ലാത്ത ബ്രോഡ്കാസ്റ്റുകൾ ആവർത്തിക്കുന്നത് മറ്റ് പ്രാദേശിക സേവനങ്ങളെ തുറന്നുകാട്ടുകയും പിന്നീട് ഡീബഗ് ചെയ്യാൻ പ്രയാസമുള്ള ലൂപ്പുകൾ സൃഷ്ടിക്കുകയും ചെയ്യുന്നു.

ഡിസൈനിന് Ethernet ആവശ്യമുള്ളപ്പോൾ മാത്രം ബ്രിഡ്ജ് ചെയ്യുക

Ethernet ഫ്രെയിമുകൾ TAP-നുള്ളിൽ സഞ്ചരിക്കുന്നു, അതിനാൽ ഒരു TAP ടണൽ ബോധപൂർവ്വം ബ്രിഡ്ജ് ചെയ്ത ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്നിൽ ഉൾപ്പെടാം. വെറുതെ dev tun എന്നത് dev tap ആക്കി മാറ്റുന്നത് ആ ബ്രിഡ്ജ് നിർമ്മിക്കുന്നില്ല, സെർവർ കോൺഫിഗറേഷൻ പൊരുത്തപ്പെടുന്നില്ല, ആപ്ലിക്കേഷനെ പുതിയ ഇന്റർഫേസ് തിരഞ്ഞെടുക്കാൻ പ്രേരിപ്പിക്കുന്നുമില്ല. OpenVPN ബ്രിഡ്ജിംഗ് ഗൈഡ് ഒരു ശൂന്യമായ ലോബിക്കുള്ള ചികിത്സയല്ല, വിശാലമായ ക്രമീകരണം വിവരിക്കുന്നു.

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

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