റൂട്ടെഡ് അല്ലെങ്കിൽ ബ്രിഡ്ജ്ഡ് VPN: ക്ലയന്റ് എന്തിലേക്ക് എത്തണം എന്നതിനെ അടിസ്ഥാനമാക്കി തിരഞ്ഞെടുക്കുക

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

ടിക്കറ്റ് ഡെസ്കിൽ ഒരേപോലെ തോന്നുന്ന രണ്ട് അഭ്യർത്ഥനകൾ

ജീവനക്കാരന്റെ ആവശ്യം ഒരു സേവനമാണ്, IP വഴി എത്താവുന്നത്, നിങ്ങൾ നിയന്ത്രിക്കാത്ത ഉപകരണത്തിൽ നിന്ന്. എൻജിനീയറുടെ ആവശ്യം ലിങ്ക് തലത്തിലാണ്: ഉപകരണം Ethernet ഫ്രെയിമുകളും ബ്രോഡ്കാസ്റ്റ് കണ്ടെത്തലും കാണാൻ പ്രതീക്ഷിക്കുന്നു, ഒരുപക്ഷേ താൻ ഉണ്ടെന്ന് കരുതുന്ന സെഗ്മെന്റിൽ നിന്ന് DHCP-യും.

ഇവ വ്യത്യസ്ത ചോദ്യങ്ങളാണ്, രണ്ടിനും പാലം കൊണ്ട് മറുപടി നൽകുന്നത് കാരണമില്ലാതെ ജീവനക്കാരന്റെ ആക്സസ് മുഴുവൻ ഓഫീസ് LAN-ലേക്ക് വ്യാപിപ്പിക്കുന്നു.

തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ആവശ്യം ഒരു വാക്യത്തിൽ എഴുതുക: ഏത് ലക്ഷ്യസ്ഥാനങ്ങൾ, ഏത് പ്രോട്ടോക്കോളുകൾ, ഏത് പങ്കാളികൾ ലോക്കലായി കാണണം. ഉത്തരം ഒരു ഹോസ്റ്റും പോർട്ടുമാണെങ്കിൽ, റൂട്ടിംഗ് അത് ഉൾക്കൊള്ളുന്നു. ഉത്തരം ബ്രോഡ്കാസ്റ്റ് മാത്രം സംസാരിക്കുന്ന ഉപകരണങ്ങളുമായുള്ള ഫ്രെയിം തലത്തിലുള്ള ബന്ധമാണെങ്കിൽ, പാലം മാത്രമായിരിക്കാം ഓപ്ഷൻ. ഇടയിലുള്ളതെല്ലാം പ്രൊഡക്ഷൻ LAN-ന് പകരം ഒരു ടെസ്റ്റ് സെഗ്മെന്റിന് അർഹമാണ്.

റൂട്ട് LAN അംഗത്വത്തേക്കാൾ ഇടുങ്ങിയതാണ്

റൂട്ടെഡ് ക്ലയന്റിന് ടണൽ സബ്നെറ്റിൽ ഒരു വിലാസവും നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന പ്രിഫിക്സുകൾക്കുള്ള റൂട്ടുകളും ലഭിക്കുന്നു. നയം അങ്ങനെ പറയുന്നുവെങ്കിൽ, അതിന് ആപ്ലിക്കേഷൻ സെർവറിൽ എത്താം, മറ്റൊന്നിലും എത്തില്ല. ഗേറ്റ്വേ നടപ്പാക്കൽ പോയിന്റായി മാറുന്നു, എല്ലാ പ്രസക്തമായ പാതയും അതിലൂടെ കടന്നുപോകുന്നുവെങ്കിൽ.

റൂട്ടിനെ അനുമതിയുമായി കൂട്ടിക്കലർത്തരുത്. സബ്നെറ്റിലേക്ക് എങ്ങനെ എത്തണം എന്ന് ക്ലയന്റിനോട് പറയുന്നത് മറ്റൊരു ലക്ഷ്യസ്ഥാനം പരീക്ഷിക്കുന്നതിൽ നിന്ന് അതിനെ തടയുന്നില്ല.

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

പാലം പ്രവേശന ചോദ്യം മാറ്റുന്നു

ബ്രിഡ്ജിംഗ് ഒരു ഭൗതിക ഇന്റർഫേസും TAP ഉപകരണവും സോഫ്റ്റ്വെയർ സ്വിച്ചിൽ ചേർക്കുന്നു, അതിനാൽ ദൂരെയുള്ള ഉപകരണങ്ങൾ ഒരേ ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്നിൽ ചേരുന്നു. ഇത് യഥാർത്ഥ കഴിവും യഥാർത്ഥ അപകടസാധ്യതയുമാണ്: ദൂരെയുള്ള ഉപകരണം ഇനി റൂട്ടെഡ് അതിഥിയല്ല, അത് പങ്കാളിയാണ്.

ഏത് ഉപകരണങ്ങൾക്ക് ചേരാം, ഏത് ഫ്രെയിം തരങ്ങൾ കടന്നുപോകണം, ആവശ്യമില്ലാത്ത പരസ്പരപ്രവർത്തനം എവിടെ തടയണം എന്ന് തീരുമാനിക്കുക. അഡ്രസ്സിംഗും DHCP അധികാരവും പങ്കിട്ട നെറ്റ്വർക്കിന്റെ ഭാഗമാകുന്നു, ഒരു സെഗ്മെന്റിൽ രണ്ട് DHCP സെർവറുകൾ നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന അതേ കുഴപ്പം ഉണ്ടാക്കുന്നു.

ഉപകരണത്തിന്, ഓഫീസ് LAN-നേക്കാൾ സമർപ്പിത ടെസ്റ്റ് സെഗ്മെന്റ് സാധാരണയായി കൂടുതൽ അനുയോജ്യമാണ്. മാനേജ്മെന്റ് ആക്സസ് പരീക്ഷണത്തിന് പുറത്ത് നിർത്തുക, ജോലി തീരുമ്പോൾ താൽക്കാലിക പങ്കാളിയെ എങ്ങനെ നീക്കം ചെയ്യാമെന്ന് നിർവചിക്കുക.

ഫിൽട്ടറിംഗ് രണ്ട് ടോപ്പോളജികളിലും ഉണ്ട്

പാലം സ്വതവേ ഫിൽട്ടർ ചെയ്യാനാകാത്തതല്ല, റൂട്ട് സ്വതവേ സുരക്ഷിതവുമല്ല. Linux പാലം ഫിൽട്ടറിംഗിന് സ്വന്തം ഹൂക്കുകളും സ്വന്തം നിയമ വാക്യഘടനയുമുണ്ട്, റൂട്ടെഡ് IP ഫോർവേഡിംഗിനായി എഴുതിയ നിയമം ബ്രിഡ്ജ്ഡ് ഫ്രെയിമുകൾക്ക് സ്വയമേവ ബാധകമല്ല.

അതിർത്തി വാഗ്ദാനം ചെയ്യുന്നതിന് മുമ്പ് പ്ലാറ്റ്ഫോം യഥാർത്ഥത്തിൽ എന്താണ് പിന്തുണയ്ക്കുന്നതെന്ന് പരിശോധിക്കുക:

bridge link show
nft list ruleset

TUN-ഉം TAP-ഉം ഇന്റർഫേസിന്റെ ട്രാഫിക് വിവരിക്കുന്നു, സൈഫറല്ല. ഇന്റർഫേസുകൾ മാറ്റുന്നത് അതിൽ ഒന്നും ശരിയാക്കുന്നില്ല: പിയർ പ്രാമാണീകരണം, മോഷ്ടിച്ച കീ, കാലഹരണപ്പെട്ട ക്രിപ്റ്റോഗ്രഫി നയം എന്നിവയെല്ലാം മാറ്റത്തെ അതിജീവിക്കുന്നു. ഇരു അറ്റങ്ങൾക്കും ഇപ്പോഴും ഒത്തുപോകുന്നതും ഇപ്പോഴും പിന്തുണയ്ക്കുന്നതുമായ ക്രമീകരണങ്ങൾ വേണം.

മൂന്ന് ശ്രമങ്ങളിലൂടെ അതിർത്തി തെളിയിക്കുക

സ്വീകാര്യത മൂന്ന് നിരീക്ഷണങ്ങളാണ്, ഡയഗ്രം അവലോകനമല്ല. ആവശ്യമായ പ്രവർത്തനം നടക്കണം, ബന്ധമില്ലാത്ത ലക്ഷ്യസ്ഥാനം പരാജയപ്പെടണം, ഗേറ്റ്വേയുടെ സ്വന്തം മാനേജ്മെന്റ് സേവനങ്ങൾ എത്തിപ്പെടാനാകാത്തതായി തുടരണം.

അതേ ക്ലയന്റിൽ നിന്ന് അനുവദിച്ചതും നിരസിച്ചതുമായ പാത ഓടിക്കുക, രണ്ടും രേഖപ്പെടുത്തുക:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

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