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

എല്ലാത്തിനും മുമ്പ് പിയർ ബന്ധങ്ങൾ എണ്ണുക

എൻ സൈറ്റുകളുണ്ടെങ്കിൽ, പൂർണ്ണ മെഷിന് എൻ ഗുണം എൻ കുറയ്ക്കൽ ഒന്ന്, രണ്ടായി ഹരിച്ചാൽ, ടണലുകൾ വേണം; ഹബ്ബിന് എൻ മതി. അഞ്ച് സൈറ്റുകളിൽ അത് പത്ത് എതിരെ അഞ്ച്, ഇത് ഇപ്പോഴും കൈകാര്യം ചെയ്യാവുന്നതായി തോന്നുന്നു. പതിനഞ്ചിൽ അത് 105 എതിരെ പതിനഞ്ച്, വ്യത്യാസം ഇനി ഗണിതമല്ല, ജീവനക്കാരാണ്.

ആ ഓരോ ബന്ധവും നിങ്ങൾ സ്വന്തമാക്കേണ്ട അവസ്ഥ വഹിക്കുന്നു. IPsec ൽ അത് ഒരു സെക്യൂരിറ്റി അസോസിയേഷൻ, ഒരു ഐഡന്റിറ്റി, ഒരു കീ അല്ലെങ്കിൽ സർട്ടിഫിക്കറ്റ്, ഡെഡ്-പിയർ കണ്ടെത്തൽ, ഓരോ ദൂര പ്രിഫിക്സിനും കുറഞ്ഞത് ഒരു റൂട്ട് എന്നിവയാണ്. WireGuard ൽ അത് ഓരോ പിയറിനും ഒരു പബ്ലിക് കീയും ഒരു AllowedIPs ബ്ലോക്കും ആണ്, ഇത് ഓരോ പിയറിനും വിലകുറഞ്ഞതാണ്, പക്ഷേ കണ്ടെത്തൽ ഒട്ടുമില്ലാതെ വരുന്നു: പുതിയ സൈറ്റ് ഏത് വിധത്തിലും ഓരോ പഴയ സൈറ്റിലും ഒരു കോൺഫിഗറേഷൻ മാറ്റമാണ്.

വരയല്ല, ട്രാഫിക് മിശ്രണം തീരുമാനിക്കട്ടെ

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

വിചിത്രമായ കേസുകൾ നടുവിൽ ഇരിക്കുന്നു, അവയാണ് ഭൂരിപക്ഷം. ഓർഗ് ചാർട്ടിൽ നിന്ന് ഊഹിക്കുന്നതിനുപകരം തർക്കിക്കുന്നതിന് മുമ്പ് അളക്കുക.

SignalPoints to a hubPoints to a mesh
Branch-to-branch trafficOccasional, smallDominant, all day
Site countGrowing, past tenSmall and stable
Change rateFrequent adds and movesRare
Failure toleranceA second hub is affordableEvery site must survive alone

പട്ടികയെ നിയമമായല്ല, ടൈ-ബ്രേക്കറായി വായിക്കുക. നാലിൽ മൂന്ന് വരികൾ ഒരേ വശത്തേക്ക് ചൂണ്ടുന്നത് സാധാരണയായി ഡിസൈൻ തീരുമാനിക്കുന്നു; വിഭജനം എന്നാൽ ഒരു ഹൈബ്രിഡ്, മുതിർന്ന മിക്ക നെറ്റ്വർക്കുകളും ഒടുവിൽ നടത്തുന്നത് അതാണ്.

ഹബ്ബിനോട് ഫോർവേഡ് ചെയ്യാൻ പറയണം

രണ്ട് പ്രവർത്തിക്കുന്ന സ്പോക്ക്-ടു-ഹബ് ടണലുകൾ സ്പോക്ക്-ടു-സ്പോക്ക് ആക്സസ് സൃഷ്ടിക്കുന്നില്ല. ഹബ്ബിൽ IP ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമാക്കണം, ഓരോ സ്പോക്ക് നെറ്റ്വർക്കിലേക്കും ഒരു റൂട്ട് വേണം, ആ ട്രാൻസിറ്റ് അനുവദിക്കുന്ന ഒരു ഫയർവാൾ നിയമം വേണം, മടക്കപ്പാത കണക്കാക്കണം; ഓരോ സ്പോക്കിനും മറ്റേ സൈറ്റിന്റെ പ്രിഫിക്സുകൾക്ക് ഒരു റൂട്ട് വേണം. ഒരു Linux ഹബ്ബിൽ അത് net.ipv4.ip_forward=1 കൂടാതെ ഒരു FORWARD ചെയിനും ആണ്, അത് ആ ജോടിയെ നിശ്ശബ്ദമായി ഉപേക്ഷിക്കരുത്; നയാധിഷ്ഠിത IPsec ൽ ഇരു അറ്റങ്ങളിലും ദൂര സ്പോക്ക് സബ്നെറ്റ് ലിസ്റ്റ് ചെയ്യുന്ന ട്രാഫിക് സെലക്ടറുകളാണ്. strongSwan ന്റെ ഫോർവേഡിംഗ് കുറിപ്പുകൾ നിങ്ങൾക്ക് നഷ്ടമായ ലെയർ അതാണെങ്കിൽ കേർണൽ, ഫയർവാൾ വശം ഉൾക്കൊള്ളുന്നു. വിലകുറഞ്ഞ പരിശോധന എന്നാൽ ഒരു സ്പോക്കിൽ നിന്ന് മറ്റേതിലെ ഒരു സേവനത്തിലേക്ക് ട്രാഫിക് അയച്ചുകൊണ്ട് ഹബ്ബിന്റെ കൗണ്ടറുകൾ നോക്കുന്നതാണ്; ഒരിക്കലും കൂടാത്ത ഒരു നിയമം എന്നാൽ റൂട്ടല്ല, ക്രമമാണ് തെറ്റ്.

കേന്ദ്ര നയമാണ് ഉപയോഗപ്രദമായ ഭാഗം. ബ്രാഞ്ചുകൾ പരസ്പരം എത്താതെ പങ്കിട്ട സേവനങ്ങളിൽ എത്താൻ അനുവദിക്കാം, ആ ആക്സസ് മാട്രിക്സ് വ്യക്തമായി എഴുതിവയ്ക്കുന്നത് മൂല്യവത്താണ്. കാണാത്ത റൂട്ടുകൾ ആരെങ്കിലും വായിക്കാവുന്ന ഒരു നിയമത്തിന് മോശം പകരമാണ്.

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

ആദ്യം പരാജയം രൂപകൽപ്പന ചെയ്യുക, പിന്നെ സാധാരണ പാത

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

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

ഫെയിലോവറിന് കുറുകെ ഒരു TCP സെഷൻ ജീവനോടെ നിലനിർത്താൻ ഒരു ഡിസൈനും സ്വയം ചെയ്യുന്നില്ല. ആപ്ലിക്കേഷന് വീണ്ടും കണക്റ്റ് ചെയ്യാൻ കഴിയില്ലെങ്കിൽ, ടോപ്പോളജി നിങ്ങളുടെ പ്രശ്നമല്ല.

മാറ്റച്ചെലവ് നോക്കി തിരഞ്ഞെടുക്കുക, പിന്നെ റൂട്ടുകൾ പരിശോധിക്കുക

ഹബ്ബിൽ നിന്ന് തുടങ്ങുക, കാരണം തെറ്റാകുന്നത് അവിടെ വിലകുറഞ്ഞതാണ്, ട്രാഫിക് ന്യായീകരിക്കുന്ന ജോടികൾക്ക് നേരിട്ടുള്ള ടണലുകൾ ചേർക്കുക. ആ ഹൈബ്രിഡ് തീരുമാനിക്കാതിരിക്കലല്ല; മിക്ക സംഘടനകളും ഒരു വർഷത്തിനുള്ളിൽ എത്തുന്ന ഡിസൈൻ അതാണ്. മുഖ്യമായത് ഓരോ നേരിട്ടുള്ള ലിങ്കിനും പറയപ്പെട്ട ഒരു കാരണവും ഒരു ഉടമയും ഉണ്ടായിരിക്കുക എന്നതാണ്.

ഒന്നല്ല, രണ്ട് ഡയഗ്രങ്ങളും പരിശോധിക്കുക. സാധാരണ പാതയ്ക്ക് traceroute ഓരോ സൈറ്റിൽ നിന്നും ഓരോ സേവന പ്രിഫിക്സിലേക്കും പ്രവർത്തിപ്പിച്ച് ഹോപ്പുകൾ ഡയഗ്രത്തോട് യോജിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക. പരാജയ പാതയ്ക്ക്, ഒരു ടണൽ അടച്ച് ആവർത്തിക്കുക, കാരണം എല്ലാം പ്രവർത്തിക്കുമ്പോൾ മാത്രം പ്രവർത്തിക്കുന്ന ഒരു റൂട്ട് രൂപകൽപ്പന ചെയ്തിട്ടില്ല, കോൺഫിഗർ മാത്രമാണ് ചെയ്തിട്ടുള്ളത്.

രണ്ട് ഡയഗ്രങ്ങളും ആക്സസ് മാട്രിക്സിനൊപ്പം സൂക്ഷിക്കുക, ഒരു സൈറ്റ് ചേർക്കുമ്പോൾ അവ വീണ്ടും പരിശോധിക്കുക; നിങ്ങൾ കൈകാര്യം ചെയ്യുന്ന ചെലവ് അടുത്ത മാറ്റത്തിന്റെ ചെലവാണ്, ഇപ്പോഴത്തെ ചിത്രത്തിന്റെ ഭംഗിയല്ല.

അനുബന്ധ ലേഖനങ്ങൾ