VPN-ലെ NetBIOS: പേര്, ഡാറ്റാഗ്രാം, സെഷൻ വേറിട്ട സേവനങ്ങളാണ്
റൗട്ടറുകളെക്കുറിച്ചുള്ള മുദ്രാവാക്യം വളരെ വിശാലമാണ്. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ മൂന്ന് സേവനങ്ങളിൽ ഏതാണ് ഉപയോഗിക്കുന്നതെന്നും, പേരുകൾ പ്രക്ഷേപണത്തിലൂടെയാണോ സെർവറിലൂടെയാണോ പരിഹരിക്കുന്നതെന്നും പരിശോധിക്കുക.
«NetBIOS റൗട്ടറുകൾ കടക്കുന്നില്ല» എന്ന വാക്യം രൂപകൽപ്പന തീർപ്പാക്കിയതുപോലെ ആവർത്തിക്കപ്പെടുന്നു. അത് തീർപ്പാക്കിയിട്ടില്ല. പ്രക്ഷേപണത്തിലൂടെയുള്ള പേരന്വേഷണം സാധാരണയായി സ്വന്തം പ്രക്ഷേപണ മേഖലയ്ക്കുള്ളിൽ തുടരും, എന്നാൽ NetBIOS സേവനങ്ങൾക്ക് നന്നായി റൂട്ട് ചെയ്യപ്പെടുന്ന ലക്ഷ്യബദ്ധമായ IP ട്രാഫിക്കും ഉപയോഗിക്കാം. ഉപയോഗപ്രദമായ ചോദ്യം NetBIOS റൗട്ടറുകൾ കടക്കുന്നുണ്ടോ എന്നതല്ല; നിങ്ങളുടെ ആപ്ലിക്കേഷൻ അതിന്റെ മൂന്ന് സേവനങ്ങളിൽ ഏതാണ് ഉപയോഗിക്കുന്നതെന്നതാണ്.
ഒരു സോഫ്റ്റ്വെയർ ഇന്റർഫേസ്, ഒരു വയർ പ്രോട്ടോക്കോൾ അല്ല
RFC 1001 NetBIOS-നെ ആപ്ലിക്കേഷനുകൾ പ്രോഗ്രാം ചെയ്യുന്ന ഇന്റർഫേസായി വിവരിക്കുന്നു, അതിന് താഴെ നിരവധി ഗതാഗതങ്ങളുണ്ട്. അതിന്റെ TCP/UDP മാതൃക പേര് സേവനം, ഡാറ്റാഗ്രാം വിതരണം, സെഷൻ സേവനം എന്നിവ വേർതിരിക്കുന്നു, കൂടാതെ IP പ്രക്ഷേപണത്തോടെയും അല്ലാതെയും പ്രവർത്തനം വ്യക്തമായി പിന്തുണയ്ക്കുന്നു.
| Service | What it does | Transport dependence |
|---|---|---|
| Name | Registers and resolves names | Broadcast, point-to-point, or a name server |
| Datagram | Connectionless messages, including broadcast | Broadcast domain or directed delivery |
| Session | Connection-oriented exchange | TCP connection to a named endpoint |
ഈ പട്ടികയാണ് മുദ്രാവാക്യം എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു എന്ന് കാണിക്കുന്നത്. പേരുള്ള രണ്ട് ഹോസ്റ്റുകൾ തമ്മിലുള്ള സെഷൻ സേവനം ഒരു IP സംഭാഷണമാണ്; പ്രക്ഷേപണ ഡാറ്റാഗ്രാം അല്ല. ഒരു VPN രൂപകൽപ്പന ആദ്യത്തേത് തൃപ്തിപ്പെടുത്തി രണ്ടാമത്തേത് തൃപ്തിപ്പെടുത്തണമെന്നില്ല, ആദ്യത്തേത് തെളിയിക്കുന്ന പരീക്ഷണം രണ്ടാമത്തേതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
നോഡ് തരങ്ങൾ ക്ലയന്റ് എന്ത് ആവശ്യപ്പെടുന്നു എന്ന് തീരുമാനിക്കുന്നു
RFC 1001-ലെ പ്രക്ഷേപണ, പോയിന്റ്-ടു-പോയിന്റ്, മിശ്ര നോഡ് മാതൃകകൾ ഒരു ഹോസ്റ്റ് പേരുകൾ എങ്ങനെ പരിഹരിക്കുന്നു എന്ന് വിവരിക്കുന്നു: പ്രാദേശിക നെറ്റ്വർക്കിനോട് ചോദിച്ചുകൊണ്ട്, പേര് സെർവറിനോട് നേരിട്ട് ചോദിച്ചുകൊണ്ട്, അല്ലെങ്കിൽ ഒന്ന് പരീക്ഷിച്ച് പിന്നീട് മറ്റൊന്ന് പരീക്ഷിച്ചുകൊണ്ട്. ഏത് ട്രാഫിക്ക് അനുവദിക്കണം എന്നതിനെ മാതൃക സ്വാധീനിക്കുന്നു, ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നുണ്ടോ എന്നതിനെയല്ല.
നിയന്ത്രിത പേര് സെർവർ ക്രമീകരണം ക്ലയന്റുകൾക്ക് പോയിന്റ്-ടു-പോയിന്റ് പാത നൽകുന്നു, പക്ഷേ അത് ഉപയോഗിക്കാൻ ക്രമീകരിച്ച ക്ലയന്റുകൾക്ക് മാത്രം. നെറ്റ്വർക്കിൽ എവിടെയോ ഒരു സെർവർ വെക്കുന്നത് ഒരു ആപ്ലിക്കേഷൻ അതിനോട് ആലോചിക്കാൻ ഇടയാക്കുന്നില്ല, പ്രക്ഷേപണ മോഡിൽ വിട്ടിട്ടുള്ള ക്ലയന്റ് പ്രാദേശിക സെഗ്മെന്റിനോട് ചോദിച്ചുകൊണ്ടിരിക്കും, സമയം കഴിയുന്നിടത്ത് എത്തും. സെർവറിന്റെ വിലാസം ക്ലയന്റിന്റെ ക്രമീകരണത്തിലെത്തണം, ആ ക്ലയന്റ് മാനിക്കുന്ന ഏത് നിർവഹണ പാതയിലൂടെയും.
അതിനാൽ ബന്ധപ്പെട്ട ആപ്ലിക്കേഷനായി മൂന്ന് നിരീക്ഷണങ്ങൾ രേഖപ്പെടുത്തുക: അത് സെർവർ പേരിനെ വിലാസമാക്കി എങ്ങനെ മാറ്റുന്നു, കണ്ടെത്തലോ സന്ദേശമയയ്ക്കലോ പ്രക്ഷേപണമാണോ ലക്ഷ്യബദ്ധമായ അന്തിമബിന്ദുവാണോ ഉപയോഗിക്കുന്നത്, യഥാർത്ഥ സെഷൻ ഏത് വിലാസവും ഗതാഗതവുമാണ് ഉപയോഗിക്കുന്നത്. ഇവ സ്വതന്ത്രമായ വസ്തുതകളാണ്, ഓരോന്നിനും അതിന്റേതായ പരിഹാരമുണ്ട്. ഒരു വിജയകരമായ പേര് പരിഹാരം ആദ്യത്തേതിനെക്കുറിച്ച് മാത്രമുള്ള തെളിവാണ്.
TCP/IP-യിലെ NetBIOS, NetBEUI അല്ല
രണ്ടിനെയും പഴയത് എന്ന് വിളിക്കുന്നതിനാൽ കൂട്ടിക്കലർത്തുന്നു. TCP/IP-യിലെ NetBIOS അതിന്റെ സേവനങ്ങൾ IP പാക്കറ്റുകൾക്കുള്ളിൽ കൊണ്ടുപോകുന്നു, റൂട്ട് ചെയ്ത ടണലിലൂടെ അവ ഇതിനകം കടന്നുപോകുന്നു. NetBEUI റൂട്ട് ചെയ്യാൻ കഴിയാത്ത ലെയർ 2 പ്രോട്ടോക്കോളാണ്, IP ടണൽ IP കൊണ്ടുപോകുന്നു എന്ന കാരണത്താൽ മാത്രം ഏകപക്ഷീയമായ ഈഥർനെറ്റ് ഫ്രെയിമുകൾ കൊണ്ടുപോകുന്നില്ല.
IP റൂട്ട് ചേർക്കുന്നത് IP അല്ലാത്ത ഫ്രെയിമിനെ IP ആപ്ലിക്കേഷനാക്കി മാറ്റാൻ കഴിയില്ല. ഒരു ആപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ ലെയർ 2-ന്റെ സ്വഭാവത്തെ ആശ്രയിക്കുന്നുവെങ്കിൽ, ഓപ്ഷനുകൾ വ്യക്തമായി പരിമിതപ്പെടുത്തിയ ലെയർ 2 സേവനമോ ആപ്ലിക്കേഷൻ മാറ്റിസ്ഥാപിക്കലോ ആണ്; അവയിൽ ഒന്നിനെയും മാറ്റിസ്ഥാപിക്കുന്ന റൂട്ടിംഗ് മാറ്റമില്ല.
ചുമതല തൃപ്തിപ്പെടുത്തുന്ന ഏറ്റവും ചെറിയ മാറ്റം തിരഞ്ഞെടുക്കുക
അംഗീകൃത DNS പേരും വ്യക്തമായ UNC പാതയും വഴി എത്തുന്ന നിലവിലുള്ള SMB പങ്കിടലിന് ഈഥർനെറ്റ് വിപുലീകരണം ആവശ്യമില്ല. ഫയൽ സേവന ചുമതലയും ബ്രൗസിംഗ് അനുഭവവും വ്യത്യസ്ത ആവശ്യകതകളാണ്, രണ്ടാമത്തേത് മാത്രമാണ് അയൽക്കാരുടെ പട്ടികയെ ആശ്രയിക്കുന്നത്. പേരിലൂടെ പങ്കിടലിൽ എത്തുന്നത് പ്രക്ഷേപണ മേഖല ടണലിലൂടെ നീട്ടാതെ ചുമതല പരിഹരിക്കുന്നു.
ബ്രൗസിംഗാണ് സാധാരണയായി പരാജയപ്പെടുന്ന ഭാഗം, അത് നിശബ്ദമായി പരാജയപ്പെടുന്നു. പാതയിലൂടെ പങ്കിടൽ തുറക്കാൻ കഴിയുമ്പോഴും അടുത്തുള്ള കമ്പ്യൂട്ടറുകളുടെ പട്ടിക ശൂന്യമായി തുടരാം, കാരണം പട്ടിക പ്രക്ഷേപണ കണ്ടെത്തലിലൂടെ നിറയുന്നു, പാത DNS ഉപയോഗിക്കുന്നു. പട്ടിക വേണമെന്ന് തീരുമാനിക്കുന്നത് ഫയൽ വേണമെന്ന് തീരുമാനിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്ത ആവശ്യകതയാണ്. എന്തെങ്കിലും രൂപകൽപ്പന ചെയ്യുന്നതിന് മുമ്പ് ഉപയോക്താവ് യഥാർത്ഥത്തിൽ ഏതാണ് ആവശ്യപ്പെട്ടതെന്ന് എഴുതുക.
പഴയ ആപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ പ്രക്ഷേപണമോ IP അല്ലാത്ത ഫ്രെയിമുകളോ ആവശ്യപ്പെടുന്നുവെങ്കിൽ, പേരുള്ള ഉടമയുള്ള പരിമിതമായ ലെയർ 2 സേവനം വിലയിരുത്തുക, അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ മാറ്റിസ്ഥാപിക്കുക. ഒരു ബ്രിഡ്ജ് പങ്കിട്ട പരാജയ മേഖലയും നയ അതിർത്തിയും വിശാലമാക്കുന്നു, അത് NetBIOS എന്നെഴുതിയ ചെക്ക്ബോക്സല്ല, വാസ്തുവിദ്യാ തീരുമാനമാണ്. ടണൽ കൊണ്ടുപോകേണ്ട നിർദ്ദിഷ്ട പ്രവർത്തനങ്ങൾ രേഖപ്പെടുത്തുക, അപ്പോൾ അഡ്മിനിസ്ട്രേറ്റർക്ക് «മുഴുവൻ Windows നെറ്റ്വർക്കിംഗ്» ഊഹിക്കുന്നതിന് പകരം അഭ്യർത്ഥന വിലയിരുത്താനാകും.