സൈറ്റ്-ടു-സൈറ്റ് VPN-നുള്ള വിലാസ ഇടത്തിന്റെ വലുപ്പം എങ്ങനെ നിർണ്ണയിക്കാം

VPN ഉപജാലം എത്ര വലുതായിരിക്കണം എന്ന് ചോദിക്കുക, സത്യസന്ധമായ ഉത്തരം ചോദ്യത്തിനുള്ളിൽ നാല് വ്യത്യസ്ത ഉപജാലങ്ങൾ ഉണ്ടാകാം എന്നാണ്. സൈറ്റ് VPN-ൽ ഗതാഗത അന്ത്യബിന്ദുക്കൾ, സംഖ്യാക്രമീകരിച്ച ടണൽ ലിങ്കുകൾ, സംരക്ഷിത LAN-ന്റെ പ്രിഫിക്സുകൾ, കൈകാര്യം ചെയ്യുന്ന ഗേറ്റ്‌വേകളിൽ ദാതാവ് സംവരണം ചെയ്യുന്ന ഒരു അടിസ്ഥാനസൗകര്യ ഉപജാലം എന്നിവ ഉൾപ്പെടാം. ഒരു നിർദ്ദിഷ്ട രൂപകൽപ്പനയിൽ അവയിൽ ഒന്നോ രണ്ടോ മാത്രമേ ഉണ്ടാകൂ. അവയെ ഓഫീസ് ഉപകരണങ്ങളുടെ എണ്ണത്തിൽ നിന്ന് അളക്കുന്നതാണ് ആരെയും തൃപ്തിപ്പെടുത്താത്ത ഒരു /24-ൽ പദ്ധതി അവസാനിക്കുന്ന വഴി.

എന്തും അനുവദിക്കുന്നതിന് മുൻപ് നാല് റോളുകൾക്ക് പേരിടുക

ഗതാഗത അന്ത്യബിന്ദുക്കൾ എന്നത് രണ്ട് ഗേറ്റ്‌വേകൾ ഇന്റർനെറ്റ് അല്ലെങ്കിൽ സ്വകാര്യ സർക്യൂട്ടിലൂടെ പരസ്പരം എത്താൻ ഉപയോഗിക്കുന്ന വിലാസങ്ങളാണ്, അവയുടെ എണ്ണം LAN-ൽ നിന്നല്ല, ഗേറ്റ്‌വേ, റിഡണ്ടൻസി മാതൃകയിൽ നിന്നാണ് വരുന്നത്. ആന്തരിക ടണൽ ലിങ്കുകൾ രൂപകൽപ്പന പോയിന്റ്-ടു-പോയിന്റ് ഇന്റർഫേസിന് നമ്പർ നൽകുന്നിടത്ത് മാത്രമേ ഉണ്ടാകൂ, നയാധിഷ്ഠിത IPsec കോൺഫിഗറേഷൻ സാധാരണയായി അത് ചെയ്യാറില്ല. സംരക്ഷിത പ്രിഫിക്സുകൾ റൂട്ട് ചെയ്യാവുന്ന യഥാർത്ഥ ഓഫീസ് അല്ലെങ്കിൽ VPC ശൃംഖലകളാണ്, ദാതാവ് സംവരണം ചെയ്ത ഉപജാലം കൈകാര്യം ചെയ്യുന്ന സേവനത്തിന്റേതാണ്.

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

ip -br addr show
ip route show | head -40

ആ രണ്ട് കമാൻഡുകൾ ബന്ധിപ്പിച്ച ശൃംഖലകളുടെയും അവയ്ക്കപ്പുറമുള്ള എല്ലാത്തിനെയും എത്തുന്ന പാതകളുടെയും പ്രാദേശിക കാഴ്ച നൽകുന്നു. ഓരോ സൈറ്റിലും പട്ടിക ആവർത്തിക്കുക, കാരണം ഒരു സൈറ്റിന്റെ ഔട്ട്പുട്ടിൽ നിർമ്മിച്ച പദ്ധതി അടുത്ത സൈറ്റിന്റേതുമായി കൂട്ടിയിടിക്കും. ഒരു ബ്ലോക്ക് പോലും അനുവദിക്കുന്നതിന് മുൻപ് ഔട്ട്പുട്ടുകൾ ശേഖരിക്കുക.

ലിങ്കുകളും ടോപ്പോളജിയും എണ്ണുക, ഉപകരണങ്ങളല്ല

എട്ട് പോയിന്റ്-ടു-പോയിന്റ് അയൽബന്ധങ്ങളുള്ള രൂപകൽപ്പന എട്ട് ബ്ലോക്കുകൾ ചെലവഴിക്കുന്നു, ഒന്നല്ല. /30-ൽ ഓരോ ബ്ലോക്കും രണ്ട് ഹോസ്റ്റുകളെ ബന്ധിപ്പിക്കാൻ നാല് വിലാസങ്ങൾ ചെലവഴിക്കുന്നു, അതിനാൽ പദ്ധതി പതിനാറ് ഉപയോഗയോഗ്യമായ അന്ത്യബിന്ദുക്കൾക്ക് മുപ്പത്തിരണ്ട് വിലാസങ്ങൾ വഹിക്കുന്നു, ബജറ്റ് താങ്ങേണ്ട സംഖ്യ അതാണ്. /31 ലിങ്കുകൾ പിന്തുണയ്ക്കുന്ന പ്ലാറ്റ്ഫോം പകുതി ചെലവഴിക്കുന്നു, പക്ഷേ രണ്ട് അറ്റങ്ങളും സേവനവും ഈ മാതൃകയിൽ യോജിക്കുമ്പോൾ മാത്രം. ബജറ്റ് താഴേക്കല്ല മുകളിലേക്ക് റൗണ്ട് ചെയ്യുക, കാരണം പിന്നീട് ബ്ലോക്ക് ചെറുതാക്കുന്നത് സജീവമായ ലിങ്കുകൾ വീണ്ടും നമ്പർ ചെയ്യുന്നു എന്നാണ് അർത്ഥം.

ദാതാവിന്റെ പരിമിതികൾ പൊതുവായ രീതിയെ മറികടക്കുന്നു. രേഖപ്പെടുത്തിയ ആന്തരിക ടണൽ ശ്രേണി നിങ്ങളുടെ റൗട്ടറുകളിൽ /31 പ്രവർത്തിക്കുന്നിടത്തും /30 ആവശ്യപ്പെടാം, കൈകാര്യം ചെയ്യുന്ന ഗേറ്റ്‌വേ അതിന്റെ സ്വന്തം ഉപജാലത്തിന് നിർദ്ദിഷ്ട മാസ്ക് ആവശ്യപ്പെടാം. മറ്റൊരു പ്ലാറ്റ്ഫോമിൽ നിന്ന് കടമെടുത്ത നിയമം പ്രയോഗിക്കുന്നതിന് മുൻപ് സേവന വ്യവസ്ഥ വായിക്കുക.

ബഹു-ബിന്ദു ഓവർലേ ഗണിതം വീണ്ടും മാറ്റുന്നു: ഓരോ ഗേറ്റ്‌വേയ്ക്കും ഒരു വിലാസം, അവയ്ക്കിടയിലുള്ള എത്തിച്ചേരൽ ഓവർലേ കൈകാര്യം ചെയ്യുന്നു. സൈറ്റുകളെ ബ്ലോക്ക് വലുപ്പം കൊണ്ട് ഗുണിക്കുന്നതിന് മുൻപ് നടപ്പാക്കൽ യഥാർത്ഥത്തിൽ ഏത് ടോപ്പോളജി ഉപയോഗിക്കുന്നു എന്ന് തീരുമാനിക്കുക.

വളർച്ചയ്ക്ക് പദ്ധതിയിൽ സ്വന്തം വരി അർഹതയുണ്ട്. സുസ്ഥിരമായ അടിസ്ഥാനസൗകര്യ ശ്രേണി സംവരണം ചെയ്യുന്നത് ന്യായമാണ്, അതിനുള്ളിൽ ഏത് ചെറിയ അനുവദനങ്ങൾ ഉണ്ടെന്ന് രേഖപ്പെടുത്തുന്നതും അങ്ങനെ തന്നെ, അടുത്ത എൻജിനീയർ ഈ സംവരണത്തെ ഒരൊറ്റ പ്രക്ഷേപണ ഡൊമെയ്നായി വായിക്കാതിരിക്കാൻ.

ഗേറ്റ്‌വേ ഉപജാലം LAN കുളത്തിന് പുറത്ത് നിർത്തുക

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

ഇതേ കാര്യം ക്ലൗഡ് VPN കണക്ഷനുകളിലെ ടണൽ ശ്രേണികൾക്കും ബാധകമാണ്, അവിടെ ദാതാവ് ഓരോ ടണലിനും സ്വന്തം ഉപയോഗത്തിനായി ചെറിയ ആന്തരിക ശ്രേണി അനുവദിക്കുന്നു. ആ ശ്രേണി നിങ്ങളുടെ ശാഖാ സെർവറുകൾ കഴിയുന്ന സ്ഥലമല്ല, അത് വിഭജിക്കേണ്ടത് നിങ്ങളുടേതല്ല.

aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table

ബാഹ്യ വിലാസങ്ങൾ പട്ടികപ്പെടുത്തുന്നത് ദാതാവ് എന്ത് അനുവദിച്ചു, ഏത് അനുബന്ധ ടണൽ ഇപ്പോൾ സജീവമാണ് എന്ന് സ്ഥിരീകരിക്കുന്നു. കണക്ഷൻ നിലവിൽ വരുന്നതിന് മുൻപ് എഴുതിയ രൂപകൽപ്പന രേഖ വായിക്കുന്നതിനെക്കാൾ ഇത് വേഗമേറിയതാണ്.

ഓരോ പ്രിഫിക്സിനും റോൾ, ഉടമ, വളർച്ച രേഖപ്പെടുത്തുക

പ്രവർത്തനത്തോടുള്ള സമ്പർക്കത്തിൽ അതിജീവിക്കുന്ന പദ്ധതി ഓരോ പ്രിഫിക്സിനും അത് ഏത് റോൾ വഹിക്കുന്നു, വിദൂര അറ്റം ആര് അനുവദിക്കുന്നു, എത്ര സ്ഥലം ബാക്കിയുണ്ട് എന്ന് പറയുന്നു. ഉടമ ഫീൽഡ് ഇല്ലാതെ രണ്ട് ടീമുകൾ ഒരേ പാദത്തിൽ ഒരേ /24 അനുവദിക്കുന്നു, കൂട്ടിയിടി ടണൽ ഉയരുമ്പോൾ മാത്രം പ്രത്യക്ഷപ്പെടുന്നു.

ഈ ശ്രേണികൾ മറ്റ് ടണലുകളിലൂടെ വരുന്ന വീട്, ശാഖാ പ്രിഫിക്സുകളിൽ നിന്ന് അകറ്റി നിർത്തുക, കാരണം ഇടത്തിന്റെ ഓവർലാപ്പാണ് സാധാരണ കാരണം സൈറ്റുകൾക്കിടയിലുള്ള കണക്ഷൻ വിജയകരമായി ചർച്ച ചെയ്തിട്ടും ഒരു ട്രാഫിക്കും കടത്തിവിടാതിരിക്കാൻ.

ആന്തരിക ലിങ്ക് വിലാസങ്ങൾ അനുവദിക്കുന്നത് അവയ്ക്ക് പിന്നിലുള്ള LAN ശൃംഖലകൾ പ്രഖ്യാപിക്കുന്നില്ല. റൂട്ടുകൾ അല്ലെങ്കിൽ ട്രാഫിക് തിരഞ്ഞെടുക്കികൾ, തിരിച്ചുള്ള പാതകൾ, ആക്സസ് നിയമങ്ങൾ എന്നിവ വേറിട്ട ജോലി ഇനങ്ങളാണ്, പദ്ധതി അത് പറയണം, സംഖ്യാക്രമീകരിച്ച ഇന്റർഫേസ് നിങ്ങൾക്കുവേണ്ടി റൂട്ടിംഗ് ചെയ്യുന്നു എന്ന് സൂചിപ്പിക്കുന്നതിന് പകരം.