VPN വഴി ഒരു സ്വകാര്യ സബ്നെറ്റ് മാത്രം എങ്ങനെ അയയ്ക്കാം

ടണലിലൂടെ ഒരു സ്വകാര്യ സബ്നെറ്റ് മാത്രം കടത്തി ബാക്കിയെല്ലാം സാധാരണ പാതയിലൂടെ അയയ്ക്കുന്നത് ചെറിയ ആവശ്യമാണ്, പക്ഷേ തെറ്റാക്കാൻ ധാരാളം വഴികളുണ്ട്. ഫലം നിർണ്ണയിക്കുന്നത് split tunneling എന്ന ചെക്ക്ബോക്സല്ല, മറിച്ച് തീരുമാനം എവിടെ നടപ്പാക്കുന്നു എന്നതാണ്: ക്ലൈന്റിന്റെ സ്വന്തം റൂട്ട് പട്ടിക, സർവർ തള്ളുന്ന റൂട്ട്, അല്ലെങ്കിൽ ഇരു അറ്റങ്ങളും കൂടിയാലോചിക്കുന്ന നയം. തെറ്റായ പാളി തിരഞ്ഞെടുത്താൽ ഒരിക്കലും ആഗ്രഹിക്കാത്ത പൂർണ്ണ ടണലോ, എതിർവശം സ്വീകരിക്കാൻ വിസമ്മതിക്കുന്ന ടണലിലേക്കുള്ള റൂട്ടോ ലഭിക്കും. ഏതെങ്കിലും കോൺഫിഗറേഷൻ തുറക്കുന്നതിന് മുൻപ് ഞാൻ മൂന്ന് വ്യവസ്ഥയുള്ള പരിശോധന ഉപയോഗിക്കുന്നു, പിന്നീട് താഴെയുള്ള ഒരു സംവിധാനം തിരഞ്ഞെടുക്കുന്നു.

രൂപകൽപ്പന തീരുമാനിക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ

ആദ്യം, നെറ്റ്വർക്ക് ഉടമയിൽ നിന്ന് കൃത്യമായ പ്രിഫിക്സും മാസ്കും വേണം. 10.x നെറ്റ്വർക്ക് പ്രിഫിക്സല്ല; 10.20.0.0/16 ആണ് പ്രിഫിക്സ്. നിങ്ങളുടെ വീട്ടിലെ LAN, Docker ബ്രിഡ്ജ്, അല്ലെങ്കിൽ നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന മറ്റൊരു VPN എന്നിവയുമായി അത് ഓവർലാപ്പ് ചെയ്യുന്നില്ലെന്ന് ഉറപ്പാക്കുക, കാരണം ഓവർലാപ്പ് റൂട്ടിനെ അവ്യക്തമാക്കുകയും കേർണൽ നിങ്ങൾ ഉദ്ദേശിക്കാത്ത എൻട്രി തിരഞ്ഞെടുക്കുകയും ചെയ്യും.

രണ്ടാമത്, തിരികെ വരുന്ന ട്രാഫിക്കിന് ആരാണ് ഉത്തരം നൽകുന്നത്. ഒരു പാക്കറ്റ് ടണലിലേക്ക് റൂട്ട് ചെയ്യുന്നത് അതിനെ VPN സർവറിലേക്ക് മാത്രം എത്തിക്കുന്നു. സബ്നെറ്റ് നിങ്ങളുടെ ക്ലൈന്റ് പൂളിലേക്ക് തിരികെ റൂട്ട് ഇല്ലാത്ത മറ്റൊരു റൂട്ടറിന് പിന്നിലാണെങ്കിൽ, സർവർ ട്രാഫിക് മാസ്ക്വറേഡ് ചെയ്യണം, അല്ലെങ്കിൽ ആ റൂട്ടർ നിങ്ങളുടെ പൂൾ പഠിക്കണം. ക്ലൈന്റ് ഭാഗത്തുള്ള ഒരു റൂട്ടും കാണാത്ത തിരിച്ചുവരവ് പാത ശരിയാക്കുന്നില്ല.

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

WireGuard: AllowedIPs ആണ് റൂട്ട് പട്ടിക

ക്ലൈന്റിൽ, AllowedIPs ടണലിൽ പ്രവേശിക്കാൻ അനുവദിക്കുന്ന ലക്ഷ്യങ്ങൾ ലിസ്റ്റ് ചെയ്യുന്നു, wg-quick ഓരോ എൻട്രിയും സാധാരണ റൂട്ടാക്കി മാറ്റുന്നു. അതിനാൽ ഈ ജോലിയുടെ ക്ലൈന്റ് പകുതി ഒരു വരിയാണ്.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

ഇനി അതേ ക്ലൈന്റിനുള്ള സർവറിന്റെ എൻട്രിയുമായി താരതമ്യം ചെയ്യുക. അത് സർവർ ക്ലൈന്റിന് എന്ത് അയയ്ക്കുമെന്ന് വിവരിക്കുന്നു, അത് സാധാരണയായി ക്ലൈന്റിന്റെ ടണൽ വിലാസമാണ്, സ്വകാര്യ സബ്നെറ്റല്ല.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

ഈ രണ്ടെണ്ണം പരസ്പരം മാറ്റുന്നതാണ് ഞാൻ ഏറ്റവും കൂടുതൽ കാണുന്ന തെറ്റ്. സർവറിന്റെ peer വിഭാഗത്തിന് കീഴിൽ 10.20.0.0/16 ഇടുന്നത് മുഴുവൻ സബ്നെറ്റും ആ ക്ലൈന്റിന് പിന്നിലാണെന്ന് പ്രഖ്യാപിക്കുന്നു, അത് സൈറ്റിൽ നിന്ന് സൈറ്റിലേക്കുള്ള അവകാശവാദമാണ്, അനുമതിയല്ല. ഏതെങ്കിലും peer ന്റെ AllowedIPs-മായി പൊരുത്തപ്പെടാത്ത പാക്കറ്റുകൾ നിശ്ശബ്ദമായി ഉപേക്ഷിക്കപ്പെടുന്നു, അതിനാൽ തെറ്റായ എൻട്രി കൃത്യമായി ഫയർവാൾ പ്രശ്നം പോലെ തോന്നും.

റൂട്ടുകൾ നിങ്ങൾ തന്നെ കൈകാര്യം ചെയ്യുന്നുവെങ്കിൽ, [Interface]-ന് കീഴിൽ Table = off സജ്ജീകരിച്ച് ആവശ്യമുള്ള റൂട്ട് ചേർക്കുക. അപ്പോൾ ഒന്നും സ്വയമേവ ചേർക്കപ്പെടുന്നില്ല, അതിനാൽ റൂട്ട് ഇന്റർഫേസ് ഉയർത്തുന്നതിന്റെ ഉള്ളിൽ ആയിരിക്കണം.

OpenVPN: റൂട്ട് തള്ളുക, എന്നിട്ട് അത് എത്തുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക

സാധാരണ സർവറിൽ മാറ്റം സർവർ കോൺഫിഗിൽ ക്ലൈന്റ് പൂളിന് അരികിൽ ഒരു നിർദ്ദേശമാണ്.

push "route 10.20.0.0 255.255.0.0"

ക്ലൈന്റ് കണക്ട് ചെയ്യുമ്പോൾ അത് ചേർക്കുന്നു. ഒരേ പ്രൊഫൈൽ redirect-gateway കൂടി തള്ളുമ്പോൾ, അല്ലെങ്കിൽ ആരെങ്കിലും മുൻപേ route-nopull ചേർത്തിട്ടുണ്ടെങ്കിൽ പരാജയരീതി പ്രത്യക്ഷപ്പെടുന്നു: ആദ്യത്തേത് സെഷനെ പൂർണ്ണ ടണലാക്കുന്നു, രണ്ടാമത്തേത് നിങ്ങളുടേതുൾപ്പടെ തള്ളിയ എല്ലാ റൂട്ടുകളും നീക്കിക്കളയുന്നു.

പൂർണ്ണ ടണൽ സർവറിനെതിരെ ഇടുങ്ങിയ പെരുമാറ്റം വേണ്ട ക്ലൈന്റ്, തനിക്ക് വേണ്ടാത്ത ഭാഗങ്ങൾ മാത്രം അവഗണിക്കണം. OpenVPN 2.4-ലും അതിനുശേഷമുള്ളവയിലും, pull-filter കൃത്യമായി അതിനുവേണ്ടിയാണ്.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

വിലാസ കുടുംബങ്ങൾ വേർതിരിച്ച് സൂക്ഷിക്കുക: തള്ളിയ IPv4 റൂട്ട് IPv6-ലേക്ക് പരിഹരിക്കുന്ന ആന്തരിക സേവനത്തിന് ഒന്നും ചെയ്യുന്നില്ല, ആ സേവനം മാത്രം ടണലിലൂടെ പരാജയപ്പെടുന്നു, ബാക്കിയെല്ലാം കുഴപ്പമില്ലാത്തതുപോലെ തോന്നും.

സ്വകാര്യ സബ്നെറ്റ് VPN സർവറിൽ അല്ലാതെ മറ്റൊരു ക്ലൈന്റിന് പിന്നിലാണെങ്കിൽ, സർവറിനെ അറിയിക്കണം. client-config-dir വഴി ഓരോ ക്ലൈന്റിനും iroute 10.20.0.0 255.255.0.0 അടങ്ങിയ ഫയൽ ചേർക്കുക, കൂടെ യോജിക്കുന്ന route ഉം, മറ്റ് ക്ലൈന്റുകൾ പാത പഠിക്കാൻ. iroute ഇല്ലാതെ ആ പ്രിഫിക്സ് കൃത്യമായി ആ ടണലിലൂടെ അയയ്ക്കാൻ സർവറിന് കാരണമില്ല.

IPsec: ട്രാഫിക് സെലക്ടറുകൾ യോജിക്കണം

IPsec-ൽ തള്ളാൻ ഒരു റൂട്ടുമില്ല. ഇരു അറ്റങ്ങളും ഏത് വിലാസങ്ങൾ ടണലിനുള്ളിലാണെന്ന് കൂടിയാലോചിക്കുന്നു, സമ്മതിച്ച സെലക്ടറുകൾക്ക് പുറത്തുള്ള ട്രാഫിക് എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുന്നുമില്ല അതിലൂടെ അയയ്ക്കപ്പെടുന്നുമില്ല. strongSwan ക്ലൈന്റിൽ സെലക്ടറുകൾ വ്യക്തമാണ്.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

ഗേറ്റ്വേ ഇരുവശത്തും 0.0.0.0/0 ഉപയോഗിച്ച് കോൺഫിഗർ ചെയ്തിട്ടുണ്ടെങ്കിൽ, IKEv2 സങ്കോചം സാധാരണയായി ചൈൽഡ് SA യെ രണ്ട് നിർദ്ദേശങ്ങളുടെ ഛേദത്തിലേക്ക് ചുരുക്കുന്നു, അതാണ് ആവശ്യമായ ഫലം. ചില ഗേറ്റ്വേകൾ പകരം തങ്ങളുടെ കോൺഫിഗർ ചെയ്ത സെലക്ടറുകളുമായി യോജിക്കാത്ത നിർദ്ദേശം നിരസിക്കുന്നു, അപ്പോൾ ലോഗ് റൂട്ടിംഗ് പരാതിക്ക് പകരം പരാജയപ്പെട്ട ചൈൽഡ് SA കാണിക്കുന്നു. അങ്ങനെ സംഭവിക്കുമ്പോൾ മാറ്റം ഗേറ്റ്വേയുടേതാണ്, കാരണം എതിർവശം സ്വീകരിക്കാത്ത സെലക്ടറിന് ക്ലൈന്റ് റൂട്ടിന് ടണൽ സൃഷ്ടിക്കാനാവില്ല.

Windows-ൽ ഉൾച്ചേർന്ന ക്ലൈന്റ് അതേ തീരുമാനം രണ്ട് ക്രമീകരണങ്ങൾക്ക് പിന്നിൽ ഒളിപ്പിക്കുന്നു. ടണൽ വിഭജനം ഓണായിരിക്കണം, പ്രിഫിക്സ് പ്രൊഫൈലിൽ രജിസ്റ്റർ ചെയ്യണം.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

പ്രിഫിക്സ് രജിസ്റ്റർ ചെയ്യുന്നതാണ് വീണ്ടും കണക്ട് ചെയ്താലും അത് നിലനിർത്തുന്നത്, കൈകൊണ്ട് ചേർത്ത റൂട്ട് അത് ചെയ്യുന്നില്ല.

എൻഡ്പോയിന്റും DNS-ഉം തീരുമാനത്തിന് പുറത്ത് സൂക്ഷിക്കുക

VPN എൻഡ്പോയിന്റ് ടണൽ ഇല്ലാതെ എത്താവുന്നതായി തുടരണം, അല്ലെങ്കിൽ ടണൽ സ്വയം നിലംപൊത്തും. 10.20.0.0/16 മാത്രം റൂട്ട് ചെയ്യുമ്പോൾ അത് സ്വയമേവയാണ്, കാരണം എൻഡ്പോയിന്റ് പൊതു വിലാസമാണ്. പൂർണ്ണ ടണൽ പ്രൊഫൈലിൽ അങ്ങനെയല്ല, ടണൽ ഉയരുന്നതിന് മുൻപ് ക്ലൈന്റിന് എൻഡ്പോയിന്റിലേക്കുള്ള വ്യക്തമായ ഹോസ്റ്റ് റൂട്ട് വേണം.

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

പരിശോധിക്കുക, പിന്നീട് റീബൂട്ട് ചെയ്ത് വീണ്ടും പരിശോധിക്കുക

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

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

ആദ്യ വരി ഒരു ഇന്റർഫേസ് പേര് പറയുന്നു. നിങ്ങളുടെ ഭൗതിക ഇന്റർഫേസ് പേര് പറഞ്ഞാൽ, റൂട്ട് ഒരിക്കലും എത്തിയിട്ടില്ല. Windows-ൽ Find-NetRoute -RemoteIPAddress 10.20.5.7 അതേ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, അവസാന പരിശോധന ഇപ്പോഴും നിങ്ങളുടെ സാധാരണ വിലാസം കാണിക്കണം, VPN സർവറിന്റേതല്ല.

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

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