ഒരു സൈറ്റ് VPN-ന് രണ്ട് സൈറ്റുകൾക്ക് ഒരേ VLAN ID വേണോ?

രണ്ട് ഓഫീസുകളിൽ ഒരേ VLAN നമ്പറുകൾ ഉണ്ടെങ്കിൽ അത് സൈറ്റ്-ടു-സൈറ്റ് ടണലിന് സഹായിക്കേണ്ടതാണെന്ന് തോന്നുന്നു, എന്നാൽ ടണൽ വഹിക്കുന്ന കാര്യത്തിൽ അത് ഒന്നും മാറ്റുന്നില്ല. ഒരു VLAN ID ഒരു കെട്ടിടത്തിനുള്ളിലെ Ethernet ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്ൻ അടയാളപ്പെടുത്തുന്നു; ടണൽ ഗേറ്റ്‌വേകൾക്കിടയിൽ IP പാക്കറ്റുകൾ കൈമാറുന്നു. രണ്ട് സൈറ്റുകൾക്ക് തികച്ചും വ്യത്യസ്തമായ VLAN നമ്പറിംഗ് ഉപയോഗിച്ചും പരസ്പരം റൗട്ട് ചെയ്യാം, രണ്ട് സൈറ്റുകൾക്ക് ഒരേ VLAN നമ്പറിംഗ് ഉപയോഗിച്ചും പരസ്പരം എത്തിച്ചേരാൻ കഴിയില്ല. എത്തിച്ചേരൽ നിർണ്ണയിക്കുന്ന ചരം വിലാസ പ്ലാനാണ്.

മിത്ത്: ഇരു അറ്റങ്ങളിലും ഒരേ VLAN ID

ഈ വിശ്വാസം ന്യായമായ ഒരു സ്ഥലത്തുനിന്നാണ് വരുന്നത്. ഒരു കെട്ടിടത്തിനുള്ളിൽ, ഒരേ VLAN-ലെ രണ്ട് പോർട്ടുകൾക്ക് സംസാരിക്കാം, വ്യത്യസ്ത VLAN-കളിലെ രണ്ട് പോർട്ടുകൾക്ക് സാധ്യമല്ല, അതിനാൽ VLAN നമ്പർ കണക്റ്റിവിറ്റി നൽകുന്ന കാര്യമായി തോന്നുന്നു. റൗട്ടഡ് ടണലിലൂടെ ടാഗ് വിവരിക്കാൻ കഴിയുന്ന പങ്കിട്ട Ethernet സെഗ്മെന്റില്ല, ഗേറ്റ്‌വേകൾ ഒരിക്കലും VLAN ലേബലുകൾ കൈമാറുന്നുമില്ല.

ടണലിന് ആവശ്യമായത് പരസ്പരം ഓവർലാപ്പ് ചെയ്യാത്ത രണ്ട് വിലാസ പരിധികളും അവയ്ക്കിടയിലുള്ള ട്രാഫിക് അനുവദിക്കുന്ന നയവുമാണ്. ഏതെങ്കിലും ഓഫീസിൽ VLAN മാറ്റൂ, ടണൽ പ്രവർത്തിക്കുന്നത് തുടരും, കാരണം ടണൽ കോൺഫിഗറേഷനിൽ ഒന്നും അതിനെ പരാമർശിച്ചിരുന്നില്ല. ഇതാണ് തർക്കം തീർക്കുന്ന പരീക്ഷണം: VLAN വീണ്ടും നമ്പർ ചെയ്യൂ, വിലാസങ്ങൾ അതേപടി വയ്ക്കൂ, ടണൽ നിലനിൽക്കുന്നുണ്ടോ എന്ന് നോക്കൂ.

വിപരീത പരീക്ഷണവും അത്രതന്നെ വിവരദായകമാണ്. രണ്ട് ഓഫീസുകൾക്കും ഒരേ സബ്നെറ്റ് നൽകൂ, എത്ര ഒരേ VLAN നമ്പറുകൾ ഉണ്ടായാലും വിലാസം അവ്യക്തമല്ലാതാക്കില്ല.

ടണൽ യഥാർത്ഥത്തിൽ എന്താണ് വഹിക്കുന്നത്

IPsec വിലാസങ്ങൾ, പ്രോട്ടോക്കോളുകൾ, പോർട്ടുകൾ എന്നിവയിൽ പ്രകടിപ്പിക്കുന്ന നയപ്രകാരം IP പാക്കറ്റുകൾ സംരക്ഷിക്കുന്നു. IPsec ആർക്കിടെക്ചർ സ്വിച്ച് ടാഗ് വിവരിക്കുന്ന എല്ലാത്തിനും പല പാളികൾ മുകളിലുള്ള IP പാളിയിൽ ആ സെലക്ടറുകൾ വിവരിക്കുന്നു. ഒരു പാക്കറ്റ് ടണലിൽ പ്രവേശിക്കുമ്പോൾ അത് ഇതിനകം VLAN വിട്ടിരിക്കുന്നു; ടാഗ് പ്രാദേശിക സ്വിച്ച് ഉപയോഗിച്ചുകഴിഞ്ഞു.

നയാധിഷ്ഠിതവും റൂട്ട് അധിഷ്ഠിതവുമായ ഡിസൈനുകൾ ടണൽ തിരഞ്ഞെടുക്കുന്ന രീതിയിൽ വ്യത്യാസപ്പെടുന്നു, അവയ്ക്ക് വഹിക്കാനാകുന്ന കാര്യത്തിലല്ല. നയാധിഷ്ഠിത പിയർ ട്രാഫിക് സെലക്ടറുകൾ പൊരുത്തപ്പെടുത്തി പൊരുത്തപ്പെടുന്ന പാക്കറ്റുകൾ ടണലിലേക്ക് അയയ്ക്കുന്നു. റൂട്ട് അധിഷ്ഠിത പിയർ ടണൽ ഇന്റർഫേസിൽ ട്രാഫിക് റൗട്ട് ചെയ്ത് തീരുമാനം റൗട്ടിംഗ് ടേബിളിന് വിടുന്നു. രണ്ടും ഇപ്പോഴും സംരക്ഷണ പരിധിയിൽ ചർച്ച നടത്തുന്നു, അതിനാൽ ടണലിലേക്ക് ചൂണ്ടുന്ന ഒരു റൂട്ട് പിയറുകൾ സംരക്ഷിക്കാൻ സമ്മതിച്ചത് വിപുലീകരിക്കുന്നില്ല.

ഈ വ്യത്യാസം സാധാരണ പകുതി-പരാജയം വിശദീകരിക്കുന്നു: റൂട്ട് ഉണ്ട്, പാക്കറ്റുകൾ ടണലിൽ പ്രവേശിക്കുന്നു, എന്നാൽ അകലെയുള്ള വശം അവ നിരസിക്കുന്നു, കാരണം ചർച്ച ചെയ്ത സെലക്ടറുകളിൽ ആ പ്രിഫിക്സ് ഒരിക്കലും ഉണ്ടായിരുന്നില്ല. ഇൻസ്റ്റാൾ ചെയ്ത നയങ്ങൾ വായിക്കുന്നത് ഏത് പരിധിയാണ് യഥാർത്ഥത്തിൽ പ്രാബല്യത്തിൽ വന്നതെന്ന് കാണിക്കുന്നു.

ip xfrm policy
ip route show
swanctl --list-sas

യഥാർത്ഥത്തിൽ തകർക്കുന്ന ഓവർലാപ്പ്

വ്യത്യസ്ത സബ്നെറ്റുള്ള രണ്ട് ഓഫീസുകൾ ടണലിലൂടെ വ്യക്തമായി റൗട്ട് ചെയ്യുന്നു, അവയുടെ VLAN നമ്പറുകൾ പ്രസക്തമല്ല. ഒരേ സബ്നെറ്റുള്ള രണ്ട് ഓഫീസുകൾ അങ്ങനെയല്ല, കാരണം ഒരു നിർദ്ദിഷ്ട വിലാസത്തിനുള്ള അഭ്യർത്ഥനയ്ക്ക് രണ്ട് സാധ്യമായ അർത്ഥങ്ങളുണ്ട്, റൗട്ടിംഗ് ടേബിളിന് ഒന്ന് മാത്രം തിരഞ്ഞെടുക്കാം. ഒരു സൈറ്റ് വീണ്ടും നമ്പർ ചെയ്യുന്നതാണ് വ്യക്തമായ പരിഹാരം, DNS, ഫയർവാൾ മാറ്റങ്ങൾ കണക്കാക്കിയാൽ സാധാരണയായി ബദലുകളേക്കാൾ വിലകുറവാണ്.

വീണ്ടും നമ്പർ ചെയ്യാൻ കഴിയാത്തപ്പോൾ, ബോധപൂർവമായ ഒരു വിവർത്തന ഡിസൈന് ഓരോ വശത്തിനും വ്യത്യസ്ത വിലാസ കാഴ്ചകൾ നൽകാം. അതായത് ഒന്നിനൊന്ന് മാപ്പിംഗ്, പൊരുത്തപ്പെടുന്ന സെലക്ടറുകൾ, വിവർത്തനം ചെയ്ത കാഴ്ച പ്രതിഫലിപ്പിക്കുന്ന DNS എൻട്രികൾ, പുനരെഴുത്തിനെ അതിജീവിക്കുന്ന മടക്ക റൗട്ടിംഗ്. യഥാർത്ഥ പ്രവർത്തന ചെലവുള്ള പിന്തുണയുള്ള ഡിസൈനാണിത്, VLAN ID മാറ്റുന്നത് ചെയ്യുന്നത് ഇതല്ല.

ഇരു അറ്റങ്ങളിലും ഒരേ VLAN നമ്പറുകൾ ചിലപ്പോൾ പങ്കിട്ട ടെംപ്ലേറ്റിന്റെ യാദൃശ്ചികതയാണ്, ആ യാദൃശ്ചികതയെ പ്രവർത്തിക്കുന്ന ടണലിന്റെ കാരണമായി കണക്കാക്കുന്നത് പിന്നീട് എന്തെങ്കിലും തകരുമ്പോൾ തെറ്റായ മാറ്റത്തിലേക്ക് നയിക്കുന്നു.

ഓരോ പാളിക്കും ഒരു ജോലി, എഴുതപ്പെട്ടത്

പ്രാദേശിക സ്വിച്ച് ഏത് പോർട്ടുകൾ ഒരു ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്ൻ പങ്കിടുന്നുവെന്ന് തീരുമാനിക്കുന്നു, അതിന്റെ VLAN നമ്പറിംഗ് മറ്റൊരു സൈറ്റും അറിയേണ്ടതില്ലാത്ത പ്രാദേശിക അക്കൗണ്ടിംഗാണ്. ഗേറ്റ്‌വേ പിയറിനെ പ്രാമാണീകരിച്ച് ചർച്ച ചെയ്ത സംരക്ഷണ പരിധി നടപ്പാക്കുന്നു. റൗട്ടിംഗ് ടേബിൾ ഡീക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റ് അടുത്ത് എവിടെ പോകുമെന്ന് തീരുമാനിക്കുന്നു, ആക്സസ് നയം ആ പാക്കറ്റിന് യാതൊരു കാരണവശാലും അനുമതി നൽകേണ്ടതുണ്ടായിരുന്നോ എന്ന് തീരുമാനിക്കുന്നു.

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

മടക്ക റൂട്ടുകൾ, സ്വകാര്യ DNS, അപ്ലിക്കേഷൻ ഐഡന്റിറ്റി ആവശ്യകതകൾ എന്നിവ വീണ്ടും വേറിട്ട ജോലികളാണ്, അവയിലൊന്നും മറ്റേ സൈറ്റിൽനിന്ന് VLAN നമ്പർ പകർത്തി വരുന്നില്ല. പ്രാപ്യമായ പ്രിഫിക്സുകളും അനുവദനീയ സേവനങ്ങളും ലിസ്റ്റ് ചെയ്യുന്ന ഡിസൈൻ രേഖ സ്വിച്ച് മാറ്റത്തെ അതിജീവിക്കും; VLAN നമ്പറുകൾ ലിസ്റ്റ് ചെയ്യുന്നത് അതിജീവിക്കില്ല.

ടാഗ് ടണലിൽ എത്തുമെന്ന് അനുമാനിക്കുന്നതിന് മുമ്പ് ബ്രിഡ്ജ് ഉപകരണങ്ങളിലൂടെ പ്രാദേശിക ചിത്രം സ്ഥിരീകരിക്കുക.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

layer-2 വിപുലീകരണമാണ് യഥാർത്ഥ ആവശ്യമെങ്കിൽ

ചില ഡിസൈനുകൾക്ക് സൈറ്റുകൾക്കിടയിൽ യഥാർത്ഥത്തിൽ Ethernet പെരുമാറ്റം ആവശ്യമാണ്: ബ്രോഡ്കാസ്റ്റ് കണ്ടെത്തലിനെ ആശ്രയിക്കുന്ന പഴയ അപ്ലിക്കേഷൻ, യന്ത്രം നീങ്ങുമ്പോൾ വിലാസം നിലനിർത്തേണ്ട മൈഗ്രേഷൻ, അല്ലെങ്കിൽ layer-2 അനുമാനങ്ങൾ ഉൾക്കൊള്ളുന്ന പ്രോട്ടോക്കോൾ. അത്തരം കേസുകൾക്ക് ഫ്രെയിമുകൾ വഹിക്കുന്ന ഓവർലേ അല്ലെങ്കിൽ ബ്രിഡ്ജ്ഡ് സേവനം വേണം, അപ്പോൾ VLAN അംഗത്വം, ലൂപ്പ് തടയൽ, പരാജയ കൈകാര്യം എന്നിവ അറ്റാദി മുതൽ അറ്റം വരെയുള്ള കാര്യങ്ങളാകുന്നു.

അത് വളരെ വലിയ പരാജയ ഡൊമെയ്നാണ്, ഫയൽ പങ്കിടൽ പ്രവർത്തിപ്പിക്കാനുള്ള ശ്രമത്തിന്റെ യാദൃശ്ചിക ഫലമല്ല, ബോധപൂർവമായ തിരഞ്ഞെടുപ്പായിരിക്കണം. സാധാരണ ഫയൽ സർവർ, ഡാറ്റാബേസ് അല്ലെങ്കിൽ വെബ് അപ്ലിക്കേഷന് അധികാരമുള്ള IP പാത വേണം, അതിനടിയിൽ നീട്ടിയ ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്ൻ ഇല്ലെങ്കിൽ അത് കൂടുതൽ സന്തുഷ്ടമായിരിക്കും.

VPN കരാർ പ്രാപ്യമായ പ്രിഫിക്സുകളും അനുവദനീയ സേവനങ്ങളുമായി എഴുതുക, VLAN ലേബൽ പ്രാദേശിക പ്രവർത്തനങ്ങൾക്ക് ആവശ്യമുള്ളിടത്ത് മാത്രം രേഖപ്പെടുത്തുക. അപ്പോൾ ഓരോ ഓഫീസിനും ഓരോ മാറ്റത്തെയും ടണൽ പുനർരൂപകൽപ്പനയാക്കാതെ സ്വന്തം സ്വിച്ചിംഗ് പുനർനമ്പർ ചെയ്യാം.