റൂട്ട് ചെയ്ത OpenVPN ടണലിലൂടെ പേരുകളുടെ തിരയൽ എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു

ഹോസ്റ്റ് വിലാസം കൊണ്ട് ping-ന് ഉത്തരം നൽകുന്നു, പേര് കൊണ്ടുള്ള ഓരോ തിരയലിലും പരാജയപ്പെടുന്നു. ടണൽ പ്രവർത്തിക്കുന്നു, റൂട്ടും നിലവിലുണ്ട്, അതിനാൽ സ്വാഭാവിക നിഗമനം VPN തെറ്റായി ക്രമീകരിച്ചു എന്നതാണ്. കൂടുതൽ ഉപയോഗപ്രദമായ നിഗമനം, ആ തിരയൽ ഒരിക്കലും റൂട്ട് ചെയ്യാവുന്നതായിരുന്നില്ല എന്നതാണ്: റൂട്ട് ചെയ്ത ടണൽ unicast IP കൊണ്ടുപോകുന്നു, എന്നാൽ ആ അന്വേഷണം മറുവശത്ത് ഇല്ലാത്ത ഒരു സെഗ്മെന്റിനെ തിരയുന്ന ബ്രോഡ്കാസ്റ്റ് ആയിരുന്നു. പാളികളുടെ പൊരുത്തക്കേട് കാണാമായി വന്നാൽ പരിഹാരങ്ങൾ സ്വയം ചെലവനുസരിച്ച് അണിനിരക്കും.

മിഥ്യ: പേരുകൾ പരാജയപ്പെടുന്നതിനാൽ ടണൽ തകർന്നിരിക്കുന്നു

രോഗലക്ഷണം വിശ്വസനീയമാണ്, കാരണം പേരിന്റെ പാളിക്ക് മുകളിലുള്ളതെല്ലാം പ്രവർത്തിക്കുന്നു. വിലാസങ്ങൾ റൂട്ട് ചെയ്യപ്പെടുന്നു, ഇന്റർഫേസ് പ്രവർത്തിക്കുന്നു, ഇണ ping-ന് ഉത്തരം നൽകുന്നു. പരാജയപ്പെട്ടത് പോയിന്റ്-ടു-പോയിന്റ് ലിങ്കിലൂടെ ഒരിക്കലും വഴിയില്ലാതിരുന്ന ഒരു കണ്ടെത്തൽ സംവിധാനമാണ്, അത് തകർന്ന ടണലിൽ നിന്ന് വ്യത്യസ്തമായ പ്രസ്താവനയാണ്. ഈ രണ്ട് പ്രസ്താവനകളെ വേർതിരിക്കുന്നതാണ് രോഗനിർണയത്തിന്റെ വലിയ ഭാഗം.

അതിനെ ടണൽ തകരാറായി കാണുന്നത് സഹായിക്കാനാകാത്ത പ്രൊഫൈൽ മാറ്റങ്ങളിലേക്ക് നയിക്കുന്നു. ഓപ്ഷനുകൾ ചേർക്കുന്നതോ എൻക്രിപ്ഷൻ മാറ്റുന്നതോ ക്ലയന്റ് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നതോ ബ്രോഡ്കാസ്റ്റിനെ ഉണ്ടായിരുന്നിടത്തു തന്നെ നിർത്തുന്നു.

പരിഹാരത്തിന്റെ പേര് പറയുന്നതിന് മുൻപ് പരാജയപ്പെട്ട സംവിധാനത്തിന്റെ പേര് പറയുക. ബ്രോഡ്കാസ്റ്റ് ഉപയോഗിക്കുന്ന തിരയലിന് സെഗ്മെന്റ് വേണം, റിസോൾവർ ഉപയോഗിക്കുന്ന തിരയലിന് ചോദിക്കാൻ ഒരു വിലാസം വേണം.

TUN എന്ത് കൊണ്ടുപോകുന്നു, എന്ത് കൊണ്ടുപോകുന്നില്ല

TUN ഉപകരണം ഒരു IP ഇന്റർഫേസാണ്, അതാണ് അതിനെ റൂട്ട് ചെയ്യാവുന്നതാക്കുന്നത്. OpenVPN ക്ലയന്റിന് ഒരു വിലാസവും റൂട്ടുകളുടെ കൂട്ടവും നൽകുന്നു, തുടർന്ന് ക്ലയന്റ് ഇണയ്ക്ക് ഡാറ്റാഗ്രാമുകൾ അയയ്ക്കുന്നു. ആ മാതൃകയിൽ ഓരോ ഹോസ്റ്റും ഓരോ ഫ്രെയിമും കേൾക്കുന്ന പങ്കിട്ട ലിങ്ക് ഒന്നും സൃഷ്ടിക്കുന്നില്ല.

കണ്ടെത്തൽ ട്രാഫിക് ആ മാതൃകയിൽ ഒട്ടും ചേരുന്നില്ല. പഴയ Windows പേരന്വേഷണങ്ങൾ, SSDP പ്രഖ്യാപനങ്ങൾ, mDNS അഭ്യർത്ഥനകൾ എന്നിവ ഒരു ലക്ഷ്യസ്ഥാനത്തിന് പകരം സെഗ്മെന്റിലെ എല്ലാവർക്കും അയയ്ക്കുന്നു. റൂട്ട് ചെയ്ത ലിങ്കിന് അയയ്ക്കാൻ «എല്ലാവരും» ഇല്ല. ആ സംവിധാനങ്ങളിൽ ഓരോന്നും പങ്കിട്ട മാധ്യമം അനുമാനിക്കുന്നു.

അതിനാൽ ടണൽ ആരോഗ്യകരമായിരിക്കാം, കണ്ടെത്തൽ പൂർണ്ണമായും പരാജയപ്പെടാം. ആരെങ്കിലും VPN ഡൗൺ ആണെന്ന് റിപ്പോർട്ട് ചെയ്യുമ്പോൾ മുറുകെ പിടിക്കേണ്ട വാക്യം ഇതാണ്.

ബ്രിഡ്ജിംഗ് അതിർത്തി നീക്കം ചെയ്താണ് പ്രവർത്തിക്കുന്നത്

TAP ഉപകരണം ഫ്രെയിമുകൾ കൊണ്ടുപോകുന്നു, ഒരു ബ്രിഡ്ജ് അതിനെ യഥാർത്ഥ LAN സെഗ്മെന്റുമായി ബന്ധിപ്പിക്കുന്നു. അപ്പോൾ ക്ലയന്റിന് ആ സെഗ്മെന്റിൽ വിലാസമുണ്ടാകും, അതിന്റെ ബ്രോഡ്കാസ്റ്റ് ട്രാഫിക് കേൾക്കും. അതുകൊണ്ടാണ് ബ്രിഡ്ജിംഗ് പേരിന്റെ പ്രശ്നം ഭേദമാക്കുന്നതായി തോന്നുന്നത്. ഇത് വിലാസനിർണ്ണയത്തിനായി ക്ലയന്റിനെ ആ സെഗ്മെന്റിനെ ആശ്രയിക്കുന്നതുമാക്കുന്നു.

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

ചെറിയ ലാബിന് ഇത് ന്യായമായ കൈമാറ്റമാണ്. വിതരണം ചെയ്ത ജനശക്തിക്ക് അപൂർവ്വമാണ്.

DNS-ഉം WINS-ഉം പുഷ് ചെയ്യുന്നതാണ് ഇടുങ്ങിയ പരിഹാരം

ക്ലയന്റിന് ചോദിക്കാൻ ഒരു നിർദ്ദിഷ്ട സ്ഥലം നൽകുക. dhcp-option DNS ഉം dhcp-option DOMAIN ഉം ആന്തരിക പേരുകളെ സോൺ അറിയുന്ന സെർവറിലേക്ക് തിരിച്ചുവിടുന്നു, NetBIOS-ൽ ഇപ്പോഴും ആശ്രയിക്കുന്ന Windows ക്ലയന്റിന് അതേ രീതിയിൽ WINS സെർവർ ലഭിക്കാം. ടണൽ റൂട്ട് ചെയ്തതായി തുടരുന്നു, സെഗ്മെന്റ് അതിന്റെ സ്ഥലത്ത് തുടരുന്നു.

ഇത് പ്രവർത്തിക്കുമോ എന്ന് രണ്ട് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു. പേരിട്ട സെർവർ സോണിന് വേണ്ടി ഉത്തരം നൽകണം, അന്വേഷണത്തിന് ടണലിലൂടെ അനുമതി ഉണ്ടായിരിക്കണം.

റിസോൾവർ സെർവറിന്റെ സ്വന്തം ഷെല്ലിൽ നിന്നല്ല, ക്ലയന്റിൽ നിന്ന് പരിശോധിക്കുക. പ്രാദേശികമായി പ്രവർത്തിക്കുന്ന റിസോൾവർ ടണൽ എന്ത് കൊണ്ടുപോകുന്നു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

ഏത് പാളി പരാജയപ്പെട്ടു എന്ന് കണ്ടെത്തുക

ആദ്യം വിലാസത്തിന് ping ചെയ്യുക, പിന്നീട് പേര് റിസോൾവ് ചെയ്ത് ഏത് സെർവർ ഉത്തരം നൽകി എന്ന് വായിക്കുക. സോൺ ഹോസ്റ്റ് ചെയ്യാത്ത സെർവറിന്റെ നിഷേധാത്മക ഉത്തരം, യന്ത്രത്തിൽ നിന്ന് ഒരിക്കലും പുറത്തുപോകാത്ത അന്വേഷണത്തിൽ നിന്ന് വ്യത്യസ്തമായി തോന്നുന്നു. റിസോൾവ് ചെയ്യുന്നതും എന്നാൽ കണക്ഷനുകൾ നിരസിക്കുന്നതുമായ പേര് തികച്ചും മൂന്നാമത്തെ പ്രശ്നമാണ്.

മൾട്ടികാസ്റ്റ് അതേ മതിലിന് പിന്നിലാണ്. 224.0.0.251 പോലുള്ള ഒരു ഗ്രൂപ്പ് സ്വതവേ റൂട്ട് ചെയ്ത ടണലിലൂടെ കൈമാറ്റം ചെയ്യപ്പെടുന്നില്ല, മൾട്ടികാസ്റ്റ് മനസ്സിലാക്കുന്ന വഴിയോ LAN-ലെ പ്രതിഫലനിയോ ഇല്ലാതെ ഗ്രൂപ്പിനുള്ള റൂട്ട് പര്യാപ്തമല്ല.