LAN വിലാസമുള്ള VPN ക്ലയന്റ് LAN-ൽ അല്ല

ക്ലയന്റ് കണക്ട് ചെയ്യുന്നു, 10.50.0.200 സ്വീകരിക്കുന്നു, രണ്ട് നമ്പറുകളും ഒരേ /24-ൽ ആണെങ്കിലും 10.50.0.20-ലെ സെർവറിൽ എത്താൻ കഴിയുന്നില്ല. ഈ കോൺഫിഗറേഷന്റെ പിന്നിലെ വിശ്വാസം, LAN പ്രിഫിക്സിൽ നിന്നുള്ള വിലാസം ക്ലയന്റിനെ LAN-ന്റെ ഭാഗമാക്കുന്നു എന്നതാണ്. അത് ചെയ്യുന്നില്ല. ക്ലയന്റ് പോയിന്റ്-ടു-പോയിന്റ് ലിങ്കിലാണ്, സെർവർ ലക്ഷ്യസ്ഥാനം ലോക്കൽ ആണെന്ന് കരുതുന്നു, കാണാത്ത ഭാഗം ആരും അയക്കാത്ത അയൽക്കാരൻ മറുപടിയാണ്.

മിത്ത്: ഒരേ പ്രിഫിക്സ് എന്നാൽ ഒരേ സെഗ്മെന്റ്

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

സെർവർ 10.50.0.200-ലേക്ക് അയക്കുമ്പോൾ, ലക്ഷ്യസ്ഥാനം സ്വന്തം മാസ്കുമായി താരതമ്യം ചെയ്ത് വിലാസം on-link ആണെന്ന് തീരുമാനിച്ച്, അതിനുടമയായ ഹാർഡ്‌വെയർ വിലാസം ലോക്കൽ സെഗ്മെന്റിനോട് ചോദിക്കുന്നു. ആ അഭ്യർത്ഥന Ethernet ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്നു, VPN ക്ലയന്റ് അത് കേൾക്കാൻ അവിടെയില്ല.

ക്ലയന്റിന്റെ കോൺഫിഗറേഷനിൽ ഒന്നിനും സ്വന്തം ഭാഗത്തുനിന്ന് ഇത് പരിഹരിക്കാനാവില്ല. മറുപടി പാത ആശ്രയിക്കുന്നത് LAN-ലുള്ള ഒരു ഉപകരണം ക്ലയന്റിന്റെ പകരം മറുപടി നൽകുന്നതിനെയോ, സെർവർ ലോക്കൽ ആയി കണക്കാക്കാത്ത വിലാസം ക്ലയന്റിനുണ്ടാകുന്നതിനെയോ ആണ്.

ലോക്കൽ ഹോസ്റ്റ് വിലാസവുമായി യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു

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

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

റൂട്ട് തിരയൽ Ethernet ഇന്റർഫേസിലൂടെ ലക്ഷ്യസ്ഥാനത്തെ on-link ആയി റിപ്പോർട്ട് ചെയ്യും, അതാണ് കൃത്യം പ്രശ്നം. VPN സെഷൻ പ്രവർത്തിക്കുന്നതിനിടയിൽ അയൽക്കാര എൻട്രി അപൂർണ്ണമായി തുടർന്നാൽ, കാണാത്ത ഭാഗം ലിങ്ക് ലെയർ റെസല്യൂഷൻ ആണെന്നും റൗട്ടിംഗോ ഫയർവാൾ നയമോ അല്ലെന്നും നിങ്ങൾ സ്ഥിരീകരിച്ചു.

മറ്റൊരു സബ്നെറ്റിലെ ഹോസ്റ്റിൽ നിന്ന് അതേ പരിശോധന നടത്തി താരതമ്യം ചെയ്യുക. റൗട്ടറിലൂടെ ക്ലയന്റിൽ എത്തുന്ന ഹോസ്റ്റിന് അയൽക്കാര എൻട്രി ആവശ്യമില്ല, ആ വ്യത്യാസമാണ് ചെറിയ തോതിലുള്ള ഡിസൈൻ തീരുമാനം.

proxy ARP അടുത്ത ഹോപ്പ് എങ്ങനെ നൽകുന്നു

proxy ARP, മറ്റൊരു ഇന്റർഫേസിലൂടെ എത്താൻ കഴിയുന്ന ലക്ഷ്യസ്ഥാനത്തിന്റെ പകരം ലിങ്ക് ലെയർ അഭ്യർത്ഥനയ്ക്ക് ഗേറ്റ്‌വേ മറുപടി നൽകാൻ പ്രേരിപ്പിക്കുന്നു. LAN ഹോസ്റ്റ് ഹാർഡ്‌വെയർ വിലാസം സ്വീകരിച്ച് ഫ്രെയിം ഗേറ്റ്‌വേയിലേക്ക് അയക്കുന്നു, ഗേറ്റ്‌വേ പാക്കറ്റ് VPN സെഷനിലേക്ക് കൈമാറുന്നു. ഹോസ്റ്റിന്റെ കാഴ്ചയിൽ ക്ലയന്റ് ഗേറ്റ്‌വേയുടെ പിന്നിലാണെന്ന് തോന്നുന്നു. ക്ലയന്റിന്റെ കോൺഫിഗറേഷനിൽ ഒന്നും മാറുന്നില്ല.

MikroTik-ന്റെ RouterOS ARP രേഖകൾ ബന്ധിപ്പിച്ച LAN-ന്റെ വിലാസ ഇടം കടമെടുക്കുന്ന ഡയൽ-ഇൻ ക്ലയന്റുകൾക്കുള്ള ഈ ഉപയോഗം വിവരിക്കുന്നു. സംവിധാനം അയൽക്കാര റെസല്യൂഷന്റെ അറ്റകുറ്റപ്പണിയാണ്, ഗേറ്റ്‌വേ യഥാർത്ഥത്തിൽ രണ്ട് പാതകളിലും ഉള്ളതിനാൽ ഇത് പ്രവർത്തിക്കുന്നു.

ഇത് ക്ലയന്റിനെ LAN-ലേക്ക് ബ്രിഡ്ജ് ചെയ്യുന്നതിന് തുല്യമല്ല. ഗേറ്റ്‌വേ ഇപ്പോഴും പാക്കറ്റ് ശരിയായ സജീവ സെഷനിലേക്ക് കൈമാറണം, അതിന്റെ റൗട്ടിംഗും ഫയർവാൾ നയവും ഇപ്പോഴും സേവനം അനുവദിക്കണം. proxy ARP മാറ്റുന്നത് അയൽക്കാര അഭ്യർത്ഥനയ്ക്ക് ആര് മറുപടി നൽകുന്നു എന്നതാണ്, ആർക്ക് സംസാരിക്കാം എന്നതല്ല.

പ്ലാറ്റ്‌ഫോമിന്റെ മോഡ് പേരുകൾ ശ്രദ്ധയോടെ വായിക്കുക. RouterOS proxy-arp-നെ local-proxy-arp-ൽ നിന്ന് വേർതിരിക്കുന്നു, രണ്ടാമത്തേത് അതേ ഇന്റർഫേസിലൂടെ അകത്തേക്കും പുറത്തേക്കും പോകുന്ന ട്രാഫിക് കൈകാര്യം ചെയ്യുന്നു. ഇവ പരസ്പരം മാറ്റാവുന്ന അക്ഷരവിന്യാസങ്ങളല്ല, രണ്ടും വേർതിരിവില്ലാതെ പ്രവർത്തനക്ഷമമാക്കുന്നത് എളുപ്പവഴിയല്ല.

proxy ARP നിങ്ങൾക്ക് നൽകാത്തത്

ഇത് broadcast അല്ലെങ്കിൽ multicast കണ്ടെത്തൽ നൽകുന്നില്ല. broadcast വഴി സേവനം കണ്ടെത്തേണ്ട ക്ലയന്റ് ഇപ്പോഴും പരാജയപ്പെടും, കാരണം ഗേറ്റ്‌വേ unicast സെഷനിലേക്ക് കൈമാറുന്നു, ക്ലയന്റിനെ LAN-ന്റെ broadcast ഡൊമെയ്നിലെ അംഗമാക്കുന്നുമില്ല. broadcast-നെ ആശ്രയിക്കുന്ന കണ്ടെത്തൽ പ്രോട്ടോക്കോളുകൾ, കടമെടുത്ത വിലാസ ഡിസൈനുകളിൽ «ഒരു കാര്യത്തിന് പ്രവർത്തിക്കുന്നു, മറ്റൊന്നിന് ഇല്ല» എന്ന റിപ്പോർട്ടുകളുടെ സാധാരണ ഉറവിടമാണ്.

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

LAN-ന്റെ ഉടമയുമായി ഏകോപിപ്പിക്കേണ്ട ആവശ്യകതയും ഇത് ഒഴിവാക്കുന്നില്ല. വിലാസ പദ്ധതിയുടെ ഉടമയെ അത്ഭുതപ്പെടുത്തുന്ന proxy ARP എൻട്രി ശാന്തമായ ഒരു ആഴ്ചയ്ക്കായി കാത്തിരിക്കുന്ന പിന്തുണ സംഭവമാണ്.

വേറിട്ട് റൗട്ട് ചെയ്ത പൂളുമായുള്ള താരതമ്യം

ബദൽ, VPN ക്ലയന്റുകൾക്ക് സ്വന്തം പ്രിഫിക്സ് നൽകി LAN ഹോസ്റ്റുകൾ അങ്ങോട്ട് റൗട്ട് ചെയ്യാൻ അനുവദിക്കുക എന്നതാണ്. അപ്പോൾ സെർവർ തന്റെ ഗേറ്റ്‌വേയിലേക്ക് off-link മറുപടികൾ അയക്കുന്നു, ഗേറ്റ്‌വേ പ്രിഫിക്സ് VPN അന്തിമ ബിന്ദുവിലേക്ക് റൗട്ട് ചെയ്യുന്നു, LAN സെഗ്മെന്റിൽ അയൽക്കാര റെസല്യൂഷൻ ആവശ്യമില്ല. കടമെടുത്ത വിലാസവും proxy മറുപടിയും ചേർന്നതിനേക്കാൾ കുറഞ്ഞ ചലിക്കുന്ന ഭാഗങ്ങളാണിത്.

ആ ഡിസൈൻ ചിന്തിക്കാനും ഓഡിറ്റ് ചെയ്യാനും എളുപ്പമാണ്, കാരണം ക്ലയന്റ് ശ്രേണി LAN ശ്രേണിയിൽ നിന്ന് വ്യക്തമായി വേർതിരിച്ചിരിക്കുന്നു. അതിന് ഒരു റൂട്ട്, ഒരു തിരിച്ചുവരവ് പാത, ഒരു ആക്സസ് നിയമം എന്നിവ ചെലവാകുന്നു, proxy ARP ഡിസൈന് കുറഞ്ഞ വ്യക്തതയുള്ള സ്ഥലത്ത് ആവശ്യമായ അതേ കാര്യങ്ങൾ.

മാതൃകകൾക്കിടയിൽ ബോധപൂർവ്വം തിരഞ്ഞെടുക്കുക, യാദൃച്ഛികമായി അല്ല. proxy ARP ഒരു നിർദ്ദിഷ്ട ബന്ധം നന്നാക്കുന്നു; റൗട്ട് ചെയ്ത പൂൾ ആ അറ്റകുറ്റപ്പണിയുടെ ആവശ്യം ഒഴിവാക്കുന്നു. ഏതാണ് തിരഞ്ഞെടുത്തതെന്നും എന്തുകൊണ്ടെന്നും എഴുതിവെക്കുക, അപ്പോൾ അടുത്തയാൾക്ക് പരാജയപ്പെട്ട അയൽക്കാര എൻട്രിയിൽ നിന്ന് അത് വീണ്ടും കണ്ടെത്തേണ്ടിവരില്ല.