നിങ്ങളുടെ VPN പൂൾ LAN-ന്റെ DHCP ശ്രേണിയല്ല: അത് എന്തുകൊണ്ട് തകരുന്നു

ഓഫീസിലെ DHCP സർവറിന് ഉപയോഗിക്കുന്ന അതേ ശ്രേണിയിൽ നിന്ന് VPN ക്ലയന്റുകൾക്ക് വിലാസങ്ങൾ നൽകുന്നതാണ് പ്രലോഭനീയമായ എളുപ്പവഴി, എല്ലാം എന്തായാലും ഒരു നെറ്റ്വർക്കാണ് എന്ന ധാരണയിൽ. അങ്ങനെയല്ല. റൂട്ട് ചെയ്ത തുരങ്കം രണ്ട് അറ്റങ്ങൾക്കിടയിൽ യൂണികാസ്റ്റ് പാക്കറ്റുകൾ കൊണ്ടുപോകുന്നു, അതേസമയം ഭൗതിക സെഗ്മെന്റിൽ ബ്രോഡ്കാസ്റ്റ് അഭ്യർത്ഥനകൾക്ക് ഉത്തരം നൽകാനാണ് LAN പൂൾ നിലനിൽക്കുന്നത്. അതേ നമ്പറുകൾ വീണ്ടും ഉപയോഗിക്കുന്നത് രണ്ട് അനുവദനക്കാരെ ഒരു വിലാസ മേഖലയുടെ ഉത്തരവാദിത്തത്തിലാക്കുകയും റിട്ടേൺ പാത നിർവചിക്കപ്പെടാതെ വിടുകയും ചെയ്യുന്നു.

രണ്ട് അനുവദനക്കാർ, ഒരു വിലാസ മേഖല

LAN-ന്റെ DHCP സർവർ ഏത് വിലാസങ്ങൾ ഏത് MAC വിലാസത്തിന് പാട്ടത്തിന് നൽകി എന്ന് അറിയുന്നു, ARP ഉപയോഗിച്ച് അവയെ സംരക്ഷിക്കുന്നു. VPN സർവറിന് സ്വന്തം പൂൾ ഉണ്ട്, ആ പാട്ടങ്ങളെക്കുറിച്ച് ഒന്നും അറിയില്ല. രണ്ടും തെറ്റല്ല; അവരെ ഒരിക്കലും പരസ്പരം പരിചയപ്പെടുത്തിയിട്ടില്ല.

VPN സർവർ LAN പൂളിൽ നിന്ന് നൽകുന്ന വിലാസം ഇതിനകം ഒരു പ്രിന്ററിന്റേതാകാം. ഇപ്പോൾ രണ്ട് ഉപകരണങ്ങൾ ഒരേ പ്രിഫിക്സിൽ ഒരു വിലാസം അവകാശപ്പെടുന്നു, സ്വിച്ചിന്റെ ഫോർവേഡിംഗ് പട്ടിക ആര് ഉത്തരം നൽകുമെന്ന് തീരുമാനിക്കുന്നു.

ആളുകൾ ആദ്യം നേരിടുന്ന തകരാറാണിത്: വിജയകരമായി കണക്ട് ചെയ്ത ശേഷം തെറ്റായ യന്ത്രത്തിൽ എത്തുന്ന ക്ലയന്റ്, അല്ലെങ്കിൽ ശരിയായതിൽ ഇടവേളകളിൽ എത്തുന്ന ക്ലയന്റ്.

റൗട്ടർ VPN വിലാസങ്ങൾ വിതരണം ചെയ്യാത്തത് എന്തുകൊണ്ട്

DHCP കണ്ടെത്തൽ ഒരു ബ്രോഡ്കാസ്റ്റാണ്, ബ്രോഡ്കാസ്റ്റുകൾ റൂട്ട് ചെയ്ത അതിർത്തിയിൽ നിലയ്ക്കുന്നു. രൂപകൽപ്പന തുരങ്കം ബ്രിഡ്ജ് ചെയ്യുന്നില്ലെങ്കിൽ അല്ലെങ്കിൽ യോജിച്ച അധികാരമുള്ള DHCP റിലേ പ്രവർത്തിപ്പിക്കുന്നില്ലെങ്കിൽ, ക്ലയന്റിന്റെ അഭ്യർത്ഥന ഒരിക്കലും LAN സർവറിൽ എത്തില്ല.

അതുകൊണ്ട് VPN സർവർ തന്നെ വിലാസം നിശ്ചയിക്കുന്നു: സർവർ കോൺഫിഗറേഷനിലെ ഒരു പൂൾ, WireGuard ക്രമീകരണത്തിൽ ഓരോ പിയർക്കും ഒരു വിലാസം, അല്ലെങ്കിൽ IKEv2 വിന്യാസത്തിൽ ഓതന്റിക്കേഷൻ പാളി തള്ളുന്ന വിലാസം. ഈ സംവിധാനങ്ങൾ LAN പാട്ട ഡാറ്റാബേസിൽ നിന്ന് സ്വതന്ത്രമാണ്, അതുകൊണ്ടുതന്നെ അവയ്ക്ക് സ്വന്തം ശ്രേണി വേണം.

അതേ യുക്തി വിശദീകരിക്കുന്നത് DHCP സ്കോപ്പ് മാറ്റിയാലും ഒരിക്കലും വിലാസം ലഭിക്കാത്ത VPN ക്ലയന്റ് എന്തുകൊണ്ട് ശരിയാകുന്നില്ല എന്നാണ്. ക്ലയന്റ് LAN സർവറിനോട് ചോദിക്കുന്നില്ല, സ്കോപ്പിൽ എത്ര എഡിറ്റ് ചെയ്താലും അതിനെ ചോദിക്കാൻ നിർബന്ധിക്കാനാകില്ല.

ഓവർലാപ്പ് മന്ദഗതിയിലുള്ള നെറ്റ്വർക്കായി അല്ല, സംഘർഷമായി പ്രത്യക്ഷപ്പെടുന്നു

പിന്തുണയുള്ള രൂപകൽപ്പനയില്ലാതെ ഒരേ പ്രിഫിക്സ് പങ്കിടുന്ന രണ്ട് നെറ്റ്വർക്കുകൾ ഇരട്ട ഉടമസ്ഥതയിൽ നിന്ന് വ്യത്യസ്തമായ പ്രശ്നമാണ്, അവ പലപ്പോഴും കൂട്ടിക്കലർത്തപ്പെടുന്നു. VPN പൂൾ വേറിട്ട പ്രിഫിക്സാണെങ്കിൽ, ഒരു റൂട്ട് ട്രാഫിക്കിനെ തെറ്റായ വശത്തേക്ക് അയക്കുമ്പോൾ മാത്രമാണ് ഓവർലാപ്പ് പ്രസക്തം. പൂൾ LAN പ്രിഫിക്സിനുള്ളിലാണെങ്കിൽ, സംഘർഷം തൽക്ഷണവും പ്രാദേശികവുമാണ്.

പ്രായോഗികമായി തെറ്റായ ഉപകരണത്തിൽ നിന്നുള്ള ARP ഉത്തരങ്ങൾ, പകുതിയിൽ റീസെറ്റ് ചെയ്യുന്ന കണക്ഷനുകൾ, സ്വന്തം വിലാസം മറ്റൊരാൾ അവകാശപ്പെടുന്ന ക്ലയന്റ് എന്നിവ കാണാം. ഇവയൊന്നും റൂട്ടിംഗ് പ്രശ്നമായി തോന്നുന്നില്ല, അതുകൊണ്ടാണ് പരിഹാരം തെറ്റായ പാളിയിൽ പ്രയോഗിക്കുന്നത്. ഇരട്ട പാട്ടം സ്ഥിരീകരിക്കാൻ എളുപ്പവും അതിനോടൊപ്പം ജീവിക്കാൻ ശല്യവുമാണ്. റീബൂട്ടുകളെയും അത് അതിജീവിക്കുന്നു, കാരണം രണ്ട് അനുവദനക്കാരും അതേ വിലാസത്തിന് വാശി പിടിക്കുന്നു.

റിട്ടേൺ പാത വേറിട്ട പ്രശ്നമാണ്

വൃത്തിയുള്ളതും വേറിട്ടതുമായ പൂൾ ഉണ്ടായാലും, ക്ലയന്റിനോട് എങ്ങനെ ഉത്തരം നൽകണമെന്ന് LAN ഹോസ്റ്റുകൾ അറിയണം. അവയുടെ ഡിഫോൾട്ട് ഗേറ്റ്വേ റൗട്ടറാണ്, റൗട്ടറിന് പൂളിനായി VPN സർവറിലേക്ക് ചൂണ്ടുന്ന ഒരു റൂട്ട് വേണം, രൂപകൽപ്പന പകരം ക്ലയന്റ് ട്രാഫിക് പരിഭാഷപ്പെടുത്തുന്നില്ലെങ്കിൽ.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് പാത രണ്ട് ദിശകളിലും വായിക്കുക. ഗേറ്റ്വേയിൽ ക്ലയന്റ് വിലാസത്തിന് കേർണൽ ഏത് ഇന്റർഫേസ് ഉപയോഗിക്കുമെന്ന് ചോദിക്കുക; ക്ലയന്റിൽ LAN വിലാസത്തിന് അത് ഏത് റൂട്ട് ഉപയോഗിക്കുന്നു എന്ന് ചോദിക്കുക.

ഈ കമാൻഡുകൾ ഗേറ്റ്വേയിലെ ഫോർവേഡിംഗ് തീരുമാനവും തനിപ്പകർപ്പ് വെളിപ്പെടുത്തുന്ന അയൽവാസി എൻട്രികളും കാണിക്കുന്നു:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

ആദ്യ കമാൻഡ് തുരങ്കത്തിന്റെ ഇന്റർഫേസോടെ ഉത്തരം നൽകുന്നുവെങ്കിൽ, റിട്ടേൺ റൂട്ട് നിലവിലുണ്ട്. അത് LAN ഇന്റർഫേസോടെ ഉത്തരം നൽകുന്നുവെങ്കിൽ, ക്ലയന്റ് കമ്പിയിലാണെന്ന് റൗട്ടർ വിശ്വസിക്കുകയും അതിനായി ARP ചെയ്യാൻ ശ്രമിക്കുകയും ചെയ്യും.

ബ്രിഡ്ജ്ഡ് രൂപകൽപ്പനകൾ നിലവിലുണ്ട്, പക്ഷേ അവ തിരഞ്ഞെടുക്കണം

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

പ്രവർത്തിക്കാത്തത് നമ്പറുകൾ പകർത്തി ഫലം അനുകരിക്കുന്നതാണ്. ബ്രിഡ്ജ് ഇല്ലാത്ത പങ്കിട്ട പൂൾ കണ്ടെത്തലില്ലാതെ സംഘർഷം മാത്രം തരുന്നു, അതാണ് രണ്ട് ക്രമീകരണങ്ങളിലും ഏറ്റവും മോശം.

ആപ്ലിക്കേഷന് യഥാർത്ഥത്തിൽ സെഗ്മെന്റ് ആവശ്യമില്ലെങ്കിൽ വേറിട്ട പൂളുമായി മൂന്നാം പാളി തിരഞ്ഞെടുക്കുക, പൂൾ രേഖപ്പെടുത്തുക, അടുത്ത അഡ്മിനിസ്ട്രേറ്റർ വൃത്തിക്കുവേണ്ടി DHCP ശ്രേണി വീണ്ടും ഉപയോഗിക്കാതിരിക്കാൻ.