സൈറ്റ്-ടു-സൈറ്റ് VPN-ന് എന്ത് രേഖപ്പെടുത്തണം: സെലക്ടറുകളും പരിധിയും

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

കോൺഫിഗർ ചെയ്തത് ഉടമ്പടിയിലെത്തിയതല്ല

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

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

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

റൂട്ട് അടിസ്ഥാനമാക്കിയ ടണലുകൾ വ്യത്യസ്തമായി തിരഞ്ഞെടുക്കുന്നു

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

പോളിസി അടിസ്ഥാനമാക്കിയ ഒരു ടെംപ്ലേറ്റ് റൂട്ട് അടിസ്ഥാനമാക്കിയ ടണലിൽ പകർത്തുന്നത് വിന്യാസം ഉപയോഗിക്കാത്ത ഒരു സംവിധാനത്തെ വിവരിക്കുന്ന രേഖ സൃഷ്ടിക്കുന്നു. അടുത്ത എൻജിനിയർ അവിടെ ഒരിക്കലും ഉണ്ടാകാൻ പാടില്ലാത്ത സെലക്ടറുകൾ തിരയുന്നു, ടണൽ തെറ്റായി കോൺഫിഗർ ചെയ്തതാണെന്ന് കരുതുന്നു, യഥാർത്ഥത്തിൽ അത് മോശമായി രേഖപ്പെടുത്തിയത് മാത്രമാണ്.

വിവർത്തനം അതേ പട്ടികയിൽ വരണം

NAT മറുവശത്തിന് വ്യത്യസ്തമായ ഒരു പരിധി നൽകുമ്പോൾ യഥാർത്ഥവും വിവർത്തനം ചെയ്തതുമായ പ്രിഫിക്സുകൾ ഒരുമിച്ച് രേഖപ്പെടുത്തുക. സെലക്ടറുകളും ആക്സസ് നിയമങ്ങളും ഏത് ഘട്ടത്തിൽ അവയുമായി ഒത്തുപോകുന്നു എന്ന് കുറിക്കുക, കാരണം ക്രമമാണ് അപ്പുറത്തുള്ള വശം നിങ്ങൾ എഴുതിയ വിലാസം ഒരിക്കലും കാണുമോ എന്ന് തീരുമാനിക്കുന്നത്. രണ്ട് പരിധികളിൽ ഒന്ന് മാത്രമുള്ള പട്ടിക പട്ടികയില്ലാത്തതിനേക്കാൾ മോശമാണ്, അത് പൂർണ്ണമെന്ന് തോന്നിക്കുന്നു.

NAT മാറ്റത്തിന് ശേഷം പ്രവർത്തിക്കുന്ന ഒരു ടണൽ തകർക്കുന്ന വിശദാംശം ഇതാണ്: സെലക്ടർ ഇപ്പോഴും യഥാർത്ഥ പ്രിഫിക്സുമായി ഒത്തുപോകുന്നു, മറുവശത്തിന് ഇപ്പോൾ വിവർത്തനം ചെയ്തത് ലഭിക്കുന്നു, അതിന്റെ മടക്ക റൂട്ട് ഇനി നിലവിലില്ലാത്ത ഒരു വിലാസത്തെ ചൂണ്ടിക്കാണിക്കുന്നു. രണ്ടും ഒത്തുപോകാതാകുന്ന നിമിഷത്തിൽ ഒന്നും തന്നെ ഒരു പിശക് രേഖപ്പെടുത്തുന്നില്ല.

സ്വകാര്യ DNS അതേ സ്ഥലത്ത് തന്നെ വരണം. ബന്ധപ്പെട്ട സൈറ്റിൽ നിന്ന് ഉപയോഗിക്കാനാവാത്ത ഒരു വിലാസത്തിലേക്ക് റിസോൾവ് ചെയ്യുന്ന പേര് സപ്പോർട്ട് ടിക്കറ്റ് ഘടിപ്പിച്ച ഒരു ഡോക്യുമെന്റേഷൻ പിശകാണ്, കുറ്റം ടണലിന്റെ മേൽ ചുമത്തപ്പെടും.

സേവന ആവശ്യകത ചേർക്കുക

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

തുടർന്ന് ഈ നിയമം പരിപാലിക്കുന്ന നെറ്റ്വർക്ക് അഡ്മിനിസ്ട്രേറ്ററെ പേരെടുത്ത് പറയുക. ഉടമയില്ലാത്ത ഒരു സെലക്ടർ ഇൻവെന്ററി നിശ്ശബ്ദമായി കാലഹരണപ്പെടുന്നു, രാത്രി രണ്ട് മണിക്ക് ടണൽ തകരുമ്പോൾ കാലഹരണപ്പെട്ടതും തെറ്റായതും തമ്മിൽ വ്യത്യാസം കാണില്ല. മാറ്റം ബോധപൂർവമായിരുന്നു എന്ന് സ്ഥിരീകരിക്കാൻ കഴിയുന്ന വ്യക്തിയും ഉടമ തന്നെയാണ്.

രേഖയെ ഒരു പരിശോധനാ പദ്ധതിയാക്കുക

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

swanctl --list-sas

അഞ്ച് വരികളുള്ള ഒരു അസ്ഥികൂടം സാധാരണയായി രേഖ സത്യസന്ധമായി നിലനിർത്താൻ മതിയാകും. താഴെയുള്ള പതിപ്പ് വെട്ടിച്ചുരുക്കലില്ലാതെ ഒരു മാറ്റ ടിക്കറ്റിൽ ഒതുങ്ങും:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

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