പൂർണ ടണൽ VPN നിങ്ങളുടെ റൂട്ട് ചെയ്ത പ്രാദേശിക VLAN-കൾ എന്തുകൊണ്ട് മറയ്ക്കുന്നു

VPN ക്ലയന്റിലെ “allow local network” സ്വിച്ച് കെട്ടിടത്തിലെ എല്ലാം ഉൾക്കൊള്ളുന്നതായി തോന്നുന്നു. പ്രായോഗികമായി അത് സാധാരണയായി ടണലിന്റെ ഡിഫോൾട്ട് റൂട്ടിലേക്ക് കുറച്ച് സ്വകാര്യ-വിലാസ ഒഴിവുകൾ ചേർത്ത് അവിടെ നിൽക്കുന്നു. നിങ്ങളുടെ സ്റ്റോറേജ് VLAN എത്താവുന്നതായി തുടരുന്നത്, ആ നിർദ്ദിഷ്ട പ്രിഫിക്സിനുള്ള റൂട്ട് ടണലിന്റെ വരവിനെ അതിജീവിച്ചാൽ മാത്രം, പല ക്ലയന്റുകളിലും അത് അതിജീവിക്കുന്നില്ല.

ഇത് VPN ക്രമീകരണമല്ല, റൂട്ടിംഗ് ചോദ്യമാണ്, അത് നല്ല വാർത്തയാണ്: അതിന് വ്യക്തമായ ഉത്തരമുണ്ട്.

allow-local-network യഥാർത്ഥത്തിൽ എന്താണ് ഉൾക്കൊള്ളുന്നത്

ക്ലയന്റുകൾ ആ ഓപ്ഷൻ വ്യത്യസ്ത രീതിയിൽ നടപ്പാക്കുന്നു. ചിലത് യന്ത്രം ബന്ധിപ്പിച്ചിരിക്കുന്ന സബ്‌നെറ്റിന് റൂട്ടുകൾ ചേർക്കുന്നു, ചിലത് RFC 1918 ശ്രേണികൾ ചേർക്കുന്നു, കുറച്ച് എണ്ണം ഡിഫോൾട്ട് ഗേറ്റ്‌വേ മാത്രം ഒഴിവാക്കുന്നു. അവയിലൊന്നും നിങ്ങളുടെ ഓഫീസ് റൂട്ടർ ഒരു സ്റ്റോറേജ് VLAN, ലാബ് സെഗ്മെന്റ് അല്ലെങ്കിൽ പ്രിന്റർ സബ്‌നെറ്റ് കൂടി സേവിക്കുന്നുവെന്ന് അറിയില്ല, കാരണം ആ പ്രിഫിക്സുകൾ ക്ലയന്റ് കാണുന്ന വയറിൽ ഇല്ല. ലേബൽ നിങ്ങളുടെ ടോപ്പോളജിയെ വിവരിക്കുന്നുവെന്ന് അനുമാനിക്കുന്നതിന് പകരം കൃത്യമായ പെരുമാറ്റത്തിന് ക്ലയന്റിന്റെ സ്വന്തം ഡോക്യുമെന്റേഷൻ വായിക്കുക.

ഈ വ്യത്യാസം ഏറ്റവും പ്രധാനമാകുന്നത് പൂർണ ടണൽ രൂപകൽപ്പനയിലാണ്, അവിടെ എല്ലാ ട്രാഫിക്കും VPN വഴി പോകാൻ ക്ലയന്റ് ഡിഫോൾട്ട് റൂട്ട് ബോധപൂർവ്വം മാറ്റിസ്ഥാപിക്കുന്നു. അതാണ് രൂപകൽപ്പനയുടെ മുഴുവൻ ഉദ്ദേശ്യം, അതാണ് പ്രാദേശിക റൂട്ട് ചെയ്ത നെറ്റ്‌വർക്കുകളെ അപ്രത്യക്ഷമാക്കുന്നതും. അവയെ ഒരിക്കലും സ്വന്തം റൂട്ട് ഉൾക്കൊണ്ടിരുന്നില്ല; അവ ഇപ്പോൾ മാറ്റിസ്ഥാപിച്ച ഡിഫോൾട്ട് റൂട്ടിൽ സഞ്ചരിക്കുകയായിരുന്നു. തനിക്ക് നിലനിൽപ്പുള്ളതായി അറിയാത്തത് ക്ലയന്റിന് റൂട്ട് ചെയ്യാനാകില്ല, അത് സ്വന്തം ഇന്റർഫേസിൽ ഘടിപ്പിച്ച പ്രിഫിക്സുകൾ മാത്രമാണ് പഠിക്കുന്നത്. ബാക്കിയെല്ലാം ടോപ്പോളജി അറിയുന്ന ഒരാൾ വിവരിക്കണം.

കണക്ട് ചെയ്ത റൂട്ടുകൾ ആദ്യ റൂട്ടറിൽ നിൽക്കുന്നു

192.168.10.20/24-ൽ ഉള്ളതും ഗേറ്റ്‌വേ 192.168.10.1 ഉള്ളതുമായ ഒരു വർക്ക്‌സ്റ്റേഷന് 192.168.10.0/24-നായി സ്വയമേവ ഒരു കണക്ട് ചെയ്ത റൂട്ട് ലഭിക്കുന്നു. 192.168.20.0/24-ലെ സ്റ്റോറേജ് VLAN മറ്റൊരു പ്രിഫിക്സാണ്, ആ ഗേറ്റ്‌വേ വഴി മാത്രം എത്താം, വർക്ക്‌സ്റ്റേഷന് ഡിഫോൾട്ടിനപ്പുറം അതിന് റൂട്ടില്ല. ടണൽ ഉയരുന്നതിന് മുമ്പ് സാധാരണ ഡിഫോൾട്ട് യാദൃച്ഛികമായി സ്റ്റോറേജ് ട്രാഫിക് 192.168.10.1-ലേക്ക് അയയ്ക്കുന്നു, എല്ലാം പ്രവർത്തിക്കുന്നു.

VPN പൂർണ ടണൽ ഡിഫോൾട്ട് ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ, 192.168.20.1-ലേക്കുള്ള പാക്കറ്റുകൾ പുതിയ ഡിഫോൾട്ട് പിന്തുടർന്ന് ടണലിലേക്ക് പോകുന്നു. ആ പ്രിഫിക്സ് എവിടെയാണെന്ന് വിദൂര ഗേറ്റ്‌വേയ്ക്ക് ഒരു ധാരണയുമില്ല, അതിനാൽ അത് അവ ഉപേക്ഷിക്കുന്നു അല്ലെങ്കിൽ ഉപയോഗശൂന്യമായ എവിടെയോ കൈമാറുന്നു. സ്റ്റോറേജ് VLAN-ൽ ഒന്നും തെറ്റായി ക്രമീകരിച്ചിരുന്നില്ല; അതിന്റെ പാത കടം വാങ്ങിയതായിരുന്നു, കടം തിരിച്ചുചോദിച്ചു.

പ്രലോഭനം എന്നത് /1 റൂട്ട് ജോടി അല്ലെങ്കിൽ രണ്ടാമത്തെ ഡിഫോൾട്ട് പോലുള്ള വിശാലമായ ഒഴിവിലേക്ക് കൈ നീട്ടുന്നതാണ്. അതിനെ ചെറുക്കുക. ഒഴിവ് എത്ര ഇടുങ്ങിയതോ അത്രയും വിശദീകരിക്കാനും പരിശോധിക്കാനും നെറ്റ്‌വർക്ക് മാറുമ്പോൾ നീക്കം ചെയ്യാനും എളുപ്പം.

ഒഴിവ് വിജയിക്കുന്ന പട്ടികയിൽ വയ്ക്കുക

ഒരു റൂട്ടിംഗ് പട്ടികയ്ക്കുള്ളിൽ, /24 ഏറ്റവും നീളമുള്ള പ്രിഫിക്സ് പൊരുത്തത്തിലൂടെ /0 അല്ലെങ്കിൽ /1-നെ തോൽപ്പിക്കുന്നു, അതിനാൽ പ്രാദേശിക ഗേറ്റ്‌വേ വഴി സ്റ്റോറേജ് VLAN-ലേക്കുള്ള നിർദ്ദിഷ്ട റൂട്ട് മതി, പട്ടിക ഒട്ടും പരിശോധിക്കുകയാണെങ്കിൽ. Linux-ൽ സാധാരണ രൂപം ചെറുതാണ്:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

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

തുടർന്ന് ക്ലയന്റ് പിന്തുണയ്ക്കുന്ന സംവിധാനത്തിലൂടെയോ ഇന്റർഫേസ് ഉള്ള നെറ്റ്‌വർക്ക് മാനേജറിലൂടെയോ എൻട്രി സ്ഥിരമാക്കുക. പ്രോംപ്റ്റിൽ ടൈപ്പ് ചെയ്ത റൂട്ട് അടുത്ത വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ അപ്രത്യക്ഷമാകും, ഒരു Wi-Fi ഗേറ്റ്‌വേയിൽ ബന്ധിച്ച റൂട്ട് ലാപ്‌ടോപ്പ് സന്ദർശിക്കുന്ന അടുത്ത നെറ്റ്‌വർക്കിലേക്ക് കൊണ്ടുപോകാനാവില്ല.

പേരുകളും നയവും റൂട്ടുകളെ പിന്തുടരുന്നില്ല

റൂട്ട് നന്നാക്കുന്നത് പാക്കറ്റുകൾ തിരികെ നൽകുന്നു, പേരുകളല്ല. പ്രാദേശിക ഉപകരണങ്ങൾ അവയെക്കുറിച്ച് ഒന്നുമറിയാത്ത ഒരു അടിച്ചേൽപ്പിച്ച റിസോൾവർ വഴി പരിഹരിക്കപ്പെടുന്നുവെങ്കിൽ, വിലാസം എത്താവുന്നതാണെങ്കിലും മൗണ്ട് ഇപ്പോഴും പരാജയപ്പെടുന്നു. പ്രാദേശിക പേരുകൾക്ക് പ്രാദേശിക അല്ലെങ്കിൽ വിഭജിത DNS ക്രമീകരണം ആവശ്യമാണ്, അത് റൂട്ട് ഒഴിവിൽ നിന്ന് വേറിട്ട തീരുമാനമാണ്.

നയം വീണ്ടും വേറിട്ടതാണ്. VPN ക്ലയന്റിന്റെ പ്രാദേശിക-പ്രവേശന ഫിൽട്ടർ സ്വകാര്യ ശ്രേണികളിലേക്കുള്ള ട്രാഫിക് ബോധപൂർവ്വം വിലക്കാം, ഒരു റൂട്ട് ആ നിയമത്തെ മറികടക്കുന്നില്ല. വിശ്വസനീയമല്ലാത്ത നെറ്റ്‌വർക്കിൽ, സ്വകാര്യ വിലാസം ലക്ഷ്യം നിങ്ങളുടെ സ്റ്റോറേജ് സർവറാണെന്നതിന് തെളിവുമല്ല, അതിനാൽ ഒഴിവ് റൂട്ടിന്റെ അത്രതന്നെ നിർദ്ദിഷ്ടമായിരിക്കണം.

നിങ്ങൾക്ക് കൈമാറാവുന്ന ഒരു കരാർ

പൂർത്തിയായ രൂപകൽപ്പന ഒരു ചെറിയ പട്ടികയായി വായിക്കപ്പെടണം: പൊതുവായ ഇന്റർനെറ്റ് ട്രാഫിക് ടണലിനെ പിന്തുടരുന്നു, ഈ പേരിട്ട പ്രാദേശിക പ്രിഫിക്സുകൾ പ്രാദേശിക റൂട്ടർ വഴി അവയുടെ പാത നിലനിർത്തുന്നു. പ്രിഫിക്സുകൾ, അടുത്ത ഹോപ്പ്, അവയോടൊപ്പം വരുന്ന DNS പ്രത്യയം എന്നിവ എഴുതിവയ്ക്കുക, റൂട്ടിംഗ് പട്ടിക വായിക്കാതെ ആർക്കെങ്കിലും പരിശോധിക്കാൻ കഴിയുന്നത്ര ചെറുതായി പട്ടിക സൂക്ഷിക്കുക.

പ്രാദേശിക, വിദൂര ശ്രേണികൾ തമ്മിലുള്ള ഓവർലാപ്പ് ശ്രദ്ധിക്കുക. VPN-ന് പിന്നിലുള്ള എന്തെങ്കിലുമായി പ്രിഫിക്സ് പങ്കിടുന്ന ഒരു സ്റ്റോറേജ് VLAN കൂടുതൽ നിർദ്ദിഷ്ടമായ റൂട്ടിലേക്ക് പരിഹരിക്കപ്പെടും, അതിൽ നിന്നുള്ള പെരുമാറ്റം ഇടയ്ക്കിടെ സംഭവിക്കുന്നതായി തോന്നുന്ന രീതിയിൽ ആശയക്കുഴപ്പം ഉണ്ടാക്കുന്നു. ഒരു വശം വീണ്ടും അക്കമിടുന്നത് സാധാരണയായി അവ്യക്തത എന്നെന്നും ഡീബഗ് ചെയ്യുന്നതിനേക്കാൾ വിലകുറഞ്ഞതാണ്.

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