റൂട്ട് അധിഷ്ഠിത vs നയ അധിഷ്ഠിത സൈറ്റ്-ടു-സൈറ്റ് VPN: എന്താണ് വ്യത്യാസം
നയ അധിഷ്ഠിത IPsec ഒരു സെലക്ടർ ഉപയോഗിച്ച് ട്രാഫിക് തിരഞ്ഞെടുക്കുന്നു; റൂട്ട് അധിഷ്ഠിതം അതിനെ ടണൽ ഇന്റർഫേസിലൂടെ അയയ്ക്കുന്നു. രണ്ടിനും ഇപ്പോഴും ഫയർവാൾ നിയമങ്ങളും മടങ്ങിവരവ് റൂട്ടും വേണം.
രണ്ട് രൂപകൽപ്പനകളും ഒരേ ട്രാഫിക്കിനെ ഒരേ IPsec യന്ത്രം കൊണ്ട് സംരക്ഷിക്കുന്നു, ഏത് പാക്കറ്റ് ടണലിൽ പ്രവേശിക്കുന്നു എന്ന് തീരുമാനിക്കുന്നതിൽ അവ വ്യത്യസ്തമാണ്. നയ അധിഷ്ഠിത കണക്ഷനിൽ ചർച്ച ചെയ്ത ട്രാഫിക് സെലക്ടർമാർ ആ ജോലി ചെയ്യുന്നു; റൂട്ട് അധിഷ്ഠിതത്തിൽ ടണൽ ഇന്റർഫേസിലേക്ക് ചൂണ്ടുന്ന ഒരു റൂട്ട് ചെയ്യുന്നു. രണ്ടിനെയും കൂട്ടിക്കലർത്തിയാൽ ടണൽ സ്ഥാപിതമായി എന്ന് റിപ്പോർട്ട് ചെയ്യുകയും എന്നാൽ ആപ്ലിക്കേഷൻ എങ്ങും എത്താതിരിക്കുകയും ചെയ്യുന്ന പരിചിതമായ പിന്തുണാ ത്രെഡ് ഉണ്ടാകുന്നു. നെറ്റ്വർക്ക് ചേർക്കുമ്പോൾ, റൂട്ടിംഗ് പ്രോട്ടോക്കോൾ പ്രവർത്തിപ്പിക്കുമ്പോൾ, അല്ലെങ്കിൽ തെറ്റായ പുറത്തേക്കുള്ള വഴിയിലൂടെ നിശബ്ദമായി പുറത്തുപോകുന്ന ഒരു പാത ഡീബഗ് ചെയ്യുമ്പോൾ ഈ വ്യത്യാസം ഏറ്റവും പ്രധാനമാണ്.
ടണലിലേക്ക് എന്ത് പ്രവേശിക്കുന്നു എന്ന് തീരുമാനിക്കാനുള്ള രണ്ട് വഴികൾ
നയ അധിഷ്ഠിത VPN ഉറവിട, ലക്ഷ്യ പ്രിഫിക്സുകളുമായി പൊരുത്തപ്പെടുന്ന ഒരു സുരക്ഷാ നയം നിർമ്മിച്ച്, പൊരുത്തപ്പെടുന്ന എല്ലാം എൻക്രിപ്റ്റ് ചെയ്യുന്നു. ഇണയ്ക്ക് പൊരുത്തപ്പെടുന്ന സെലക്ടർമാരെ ചർച്ച ചെയ്യേണ്ടതുണ്ട്, അതിനാൽ ഫലപ്രദമായ പരിധി ഒടുവിൽ ഇരുവശവും നിർദ്ദേശിച്ചതിന്റെ വിഭജനമായി മാറുന്നു. ആ വിഭജനത്തിന് പുറത്ത് ഒന്നും സംരക്ഷിക്കപ്പെടുന്നില്ല, റൂട്ടിംഗ് പട്ടിക എന്ത് പറഞ്ഞാലും.
റൂട്ട് അധിഷ്ഠിത VPN ടണലിനെ പ്രതിനിധീകരിക്കുന്ന ഒരു ഇന്റർഫേസ് സൃഷ്ടിച്ച് റൂട്ടിംഗ് പട്ടികയ്ക്ക് അതിലേക്ക് ട്രാഫിക് അയയ്ക്കാൻ അനുവദിക്കുന്നു. IKE ഡീമൺ ഇപ്പോഴും അവസ്ഥയും ഓരോ ഇന്റർഫേസിന്റെ നയവും ഇൻസ്റ്റാൾ ചെയ്യുന്നു, റൂട്ടുകൾ എൻക്രിപ്ഷനെ മാറ്റിസ്ഥാപിച്ചു എന്ന് തീരുമാനിക്കുമ്പോൾ ആളുകൾ ഒഴിവാക്കുന്ന വിശദാംശം അതാണ്. രണ്ട് രൂപകൽപ്പനകളും IPsec കൊണ്ട് എൻക്രിപ്റ്റ് ചെയ്യുന്നു; തിരഞ്ഞെടുപ്പ് സംവിധാനം മാത്രം വ്യത്യസ്തമാണ്.
താഴെയുള്ള താരതമ്യം സ്കോർകാർഡായല്ല, പരാജയ സൂചനകളുടെ ഒരു കൂട്ടമായി വായിക്കുക, കാരണം ഒരു നിരയും സ്വയം വിജയിക്കുന്നില്ല.
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
നയ അധിഷ്ഠിതം: സെലക്ടർ ആണ് കരാർ
സെലക്ടർമാർ ചർച്ച ചെയ്യപ്പെടുന്നു, വെറുതെ കോൺഫിഗർ ചെയ്യുന്നില്ല. ഒരു വശത്ത് 10.10.0.0/16 ഉം മറുവശത്ത് 10.10.1.0/24 ഉം നിർദ്ദേശിക്കുക, അപ്പോൾ അസോസിയേഷൻ ചർച്ച നിൽക്കുന്നതിനെ ഉൾക്കൊള്ളും, മറ്റെല്ലാ ഹോസ്റ്റുകളും പുറത്ത് നിൽക്കും.
കോൺഫിഗറേഷൻ ഫയലിന് പകരം ഇൻസ്റ്റാൾ ചെയ്ത അവസ്ഥ വായിക്കുക. Linux ഇണയിൽ കെർണലിന്റെ സ്വന്തം പട്ടികകളാണ് അടിസ്ഥാന സത്യം, ചർച്ചയിൽ നിന്ന് എന്ത് അവശേഷിച്ചു എന്ന് അവ കാണിക്കുന്നു. ശരിയായ പ്രിഫിക്സുകൾ പേരിടുകയും എന്നാൽ പൊരുത്തപ്പെടുന്ന അവസ്ഥ ഇല്ലാതിരിക്കുകയും ചെയ്യുന്ന നയം അർത്ഥമാക്കുന്നത് അസോസിയേഷൻ ഒരിക്കലും ഉയർന്നില്ല എന്നാണ്. തെറ്റായ പ്രിഫിക്സിനുള്ള നയവുമായി ജോടിയാക്കിയ അവസ്ഥ വിപരീത പ്രശ്നമാണ്, അത് ആരോഗ്യകരമായി തോന്നുന്ന ടണൽ സൃഷ്ടിക്കുന്നു, എന്നാൽ ഒരു സബ്നെറ്റ് എങ്ങും എത്തുന്നില്ല.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasനിങ്ങൾ സംരക്ഷിക്കുന്നു എന്ന് കരുതുന്ന പ്രിഫിക്സുകളുമായി രണ്ട് ഔട്ട്പുട്ടുകളും താരതമ്യം ചെയ്യുക. ആ ഒരു താരതമ്യം പ്രവർത്തിക്കുന്ന ടണലും എത്തിച്ചേരാനാകാത്ത സെർവറും സംബന്ധിച്ച മിക്ക റിപ്പോർട്ടുകളും പരിഹരിക്കുന്നു. ഏത് ഇണയെ മാറ്റണം എന്നും അത് കാണിക്കുന്നു, കാരണം പൊരുത്തക്കേട് സാധാരണയായി ഒരു ദിശയിൽ മാത്രമേ കാണൂ.
റൂട്ട് അധിഷ്ഠിതം: ഇന്റർഫേസ് ആണ് കരാർ
XFRM ഇന്റർഫേസ് ടണലിന് ഒരു പേരും ഐഡന്റിറ്റിയും നൽകുന്നു, റൂട്ടിംഗ് പട്ടിക അങ്ങനെ പറയുന്നതിനാൽ ട്രാഫിക് അതിൽ എത്തുന്നു. നിരവധി വിദൂര പ്രിഫിക്സുകൾ അപ്പോൾ സെലക്ടർ പ്രശ്നത്തിന് പകരം റൂട്ടിംഗ് പ്രശ്നമായി മാറുന്നു, ഒരു റൂട്ടിംഗ് പ്രോട്ടോക്കോളിന് അവ പ്രഖ്യാപിക്കാം. അതാണ് യഥാർത്ഥ നേട്ടം, എൻക്രിപ്ഷനല്ല.
ഇന്റർഫേസ് നയത്തിന്റെ ആവശ്യകത ഒഴിവാക്കുന്നില്ല. ഡീമൺ ഇന്റർഫേസിന്റെ ഐഡന്റിറ്റിയുമായി ബന്ധിപ്പിച്ച നിയമങ്ങൾ ഓരോ ഇന്റർഫേസിനും ഇൻസ്റ്റാൾ ചെയ്യുന്നു, അതിനാൽ തെറ്റായ ഇന്റർഫേസിൽ എത്തുന്ന പാക്കറ്റ് ഇപ്പോഴും പരാജയപ്പെടുന്നു. ഇണ സ്വീകരിക്കാത്ത ഉറവിട വിലാസവും, തികഞ്ഞ റൂട്ട് ഉണ്ടായിരുന്നാലും പരാജയപ്പെടുന്നു. റൂട്ട് അധിഷ്ഠിതം എന്നാൽ പ്രവേശനം റൂട്ട് തീരുമാനിക്കുന്നു എന്നാണ്, നയം അപ്രത്യക്ഷമായി എന്നല്ല.
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10റൂട്ട് സ്ഥാപിച്ചതിന് ശേഷം ഇന്റർഫേസ് കൗണ്ടറുകൾ നിരീക്ഷിക്കുക. റൂട്ട് ഉണ്ട്, പക്ഷേ കൗണ്ടറുകൾ പൂജ്യത്തിൽ നിൽക്കുന്നു എങ്കിൽ ടണലിലേക്ക് ഒന്നും പൊരുത്തപ്പെടുത്തുന്നില്ല എന്നാണ്, ഇത് സാധാരണയായി ഇല്ലാത്ത റൂട്ടിനെക്കാൾ ഇല്ലാത്ത അവസ്ഥയെ സൂചിപ്പിക്കുന്നു.
രണ്ട് രൂപകൽപ്പനകൾ യഥാർത്ഥത്തിൽ വേർതിരിയുന്നിടം
നെറ്റ്വർക്ക് ചേർക്കുന്നത് ഏത് മോഡൽ നിങ്ങൾക്ക് അനുയോജ്യമെന്ന് പരിശോധിക്കാനുള്ള ഏറ്റവും വ്യക്തമായ പരീക്ഷണമാണ്. റൂട്ട് അധിഷ്ഠിത രൂപകൽപ്പന ഒരു റൂട്ട് ചേർക്കുകയും പരമാവധി ഒരിക്കൽ സെലക്ടർ വിശാലമാക്കുകയും ചെയ്യുന്നു, നയ അധിഷ്ഠിത രൂപകൽപ്പന രണ്ട് ഇണകളിലും പ്രിഫിക്സ് ജോഡികൾ തിരുത്തി വീണ്ടും ചർച്ച ചെയ്യുന്നു. രണ്ട് സ്ഥിരതയുള്ള സബ്നെറ്റുകൾ ആ തിരുത്തലിനെ നിസ്സാരമാക്കുന്നു, ഇരുപത് അതിനെ ഒരു പ്രോജക്ടാക്കുന്നു.
ഒരു മോഡലും ഫയർവാൾ മാറ്റിസ്ഥാപിക്കുന്നില്ല, താരതമ്യങ്ങൾ സാധാരണയായി ഈ ഘട്ടത്തിന് മുമ്പ് നിൽക്കുന്നു. വിശാലമായ സെലക്ടറോ വിശാലമായ റൂട്ടോ എന്ത് എൻക്രിപ്റ്റ് ചെയ്യുന്നു എന്ന് തീരുമാനിക്കുന്നു, എന്ത് അനുവദിക്കുന്നു എന്നല്ല.
MTU-വിന്റെ സ്വഭാവവും പ്രായോഗികമായി വ്യത്യസ്തമാണ്. എൻകാപ്സുലേഷൻ ഉപയോഗയോഗ്യമായ പേലോഡ് കുറയ്ക്കുന്നു, റൂട്ട് അധിഷ്ഠിത ഇന്റർഫേസ് സ്വന്തം MTU വഹിക്കുന്നു, അതിനാൽ രണ്ട് ഗേറ്റ്വേകളിലും MSS ക്ലാമ്പ് ചെയ്യുന്നത് ചെറിയ മറുപടികൾ എത്തി വലിയവ പോകുന്ന കറുത്ത കുഴി ലക്ഷണം ഒഴിവാക്കുന്നു. നയ അധിഷ്ഠിത ടണലുകളും സെലക്ടർ പാക്കറ്റ് വലിപ്പത്തെക്കുറിച്ച് ഒന്നും പറയാത്തതിനാൽ മറുവശത്ത് നിന്ന് അതേ മതിലിൽ ഇടിക്കുന്നു. ഇണയെ കുറ്റപ്പെടുത്തുന്നതിന് പകരം ക്ലാമ്പ് ബോധപൂർവ്വം സജ്ജമാക്കുക.
മടങ്ങിവരവ് പാത നഷ്ടപ്പെടുത്താതെ കുടിയേറ്റം
എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് നിലവിലുള്ള പ്രിഫിക്സ് ജോഡികൾ രേഖപ്പെടുത്തുക, തുടർന്ന് ഒരു ആപ്ലിക്കേഷൻ പാത നീക്കി അതിനെ തുടക്കം മുതൽ അവസാനം വരെ നിരീക്ഷിക്കുക. സ്ഥാപിക്കുന്ന ടണൽ കൈമാറ്റം ചെയ്യുന്ന ടണലല്ല, വ്യത്യാസം മറുപടിയുടെ ദിശയിൽ പ്രത്യക്ഷപ്പെടുന്നു.
ഇണകൾ ബന്ധിപ്പിക്കുമ്പോൾ LAN ഹോസ്റ്റുകൾക്ക് കഴിയാത്തപ്പോൾ, മടങ്ങിവരവ് റൂട്ടും വിദൂര ഹോസ്റ്റ് ഉപയോഗിക്കുന്ന ഉറവിട വിലാസവും പരിശോധിക്കുക. രണ്ട് ഇന്റർഫേസുകളുള്ള ഹോസ്റ്റിന് തെറ്റായ ഒന്നിൽ നിന്ന് മറുപടി നൽകാം, സെലക്ടർ മാറ്റം അത് ശരിയാക്കുന്നില്ല. അൽഗോരിതങ്ങൾ തിരുത്തുന്നതിന് മുമ്പ് രണ്ട് അറ്റങ്ങളിലും ട്രാഫിക് പിടിച്ചെടുക്കുക.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsജോലി ചെയ്യുമ്പോൾ ടണലിനെ ആശ്രയിക്കാത്ത ഒരു മാനേജ്മെന്റ് പാത സൂക്ഷിക്കുക. നിങ്ങൾ ഡീബഗ് ചെയ്യുന്ന കണക്ഷനിൽ ഗേറ്റ്വേയുടെ സ്വന്തം ആക്സസ് സഞ്ചരിക്കുന്നില്ലെങ്കിൽ പിന്നോട്ട് പോകാൻ എളുപ്പമാണ്.