സൈറ്റ്-ടു-സൈറ്റ് vs റിമോട്ട് ആക്സസ് VPN: ഓരോന്നും എന്താണ് ബന്ധിപ്പിക്കുന്നത്
ഒന്ന് ഗേറ്റ്‌വേകളെ ബന്ധിപ്പിക്കുന്നു, മറ്റൊന്ന് ഉപകരണങ്ങളെ ബന്ധിപ്പിക്കുന്നു. ട്രാഫിക് സെലക്ടറുകളെ റൂട്ടുകളുമായി താരതമ്യം ചെയ്യുക, അഡ്രസ്സിംഗ് ആസൂത്രണം ചെയ്യുക, തുടർന്ന് യഥാർത്ഥ ഹോസ്റ്റിൽ നിന്ന് ഫോർവേഡിംഗും പോളിസിയും പരിശോധിക്കുക.
രണ്ട് രൂപകൽപ്പനകളെയും VPN എന്ന് വിളിക്കുന്നു, അവ വ്യത്യസ്ത പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നു. സൈറ്റ്-ടു-സൈറ്റ് ടണൽ രണ്ട് ഗേറ്റ്‌വേകളെ ബന്ധിപ്പിക്കുന്നു, അതിനാൽ അവയുടെ പിന്നിലുള്ള ഓരോ ഹോസ്റ്റിനും ഒന്നും ഇൻസ്റ്റാൾ ചെയ്യാതെ തന്നെ മറുവശത്തെ അനുവദനീയമായ വിലാസങ്ങളിൽ എത്താനാകും. റിമോട്ട് ആക്സസ് ടണൽ വ്യക്തിഗത ഉപകരണങ്ങളെ ഒരു നെറ്റ്‌വർക്കിലേക്ക് ബന്ധിപ്പിക്കുന്നു, ഒരു സമയത്ത് ഒരു ക്ലയന്റ്. ഈ താരതമ്യം പ്രധാനമാണ്, കാരണം മിക്ക വിന്യാസ പിഴവുകളും ഒന്ന് കോൺഫിഗർ ചെയ്ത് മറ്റൊന്നിന്റെ സ്വഭാവം പ്രതീക്ഷിക്കുന്നതിൽ നിന്നാണ് ഉണ്ടാകുന്നത്, കൂടാതെ ലക്ഷണം സാധാരണയായി ടണൽ യഥാർത്ഥത്തിൽ എത്തിയ ഒരു സേവനത്തിലെ സമയപരിധി കവിയൽ ആണ്.
രണ്ട് രൂപകൽപ്പനകൾ, രണ്ട് അതിരുകൾ
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
ഒരു രൂപകൽപ്പനയും LAN ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്ൻ വിപുലീകരിക്കുന്നില്ല. അപ്പുറത്തുള്ള ഉപകരണങ്ങൾ പ്രാദേശിക കണ്ടെത്തൽ പട്ടികയിൽ പ്രത്യക്ഷപ്പെടുന്നില്ല, അത് പ്രതീക്ഷിക്കുന്നത് ഉപേക്ഷിക്കേണ്ട ആദ്യ അനുമാനമാണ്. നിങ്ങൾ ബോധപൂർവ്വം പ്രസിദ്ധീകരിക്കുന്ന സ്വകാര്യ DNS നാമങ്ങൾ ഏതൊരു കണ്ടെത്തൽ പ്രോട്ടോക്കോളിനെക്കാളും പ്രവചനക്ഷമമാണ്, വിതരണക്കാരൻ മാറിയാലും അവ നിലനിൽക്കും.
ഒരു സൈറ്റിൽ 10.10.0.0/24 ഉം മറ്റേതിൽ 10.20.0.0/24 ഉം എടുക്കുക. ഗേറ്റ്‌വേ A-ക്ക് 10.20.0.0/24 പ്രിഫിക്സ് ടണലിലേക്ക് അയക്കുന്ന ഒരു റൂട്ടോ ട്രാഫിക് സെലക്ടറോ ആവശ്യമാണ്, ഗേറ്റ്‌വേ B-ക്ക് അതിന്റെ കണ്ണാടി പ്രതിബിംബം ആവശ്യമാണ്. തുടർന്ന് ഇരുവശത്തുമുള്ള ഹോസ്റ്റുകൾ സാധാരണ IP കണക്റ്റിവിറ്റി ഉപയോഗിക്കുന്നു, ഒരു ടണൽ ഉണ്ടെന്ന് ഒരിക്കലും അറിയുന്നില്ല. ആ അദൃശ്യതയാണ് സവിശേഷത, പരാജയങ്ങൾ ടണൽ പിഴവുകളല്ലാതെ സാധാരണ നെറ്റ്‌വർക്ക് പിഴവുകൾ പോലെ തോന്നുന്നതിന്റെ കാരണവും അതാണ്.
പോളിസി അധിഷ്ഠിതവും റൂട്ട് അധിഷ്ഠിതവും ഒരേ ടണലല്ല
പോളിസി അധിഷ്ഠിത IPsec വിന്യാസത്തിൽ, ചർച്ച ചെയ്ത ട്രാഫിക് സെലക്ടറുകൾ ഏത് ഉറവിട-ലക്ഷ്യ ജോഡികളാണ് സംരക്ഷിക്കപ്പെടുന്നതെന്ന് കൃത്യമായി നിർവചിക്കുന്നു. ഒരു ഗേറ്റ്‌വേയുടെ പിന്നിൽ പുതിയ സബ്നെറ്റ് പ്രത്യക്ഷപ്പെടുകയും അത് ഒരു സെലക്ടറും ഉൾക്കൊള്ളാതിരിക്കുകയും ചെയ്താൽ, ടണൽ പ്രവർത്തിക്കുന്നത് തുടരും, പുതിയ സബ്നെറ്റ് വെറുതെ കൊണ്ടുപോകപ്പെടുന്നില്ല. റൂട്ട് അധിഷ്ഠിത രൂപകൽപ്പനയിൽ ഇന്റർഫേസ് ട്രാഫിക് സ്വീകരിക്കുന്നു, റൂട്ടിംഗ് പട്ടിക തീരുമാനിക്കുന്നു, ഇത് പ്രിഫിക്സ് ചേർക്കുന്നതിനെ ടണൽ വീണ്ടും ചർച്ച ചെയ്യുന്നതല്ലാതെ റൂട്ട് മാറ്റമാക്കുന്നു.
StrongSwan രണ്ട് കാഴ്ചകളും നേരിട്ട് കാണിക്കുന്നു, അവ ഒരുമിച്ച് വായിക്കുന്നതാണ് നിങ്ങൾ യഥാർത്ഥത്തിൽ ഏത് മാതൃക വിന്യസിച്ചുവെന്ന് അറിയാനുള്ള വഴി.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'നിങ്ങൾക്ക് ആവശ്യമായ പ്രിഫിക്സ് ഒഴിവാക്കിയ സെലക്ടർ പട്ടിക ഒരു പാക്കറ്റ് ക്യാപ്ചറും ഇല്ലാതെ പരാജയം വിശദീകരിക്കുന്നു, തെറ്റായ ഇന്റർഫേസിലേക്ക് ചൂണ്ടുന്ന റൂട്ട് മടക്കവഴിയിലെ കണ്ണാടി പരാജയം വിശദീകരിക്കുന്നു. എന്തെങ്കിലും വീണ്ടും ചർച്ച ചെയ്യുന്നതിന് മുൻപ് രണ്ടും വായിക്കുക, കാരണം കീ പുതുക്കൽ നിങ്ങൾ ഒരിക്കലും കോൺഫിഗർ ചെയ്യാത്ത ഒരു സെലക്ടർ ചേർക്കില്ല.
ടണലിന് മുൻപ് അഡ്രസ്സിംഗ് ആസൂത്രണം ചെയ്യുക
ഓവർലാപ്പിംഗ് ശ്രേണികൾ കോൺഫിഗറേഷൻ കൊണ്ട് പരിഹരിക്കാനാകാത്ത രൂപകൽപ്പന പിഴവാണ്. രണ്ട് സൈറ്റുകളും 192.168.1.0/24 ഉപയോഗിക്കുന്നുവെങ്കിൽ, 192.168.1.50 ആവശ്യമുള്ള ഹോസ്റ്റിന് രണ്ട് സ്ഥാനാർത്ഥികളുണ്ട്, തിരഞ്ഞെടുക്കാൻ ഒരു വഴിയുമില്ല. ടണൽ പ്രാമാണീകരിക്കും, സുരക്ഷാ അസോസിയേഷനുകൾ സ്ഥാപിക്കും, എന്നിട്ടും റൂട്ടിംഗ് തീരുമാനം തെറ്റായതോ അവ്യക്തമായതോ ആയിരിക്കും.
മൂന്ന് സത്യസന്ധമായ ഓപ്ഷനുകളിൽ ഒന്ന് തിരഞ്ഞെടുക്കുക: ഒരു സൈറ്റ് പുനർനമ്പർ ചെയ്യുക, ഗേറ്റ്‌വേയിൽ ഓവർലാപ്പിംഗ് ശ്രേണി വിവർത്തനം ചെയ്ത് ഓരോ വശവും വ്യത്യസ്ത പ്രിഫിക്സ് കാണാൻ അനുവദിക്കുക, അല്ലെങ്കിൽ ആ ഹോസ്റ്റുകൾക്ക് നേരിട്ടുള്ള റൂട്ടിംഗ് ഉപേക്ഷിച്ച് സേവനം മറ്റൊരു വഴിക്ക് പ്രസിദ്ധീകരിക്കുക. ഓരോന്നിനും ചെലവുണ്ട്, രണ്ട് വർഷത്തെ കാഴ്ചപ്പാടിൽ ആദ്യത്തേതാണ് സാധാരണയായി ഏറ്റവും വിലകുറഞ്ഞത്. ടണൽ ഉണ്ടാകുന്നതിന് മുൻപ് തീരുമാനിക്കുക, കാരണം പിന്നീട് ആ മാറ്റം പഴയ വിലാസമുള്ള ഓരോ ഉപകരണത്തെയും സ്പർശിക്കും.
MTU പ്രശ്നവും നേരത്തെ പരിഹരിക്കുക. ടണൽ ഉപയോഗപ്രദമായ പേലോഡ് കുറയ്ക്കുന്നു, ഫ്രാഗ്മെന്റേഷനെ ആശ്രയിക്കുന്ന രൂപകൽപ്പന ഗേറ്റ്‌വേകളിൽ MSS സ്ഥിരപ്പെടുത്തുന്ന രൂപകൽപ്പനയിൽ നിന്ന് വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു.
ഫോർവേഡിംഗും പോളിസിയും ടണലിന് പുറത്താണ്
ഗേറ്റ്‌വേ ടണൽ ഇന്റർഫേസും LAN ഇന്റർഫേസും തമ്മിൽ പാക്കറ്റുകൾ ഫോർവേഡ് ചെയ്യാൻ തയ്യാറായിരിക്കണം, രണ്ട് ദിശകൾക്കും സേവനം അനുവദിക്കുന്ന പോളിസി ആവശ്യമാണ്. Linux-ൽ ഇവ രണ്ട് വ്യത്യസ്ത ക്രമീകരണങ്ങളാണ്, കൂടാതെ ഫോർവേഡ് ചെയ്ത ഫ്ലോ ഒട്ടും അനുവദനീയമാണോ എന്ന് തീരുമാനിക്കുന്ന ഫയർവാൾ നിയമങ്ങളും.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTസ്വീകരിക്കുന്ന ഹോസ്റ്റ് മൂന്നാം പാളി ചേർക്കുന്നു: അതിന്റെ സ്വന്തം ഫയർവാൾ ഇപ്പോഴും ദൂരെയുള്ള സബ്നെറ്റിൽ നിന്നുള്ള ഒരു ക്ലയന്റിനെ സ്വീകരിക്കണം. തന്റെ പ്രാദേശിക /24 മാത്രം അനുവദിക്കുന്ന ഒരു ഫയൽ സർവർ, ടണൽ എത്ര ആരോഗ്യകരമായി തോന്നിയാലും 10.20.0.7-ൽ നിന്നുള്ള ഫോർവേഡ് ചെയ്ത ട്രാഫിക് നിരസിക്കും, ആ നിരസനെ റൂട്ടിംഗ് പരാജയമായി വായിക്കാൻ എളുപ്പമാണ്.
ഗേറ്റ്‌വേയിൽ നിന്നല്ല, ഹോസ്റ്റിൽ നിന്ന് പരിശോധിക്കുക
ഗേറ്റ്‌വേ തന്നെ അയക്കുന്ന ping ഫോർവേഡ് ചെയ്യുന്ന ഉപയോക്തൃ ട്രാഫിക്കിൽ നിന്ന് വ്യത്യസ്തമായ ഉറവിട വിലാസവും പോളിസിയും പിന്തുടരാം. അത് ഇതിനെ ദുർബലമായ പരിശോധനയാക്കുന്നു, ചിലപ്പോൾ തെറ്റായ വഴിക്ക് നയിക്കുകയും ചെയ്യുന്നു: ആപ്ലിക്കേഷൻ പരാജയപ്പെടുമ്പോൾ അത് വിജയിക്കുന്നു, അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുമ്പോൾ അത് പരാജയപ്പെടുന്നു.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullയഥാർത്ഥ ഹോസ്റ്റ്, യഥാർത്ഥ ഉറവിട വിലാസം, ആപ്ലിക്കേഷൻ ഉപയോഗിക്കുന്ന യഥാർത്ഥ പ്രോട്ടോക്കോൾ എന്നിവ ഉപയോഗിക്കുക. തുടർന്ന് മടക്കവഴി വെവ്വേറെ വായിക്കുക, കാരണം മടക്ക റൂട്ട് ഇല്ലാതെ പ്രവർത്തിക്കുന്ന മുൻപോട്ടുള്ള ദിശ, തടഞ്ഞ സേവനത്തിന് സമാനമായി കാണുന്ന സമയപരിധി കവിയൽ സൃഷ്ടിക്കുന്നു.
നിങ്ങൾ ഉത്തരം നൽകുന്ന ചോദ്യത്തിനനുസരിച്ച് രൂപകൽപ്പന തിരഞ്ഞെടുക്കുക: നിങ്ങൾ നെറ്റ്‌വർക്കുകൾ ബന്ധിപ്പിക്കുകയാണോ ഉപകരണങ്ങൾ സ്വീകരിക്കുകയാണോ? ബാക്കിയെല്ലാം, ഏത് വിതരണക്കാരനെ കോൺഫിഗർ ചെയ്യുന്നു എന്നതും ഉൾപ്പെടെ, ആ ഉത്തരത്തിൽ നിന്നാണ് വരുന്നത്.