ഒരു LAN സബ്നെറ്റ് OpenVPN വഴി റൂട്ട് ചെയ്ത് ഡിഫോൾട്ട് നിലനിർത്തുക
ഒരു സബ്നെറ്റ് ടണലിലൂടെ പോകുമ്പോൾ LAN ഡിഫോൾട്ട് നിലനിർത്തുക. പോളിസി പട്ടികയെ പ്രധാന പട്ടികയുടെ മാറ്റങ്ങളുമായി താരതമ്യം ചെയ്ത്, പിന്നീട് NAT അല്ലെങ്കിൽ സർവർ വശത്തെ റൂട്ട് തിരഞ്ഞെടുക്കുക.
LAN-നായി റൂട്ട് ചെയ്യുകയും അതേസമയം VPN-ലേക്ക് ഡയൽ ചെയ്യുകയും ചെയ്യുന്ന ഉപകരണങ്ങൾ സ്വയം അതേ വാദത്തിൽ എത്തുന്നു: ടണലിന് ഡിഫോൾട്ട് റൂട്ട് സ്വന്തമാക്കണം, LAN-ന് അത് തിരികെ വേണം. OpenVPN കണക്ട് ചെയ്യുമ്പോൾ, ടണലിലൂടെയുള്ള ഒരു ഡിഫോൾട്ടോ രണ്ട് പകുതി-ഡിഫോൾട്ടുകളോ ഇൻസ്റ്റാൾ ചെയ്തേക്കാം, അത് ലാപ്ടോപ്പിന് ശരിയും, അയൽക്കാർ അതിന്റെ LAN വിലാസത്തിൽ നിന്ന് മറുപടി പ്രതീക്ഷിക്കുന്ന ഗേറ്റ്വേയ്ക്ക് തെറ്റുമാണ്. ഉത്തരം VPN ഒഴിവാക്കുക എന്നതല്ല. ഉത്തരം രണ്ട് തീരുമാനങ്ങൾക്ക് വ്യത്യസ്ത പട്ടികകൾ നൽകുക എന്നതാണ്.
ഒരു ഡിഫോൾട്ട് റൂട്ട്, രണ്ട് ഉടമകൾ
ഫോർവേഡ് ചെയ്യുന്ന ട്രാഫിക്കും പ്രാദേശികമായി ഉണ്ടാകുന്ന ട്രാഫിക്കും ഒരേ വഴി പോകേണ്ടതില്ല. LAN ക്ലയന്റുകൾക്ക് നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന ലക്ഷ്യസ്ഥാനങ്ങൾക്ക് മാത്രം ടണൽ വേണം, അതേസമയം ഹോസ്റ്റിന്റെ സ്വന്തം മാനേജ്മെന്റ് സെഷനുകൾക്കും ആ ക്ലയന്റുകൾക്കുള്ള മറുപടികൾക്കും LAN ഡിഫോൾട്ട് വേണം. രണ്ടും പ്രധാന പട്ടികയിൽ കലർത്തിയാൽ രണ്ട് വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഒരേ ഉത്തരം അടിച്ചേൽപ്പിക്കുന്നു.
OpenVPN-ൽ ഇതിനായി തന്നെ ഒരു സ്വിച്ച് ഉണ്ട്. route-noexec ക്ലയന്റ് പ്രധാന പട്ടിക തൊടാതെ തടയുന്നു, ഒപ്പം അത് ഉപയോഗിക്കുമായിരുന്ന മൂല്യങ്ങൾ route-up സ്ക്രിപ്റ്റിലേക്ക് route_vpn_gateway, dev എന്നിവയായി കയറ്റുമതി ചെയ്യുന്നു. പിന്നീട് ഏത് പട്ടിക ഏത് റൂട്ട് സ്വീകരിക്കണം എന്ന് നിങ്ങൾ തീരുമാനിക്കുന്നു, പിന്നീട് വായിക്കാവുന്ന കോഡിൽ.
പോളിസി പട്ടിക അല്ലെങ്കിൽ പ്രധാന പട്ടിക മാറ്റിയെഴുതൽ
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
വേറിട്ട പട്ടിക ഒരു സബ്നെറ്റിനപ്പുറം സ്കെയിൽ ചെയ്യുന്ന ഒരേയൊരു ഓപ്ഷനാണ്. ഒരിക്കൽ അതിന് ഒരു പേര് നൽകുക, പിന്നീട് പേരുകൊണ്ട് അതിനെ സൂചിപ്പിക്കുക, ആർക്കും ഒരു സംഖ്യ ഓർക്കേണ്ടിവരരുത്:
echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpnഇവിടത്തെ വിലാസങ്ങൾ പ്ലേസ്ഹോൾഡറുകളാണ്. എന്തെങ്കിലും പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ സ്വന്തം വിന്യാസത്തിൽ നിന്ന് LAN പ്രിഫിക്സ്, ടണൽ ഗേറ്റ്വേ, ഉപകരണത്തിന്റെ പേര് എന്നിവ മാറ്റുക.
നിയമം ഹോസ്റ്റുമായും പൊരുത്തപ്പെടണം
LAN പ്രിഫിക്സുമായി മാത്രം പൊരുത്തപ്പെടുന്ന നിയമം ഫോർവേഡ് ചെയ്ത പാക്കറ്റുകളെ ഉൾക്കൊള്ളുന്നു. ഗേറ്റ്വേ സ്വയം സൃഷ്ടിക്കുന്ന ട്രാഫിക്കിനെയോ, ഉറവിടമായി ഗേറ്റ്വേയുടെ LAN വിലാസം വഹിക്കുന്ന, LAN ക്ലയന്റുകൾക്ക് തിരികെ അയയ്ക്കുന്ന മറുപടികളെയോ അത് ഉൾക്കൊള്ളുന്നില്ല. ആ ലുക്കപ്പുകൾ main-ലേക്ക് വീഴുന്നു, ഇപ്പോഴും ടണലിലൂടെ പുറത്തുപോകാം.
ഗേറ്റ്വേയുടെ സ്വന്തം LAN വിലാസത്തിന് രണ്ടാമതൊരു നിയമം ചേർക്കുക, അല്ലെങ്കിൽ ആദ്യ നിയമം രണ്ടും ഉൾപ്പെടുന്ന ഒരു കൂട്ടമായി വിപുലീകരിക്കുക. ക്രമം പ്രധാനമാണ്: കൂടുതൽ നിർദ്ദിഷ്ടമായ നിയമം ആദ്യം വയ്ക്കുക, ഉറവിടം വ്യക്തമായി പേരിടുന്ന ഒരു ലുക്കപ്പ് ഉപയോഗിച്ച് ഫലം പരിശോധിക്കുക.
ip route get 203.0.113.9 from 192.168.50.1പ്രാദേശികമായി തുടരേണ്ട ലക്ഷ്യസ്ഥാനത്തിന് അത് ടണൽ ഉപകരണം റിപ്പോർട്ട് ചെയ്യുന്നെങ്കിൽ, പട്ടികയിൽ എന്തുണ്ടായാലും നിയമക്കൂട്ടം തെറ്റാണ്.
NAT അല്ലെങ്കിൽ അപ്പുറത്തെ വശത്ത് ഒരു റൂട്ട്
VPN സർവറിന് ടണൽ സബ്നെറ്റ് അറിയാം, മറ്റൊന്നുമില്ല. LAN ഉറവിട വിലാസവുമായി വരുന്ന പാക്കറ്റുകൾക്ക് ആരെങ്കിലും ഒരു തിരിച്ചുവഴി നൽകിയില്ലെങ്കിൽ തിരിച്ചുവഴിയില്ല, അത് നൽകാൻ കൃത്യമായി രണ്ട് വഴികളുണ്ട്. സർവറിൽ LAN പ്രിഫിക്സിന് ഒരു റൂട്ട് ചേർക്കുന്നത് യഥാർത്ഥ ഉറവിടം അറ്റം മുതൽ അറ്റം വരെ കാണാവുന്നതായി നിലനിർത്തുന്നു, ഓഡിറ്റ് ചെയ്ത രൂപകൽപ്പന സാധാരണ ഇതാണ് ആഗ്രഹിക്കുന്നത്. ഗേറ്റ്വേയിൽ മാസ്കറേഡ് ചെയ്യുന്നത് ഉറവിടം ടണൽ വിലാസത്തിലേക്ക് മാറ്റിയെഴുതുന്നു, സർവറിന്റെ സഹകരണം ആവശ്യമില്ല.
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEസർവർ നിയന്ത്രിക്കാത്തപ്പോഴും അവിടെ റൂട്ടുകൾ ചേർക്കാൻ കഴിയാത്തപ്പോഴും NAT തിരഞ്ഞെടുക്കുക. ലോഗുകൾ, ആക്സസ് നിയന്ത്രണം, തിരിച്ചുവരവ് പാതയുടെ സമമിതി എന്നിവ പ്രധാനമാകുമ്പോൾ സർവർ വശത്തെ റൂട്ട് തിരഞ്ഞെടുക്കുക, കാരണം മാസ്കറേഡ് അപ്പുറത്തെ വശം രേഖപ്പെടുത്തുന്ന എല്ലാറ്റിൽ നിന്നും യഥാർത്ഥ വിലാസം മായ്ക്കുന്നു.
ഏതായാലും ഫോർവേഡിംഗ് സജീവമായിരിക്കണം, കർശനമായ റിവേഴ്സ്-പാത്ത് ഫിൽട്ടറിംഗ്, main ആ ഉറവിടത്തിന് ടണൽ തിരഞ്ഞെടുക്കുമായിരുന്നില്ലെങ്കിൽ മറുപടി വീഴ്ത്തിയേക്കാം. ടണലിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ഫലപ്രദമായ മൂല്യം പരിശോധിക്കുക.
വീണ്ടും കണക്ട് ചെയ്താലും വിഭജനം നിലനിൽക്കട്ടെ
കൈകൊണ്ട് ചേർത്ത നിയമങ്ങളും റൂട്ടുകളും ഇന്റർഫേസ് വീണ്ടും സൃഷ്ടിക്കുമ്പോൾ അപ്രത്യക്ഷമാകുന്നു, പഴയ പട്ടിക എൻട്രി അതിനെ ന്യായീകരിച്ച സെഷനെക്കാൾ കൂടുതൽ കാലം നിലനിൽക്കാം. പട്ടികയുടെ നിയമം, ടണലിന്റെ റൂട്ട്, മാസ്കറേഡ് എൻട്രി എന്നിവ ക്ലയന്റിന്റെ route-up സ്ക്രിപ്റ്റിനുള്ളിൽ വയ്ക്കുക, സ്ക്രിപ്റ്റിന്റെ മുകളിൽ പട്ടിക ഒഴിവാക്കുക, പഴയ ഗേറ്റ്വേ പുതിയ സെഷനിലേക്ക് നിലനിൽക്കാതിരിക്കാൻ.
രണ്ട് അറ്റങ്ങളിൽ നിന്നും പരിശോധിക്കുക: ഗേറ്റ്വേയിൽ LAN ഉറവിടത്തോടെയുള്ള ഒരു ലുക്കപ്പ്, ടണലിലൂടെ പോകേണ്ട ലക്ഷ്യസ്ഥാനത്തേക്ക് LAN ക്ലയന്റിൽ നിന്നുള്ള യഥാർത്ഥ അഭ്യർത്ഥന. നിലവിലുണ്ടെങ്കിലും ഒരിക്കലും തിരഞ്ഞെടുക്കപ്പെടാത്ത റൂട്ട്, കൗണ്ടറുകൾ വായിക്കുന്നതുവരെ റൂട്ട് ഇല്ലാത്തതുപോലെ തന്നെ പെരുമാറുന്നു.