VPN-ലൂടെ DHCP: ബ്രോഡ്‌കാസ്റ്റ് ബ്രിഡ്ജ് ചെയ്യണോ റിലേ ചെയ്യണോ?

ടണലിന്റെ അപ്പുറത്തുള്ള പുതിയ ലാപ്‌ടോപ്പിന് വിലാസം ലഭിക്കുന്നില്ല, എന്നാൽ അതേ ലാപ്‌ടോപ്പ് ആസ്ഥാനത്ത് പ്രവർത്തിക്കുന്നു. സാധാരണ ആദ്യ അനുമാനം ടണൽ DHCP തടയുന്നു എന്നാണ്. പലപ്പോഴും ബ്രോഡ്‌കാസ്റ്റിന് ഒരിക്കലും വഴിയുണ്ടായിരുന്നില്ല: കോൺഫിഗർ ചെയ്യാത്ത ക്ലയന്റ് 255.255.255.255-ലേക്ക് അയയ്ക്കുന്നു, സാധാരണ IP റൂട്ടർ ആ പാക്കറ്റ് കൈമാറുന്നുമില്ല. ടണൽ റൂട്ട് ചെയ്ത ടണൽ ചെയ്യുന്നത് തന്നെയാണ് ചെയ്യുന്നത്.

രണ്ട് രൂപകൽപ്പനകൾക്ക് അത് മാറ്റാനാകും, അവ തുല്യമല്ല. ഒന്ന് ബ്രോഡ്‌കാസ്റ്റ് കൊണ്ടുപോകുന്നു; മറ്റൊന്ന് അഭ്യർത്ഥന റിലേ ചെയ്യുന്നു.

ബ്രോഡ്‌കാസ്റ്റ് ഒരിക്കലും റൂട്ടർ കടക്കുന്നില്ല

വിലാസമില്ലാത്ത DHCPv4 ക്ലയന്റ് 0.0.0.0-ൽ നിന്ന് പരിമിത ബ്രോഡ്‌കാസ്റ്റ് വിലാസത്തിലേക്ക് UDP പോർട്ട് 67, 68 വഴി അയയ്ക്കുന്നു. ആ പാക്കറ്റ് രൂപകൽപ്പന പ്രകാരം അതിന്റെ ലിങ്കിൽ തന്നെ തുടരുന്നു. അത് കൈമാറുന്ന റൂട്ടർ താൻ സേവിക്കുന്ന ഓരോ സെഗ്മെന്റും വെള്ളപ്പൊക്കത്തിൽ മുക്കും.

അതിനാൽ റൂട്ട് ചെയ്ത സൈറ്റ്-ടു-സൈറ്റ് ടണൽ റിലേയെ ഒരു സെർവറുമായി ബന്ധിപ്പിക്കുന്നു. അത് ക്ലയന്റിന്റെ ബ്രോഡ്‌കാസ്റ്റ് ഡൊമെയ്ൻ വിപുലീകരിക്കുന്നില്ല, ഒരു ഫയർവാൾ നിയമവും അത് ചെയ്യിക്കില്ല.

ബ്രിഡ്ജ് ചെയ്ത ടണൽ യഥാർത്ഥത്തിൽ എന്താണ് വിപുലീകരിക്കുന്നത്

ബോധപൂർവം ബ്രിഡ്ജ് ചെയ്ത VPN-ന് അതിന്റെ പിന്തുണയുള്ള ടോപ്പോളജിയിൽ Ethernet ബ്രോഡ്‌കാസ്റ്റ് കൊണ്ടുപോകാം, അപ്പോൾ DHCP പ്രാദേശിക ട്രാഫിക്കായി കടക്കാം. ഇത് യഥാർത്ഥ ഓപ്ഷനാണ്, പക്ഷേ ഇത് 2-ാം പാളിയിലെ രൂപകൽപ്പന തീരുമാനമാണ്. ബ്രോഡ്‌കാസ്റ്റിനൊപ്പം പരാജയ ഡൊമെയ്നും പ്രവേശന അതിരും വിപുലീകരിക്കുകയാണ്.

ബ്രിഡ്ജിംഗ് ബ്രോഡ്‌കാസ്റ്റ് കൊടുങ്കാറ്റിനോ ARP സ്കാനിനോ ദുഷ്ട DHCP സെർവറിനോ എവിടെവരെ എത്താമെന്നും മാറ്റുന്നു. ദൂര ഓഫീസ് അതേ സ്വിച്ചിൽ ഘടിപ്പിക്കില്ലെങ്കിൽ, വിലാസങ്ങൾ വിതരണം ചെയ്യാൻ മാത്രം ടണൽ ബ്രിഡ്ജ് ചെയ്യരുത്. പ്രവർത്തനക്ഷമമാക്കുന്നതിന് മുൻപ് ആ ആഘാത ആരം പരിശോധിക്കുക.

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

പകരം അഭ്യർത്ഥന റിലേ ചെയ്യുക

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

ഉദാഹരണമായ ദൂര ഓഫീസിൽ, റിലേ ഓഫീസിന്റെ LAN-ൽ ഇരിക്കുന്നു, സെർവറിൽ സൈറ്റ് VPN വഴി എത്തുന്നു. ആ ഓഫീസിനുള്ള സ്കോപ്പ്, റിലേയുടെയും സെർവറിന്റെയും ഐഡന്റിറ്റികൾ, പൂർണ മടക്കപ്പാത എന്നിവ കോൺഫിഗർ ചെയ്യുക. ടണലിലൂടെ UDP 67 അനുവദിക്കുന്നത് ഏത് പൂൾ ഉപയോഗിക്കണമെന്ന് സെർവറിനോട് പറയുന്നില്ല.

കൈമാറുന്നുവെങ്കിലും ഒരിക്കലും മറുപടി ലഭിക്കാത്ത റിലേ സാധാരണയായി മടക്കപ്പാതയുടെ പ്രശ്നമാണ്. സ്കോപ്പ് മാറ്റുന്നതിന് മുൻപ് റിലേ വിലാസത്തിലേക്കുള്ള മടക്കറൂട്ട് പരിശോധിക്കുക.

DHCP-യെ ARP-ൽ നിന്നും ടണൽ വിലാസനിർണ്ണയത്തിൽ നിന്നും വേർതിരിക്കുക

DHCP UDP/IP-യുടെ മുകളിലാണ് ഓടുന്നത്. Ethernet-ൽ, സ്ഥാനാർത്ഥി വിലാസം ഇതിനകം ഉപയോഗത്തിലാണോ എന്ന് പരിശോധിക്കാൻ ഹോസ്റ്റ് ARP-ഉം ഉപയോഗിച്ചേക്കാം. ആ കൂട്ടിയിടി പരിശോധന പ്രത്യേക ലിങ്ക്-പ്രാദേശിക പ്രവർത്തനമാണ്, DHCP സന്ദേശങ്ങളുടെ വാഹകമല്ല. DHCP അടിസ്ഥാനപരമായി ARP ആണെന്ന് പറയുന്നത് തെറ്റാണ്; രണ്ടും ഒരിക്കലും ബന്ധപ്പെടുന്നില്ലെന്ന് പറയുന്നത് വളരെ വിശാലമാണ്.

VPN ക്ലയന്റിന് DHCP ബ്രോഡ്‌കാസ്റ്റിന് പകരം VPN പ്രോട്ടോക്കോളിൽ നിന്നോ സെർവറിന്റെ സ്വന്തം പൂളിൽ നിന്നോ ടണൽ വിലാസം ലഭിച്ചേക്കാം. പേരിൽ DHCP ഉള്ള ഒരു ഓപ്ഷൻ തള്ളിയ ക്ലയന്റ് ക്രമീകരണങ്ങൾ വിവരിച്ചേക്കാം, റിലേ ചെയ്ത DHCP പാക്കറ്റല്ല. DHCP ഉൾപ്പെട്ടിട്ടുണ്ടോ എന്ന് അനുമാനിക്കുന്നതിന് മുൻപ് സെർവറിന്റെ പൂൾ പരിശോധിക്കുക.

സ്വീകരിക്കുന്ന നെറ്റ്‌വർക്ക്, അനുവദത്തിന്റെ ഉടമ, സ്കോപ്പ്, റിലേ ഉണ്ടോ എന്നത്, തടസ്സസമയത്തെ പ്രതീക്ഷിത സ്വഭാവം എന്നിവ രേഖപ്പെടുത്തുക. പിന്നീട് ആ മാതൃകയിലൂടെ പുതിയ ലീസും പുതുക്കലും പരിശോധിക്കുക. രണ്ട് സൈറ്റുകൾക്ക് ഒരേ കൈകാര്യം ചെയ്യാത്ത പൂൾ സേവിക്കാമെങ്കിൽ, ആദ്യം സഞ്ചരിക്കുന്ന ലാപ്‌ടോപ്പിനായി കാത്തിരിക്കുന്ന ഒരു കൂട്ടിയിടി നിങ്ങൾക്കുണ്ട്.