നിങ്ങളുടെ ശാഖാ നെറ്റ്വർക്കിന് ഏത് Sophos RED മോഡ് അനുയോജ്യമാണ്?
RED വിദൂര സൈറ്റിന്റെ പങ്കാണ്, പ്രോട്ടോക്കോൾ അല്ല. ശാഖയുടെ ഗേറ്റ്വേയും DHCP-ഉം ആരുടെ കൈവശമാണ് എന്നതനുസരിച്ച് Standard/Unified, Standard/Split അല്ലെങ്കിൽ Transparent/Split തിരഞ്ഞെടുക്കുക.
Sophos RED ഒരു VPN പ്രോട്ടോക്കോൾ അല്ല, അത് വിദൂര സൈറ്റിന്റെ പങ്കാണ്, അതുകൊണ്ടാണ് IPsec അല്ലെങ്കിൽ OpenVPN-മായി താരതമ്യം ചെയ്യുന്നത് തെറ്റായ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നത്. ഉപകരണം ഒരു കേന്ദ്ര ഫയർവാളിന്റെ നിയന്ത്രണം ശാഖയിലേക്ക് വ്യാപിപ്പിക്കുന്നു, നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന മോഡ് ശാഖയുടെ ഗേറ്റ്വേ ആര് നൽകുന്നു, വിലാസങ്ങൾ ആര് വിതരണം ചെയ്യുന്നു, ഏത് ട്രാഫിക് ടണലിലൂടെ കടക്കുന്നു എന്നിവ നിർണ്ണയിക്കുന്നു. ആ മൂന്ന് ഉത്തരങ്ങൾ മോഡുകളുടെ പേരുകളേക്കാൾ പ്രധാനമാണ്. അവ ആദ്യം എഴുതിവെക്കുന്നത് ഉൽപ്പന്ന തിരഞ്ഞെടുപ്പിനെ രൂപകൽപ്പനാ തീരുമാനമാക്കി മാറ്റുന്നു.
RED ഒരു പങ്കാണ്, പ്രോട്ടോക്കോൾ അല്ല
RED ഉപകരണം ഒരു ശാഖയെ കേന്ദ്ര Sophos Firewall-ലേക്ക് ബന്ധിപ്പിക്കുന്നു, ശാഖ എന്താകുമെന്ന് ഫയർവാളിന്റെ കോൺഫിഗറേഷനാണ് നിർണ്ണയിക്കുന്നത്. ടണൽ ആ ബന്ധിപ്പിക്കലിന്റെ നടപ്പാക്കൽ വിശദാംശമാണ്, ഏത് പങ്കാളിക്കും ലക്ഷ്യമിടാവുന്ന പൊതു ഉദ്ദേശ്യ VPN അന്തിമ ബിന്ദുവല്ല.
ഈ ചട്ടക്കൂട് പ്രധാനമാണ്, കാരണം RED അനിയന്ത്രിതമായ ഒരു IPsec പങ്കാളിയുമായി പരസ്പരം മാറ്റാനാവില്ല. കേന്ദ്ര ഫയർവാൾ അതിനെ നിയന്ത്രിക്കുമെന്ന് അത് പ്രതീക്ഷിക്കുന്നു, പിന്തുണയ്ക്കുന്ന മോഡുകൾ ശാഖയുടെ എത്ര ഭാഗം അത് ഏറ്റെടുക്കുന്നു എന്ന് വിവരിക്കുന്നു. അതിനെ ഒരു സാധാരണ ടണൽ അന്തിമ ബിന്ദുവായി കാണുന്നത് ഉൽപ്പന്നം ഒരിക്കലും വാഗ്ദാനം ചെയ്യാത്ത പ്രതീക്ഷകൾ സൃഷ്ടിക്കുന്നു. അതിനെ ഒരു പങ്കായി കാണുന്നത് രൂപകൽപ്പന യഥാർത്ഥത്തിൽ നിർണ്ണയിക്കുന്ന ചോദ്യങ്ങൾ ഉയർത്തുന്നു.
ചുവടെയുള്ള മൂന്ന് വ്യവസ്ഥകൾ ഉത്തരം മാറ്റുന്നു, അവയെല്ലാം ഉടമസ്ഥതയെക്കുറിച്ചാണ്, എൻക്രിപ്ഷനെക്കുറിച്ചല്ല.
മോഡ് തിരഞ്ഞെടുക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ
ശാഖയുടെ ഗേറ്റ്വേ ആരുടേതാണ്, ശാഖയിലെ ക്ലയന്റുകൾക്കായി DHCP-ഉം DNS-ഉം ആര് നടത്തുന്നു, ടണൽ തകരാറിലും പ്രാദേശിക ഇന്റർനെറ്റ് ഔട്ട്ലെറ്റ് നിലനിൽക്കണമോ എന്ന് ചോദിക്കുക.
Standard/Unified മൂന്നിനും ഒരേ രീതിയിൽ ഉത്തരം നൽകുന്നു: ഗേറ്റ്വേയുടെയും DHCP-യുടെയും ചുമതലകൾ ഉൾപ്പെടെ ശാഖയുടെ LAN കേന്ദ്ര ഫയർവാളിന്റെ കൈവശമാണ്, ട്രാഫിക് ടണലിലൂടെ കടക്കുന്നു. Standard/Split കേന്ദ്ര നിയന്ത്രണം നിലനിർത്തി കോൺഫിഗർ ചെയ്ത നെറ്റ്വർക്കുകൾ മാത്രം ടണലിലൂടെ അയയ്ക്കുന്നു. Transparent/Split നിലവിലുള്ള ശാഖാ നെറ്റ്വർക്കിനെ അതിന്റെ സ്വന്തം ഗേറ്റ്വേയും വിലാസങ്ങളും കൈകാര്യം ചെയ്യാൻ അനുവദിക്കുന്നു, തിരഞ്ഞെടുത്ത ട്രാഫിക് മാത്രം ടണലിലേക്ക് തിരിച്ചുവിടുന്നു. മൂന്ന് മോഡുകൾ, മൂന്ന് വ്യത്യസ്ത ഉടമകൾ.
| Mode | Branch gateway and DHCP | Traffic through the tunnel |
|---|---|---|
| Standard/Unified | Central firewall owns both | All branch traffic |
| Standard/Split | Central firewall owns both | Only the configured networks |
| Transparent/Split | The existing branch router keeps both | Only the selected flows |
ആദ്യം നടുവിലെ നിര വായിക്കുക, കാരണം ടണൽ പോയാൽ ശാഖയുടെ എത്ര ഭാഗം ഇപ്പോഴും പ്രവർത്തിക്കുന്നു എന്ന് അതാണ് നിർണ്ണയിക്കുന്നത്.
ശാഖയുടെ ഗേറ്റ്വേയും DHCP-ഉം ആരുടേതാണ്
ഏകീകൃത ക്രമീകരണത്തിൽ ശാഖയ്ക്ക് സ്വതന്ത്ര ഗേറ്റ്വേ ഇല്ല, ഇത് കോൺഫിഗറേഷൻ ലളിതമാക്കുകയും തകരാർ ഒരിടത്ത് കേന്ദ്രീകരിക്കുകയും ചെയ്യുന്നു. ശാഖ ചെറുതും കേന്ദ്ര ഫയർവാളിന് ഉയർന്ന ലഭ്യതയും ഉണ്ടെങ്കിൽ ആ കേന്ദ്രീകരണം കുഴപ്പമില്ല.
സുതാര്യ വിന്യാസത്തിൽ ശാഖ അതിന്റെ റൗട്ടർ നിലനിർത്തുന്നു, തിരഞ്ഞെടുത്ത ട്രാഫിക് തിരിച്ചുവിടാൻ RED പാതയിൽ ഇരിക്കുന്നു. ഇത് പ്രാദേശിക നിയന്ത്രണം സംരക്ഷിക്കുകയും പാതയിലെ സ്ഥാനം ഇപ്പോൾ ഓരോ തിരിച്ചുവിട്ട ഒഴുക്കിനും പ്രധാനമാകുന്ന ഉപകരണം കൂട്ടിച്ചേർക്കുകയും ചെയ്യുന്നു. അത് എവിടെ ഇരിക്കുന്നു എന്ന് രേഖപ്പെടുത്തുക, കാരണം പിന്നീട് ശാഖയുടെ റൗട്ടറിൽ വരുന്ന മാറ്റം അതിനെ നിശബ്ദമായി ഒഴിവാക്കാം. രണ്ട് ക്രമീകരണങ്ങളും പൊതുവായി വിജയിക്കുന്നില്ല; അവ ഉത്തരവാദിത്തം വ്യത്യസ്തമായി വിഭജിക്കുന്നു.
വിലാസങ്ങളുടെ ഉടമസ്ഥതയാണ് എഴുതിവെക്കേണ്ട ഭാഗം, കാരണം ഒരേ സെഗ്മെന്റിൽ രണ്ട് DHCP സർവറുകൾ ഇടയ്ക്കിടെ തകരാറുകൾ ഉണ്ടാക്കുന്നു, അവ VPN പ്രശ്നങ്ങളായി റിപ്പോർട്ട് ചെയ്യപ്പെടുന്നു.
ടണൽ വീഴുമ്പോൾ എന്ത് സംഭവിക്കുന്നു
ടണൽ തകരാറിനിടയിലും പ്രാദേശിക ഇന്റർനെറ്റ് പ്രവർത്തിക്കും എന്ന വാഗ്ദാനമായാണ് Split പ്രവർത്തനം പലപ്പോഴും വായിക്കപ്പെടുന്നത്, ആ വായന സുരക്ഷിതമല്ല. കൃത്യമായ സ്വഭാവം തിരഞ്ഞെടുത്ത മോഡിനെയും ഫേംവെയറിനെയും ഉപകരണത്തെയും ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ അതിന്റെ സ്ഥാനം സ്വീകാര്യതാ മാനദണ്ഡങ്ങളിലാണ്, ഒരു അനുമാനത്തിലല്ല.
ടണലില്ലാതെ ശാഖ ഇനി എന്ത് ചെയ്യണമെന്ന് തീരുമാനിക്കുക: പ്രാദേശിക പ്രിന്ററുകളിൽ എത്തുക, പേരുകൾ പരിഹരിക്കുക, പേയ്മെന്റുകൾ സ്വീകരിക്കുക, അല്ലെങ്കിൽ ഒന്നും ചെയ്യരുത്. തുടർന്ന് ടണൽ തടഞ്ഞ് ശാഖ നിരീക്ഷിച്ച് ആ അവസ്ഥ ബോധപൂർവം പരിശോധിക്കുക. DNS നിശബ്ദമായി നഷ്ടപ്പെടുന്ന ശാഖ ഉച്ചത്തിൽ പരാജയപ്പെടുന്നതിനേക്കാൾ മോശമാണ്, കാരണം ഹെൽപ്പ്ഡെസ്ക് കോൾ മണിക്കൂറുകൾക്ക് ശേഷമാണ് വരുന്നത്. നിരീക്ഷിച്ച ഫലം രൂപകൽപ്പനാ രേഖയിൽ എഴുതുക.
കേന്ദ്ര ആശ്രയത്വം എല്ലാ മോഡുകളിലും ഒന്നുതന്നെ: ഉപകരണത്തിന്റെ സ്വന്തം വീണ്ടെടുപ്പ് പാത ആരെങ്കിലും കൈവശം വേണം.
വിന്യസിക്കുന്നതിന് മുൻപ് ശാഖാ കരാർ എഴുതുക
ശാഖാ കരാർ ഒരു പേജിൽ ഒതുങ്ങുന്നു: ഉടമകൾ, വിലാസ സ്രോതസ്സുകൾ, ടണലിലൂടെ പോകുന്ന പ്രിഫിക്സുകൾ, ഔട്ട്ലെറ്റ് നയം, നിങ്ങൾ അംഗീകരിച്ച തടസ്സ സ്വഭാവം.
തുടർന്ന് ഉദ്ദേശിച്ചതല്ല, വിന്യസിച്ച ഫലം പരിശോധിക്കുക. ശാഖയിലെ ക്ലയന്റിന്റെ വിലാസം, അതിന്റെ സ്ഥിര ഗേറ്റ്വേ, ഏത് പ്രിഫിക്സുകൾ ടണലിലൂടെ പരിഹരിക്കപ്പെടുന്നു, ടണൽ തടഞ്ഞിരിക്കുമ്പോൾ എന്ത് ഇപ്പോഴും ഉത്തരം നൽകുന്നു എന്നിവ പരിശോധിക്കുക. അനുയോജ്യത, എത്തിച്ചേരൽ, ലൈസൻസിംഗ് എന്നിവയെല്ലാം കൃത്യമായ മോഡലിന് വെണ്ടറുടെ നിലവിലെ രേഖകളുമായി ഒത്തുനോക്കണം, കാരണം ഉൽപ്പന്നത്തിന്റെ പേര് ഒരു മോഡിനും ഉറപ്പ് നൽകുന്നില്ല. ആ പേജ് ഉപകരണ രേഖയ്ക്കൊപ്പം സൂക്ഷിക്കുക, അടുത്ത എഞ്ചിനീയർക്ക് ഡയഗ്രമല്ല, തീരുമാനങ്ങൾ പാരമ്പര്യമായി ലഭിക്കാൻ.
ip -br addr
ip route
traceroute -n 10.80.4.10
dig +short intranet.corp.exampleടണൽ തടഞ്ഞ അവസ്ഥയിൽ ആ ബ്ലോക്ക് വീണ്ടും പ്രവർത്തിപ്പിക്കുക, രണ്ട് പ്രവർത്തനങ്ങൾ തമ്മിലുള്ള വ്യത്യാസമാണ് നിങ്ങൾ യഥാർത്ഥത്തിൽ വാങ്ങിയ തടസ്സ സ്വഭാവം.