സൈറ്റ്-ടു-സൈറ്റ് VPN-ന്റെ മറുപടി ടണലിലൂടെ പോകുന്നില്ല
ടണൽ ഒഴിവാക്കുന്ന മറുപടി വിദൂര വശത്തെ റൂട്ടിംഗ് തീരുമാനമാണ്. ഹോസ്റ്റ് പട്ടികയും സെലക്ടറുകളും rp_filter-ഉം പരിശോധിച്ച ശേഷം റൂട്ടോ NAT-ഓ തിരഞ്ഞെടുക്കുക.
ഒരു രാവിലെ ചെലവഴിച്ചത്, വൃത്തിയായി ഉയർന്നുവന്ന് ട്രാഫിക് കൃത്യം ഒരു ദിശയിലേക്ക് മാത്രം നീക്കുന്ന ഒരു ടണലിനൊപ്പമാണ്: ശാഖയ്ക്ക് ആസ്ഥാനത്തെ ഫയൽ സെർവർ എത്തിച്ചേരാമായിരുന്നു, എന്നാൽ ആസ്ഥാനത്തുനിന്ന് ശാഖയിലേക്ക് തുറക്കുന്ന ഓരോ കണക്ഷനും ആദ്യ SYN-ൽ തന്നെ ചത്തു. SA-കൾ സജീവമായിരുന്നു, ടണൽ കൗണ്ടറുകൾ ഉയരുകയായിരുന്നു, ഹാൻഡ്ഷേക്ക് ഒരിക്കലും പ്രശ്നമായിരുന്നില്ല. ടണൽ പരിധിയിൽ എത്താത്ത എവിടേക്കോ ആണ് മറുപടി റൂട്ട് ചെയ്യപ്പെട്ടിരുന്നത്, ആ തിരഞ്ഞെടുപ്പ് വിദൂര വശത്തിന്റേതാണ്. സൈറ്റ്-ടു-സൈറ്റ് VPN ഹോസ്റ്റ് ഗേറ്റ്വേയ്ക്ക് കൈമാറുന്ന പാക്കറ്റുകൾ മാത്രമാണ് കൊണ്ടുപോകുന്നത്, ഓരോ ഹോസ്റ്റും ആ തിരഞ്ഞെടുപ്പ് വെവ്വേറെ, ഓരോ ദിശയിലും, സ്വന്തം റൂട്ടിംഗ് പട്ടികയിൽനിന്ന് ചെയ്യുന്നു.
ഇരു ദിശകളും വെവ്വേറെ റൂട്ട് ചെയ്യപ്പെടുന്നു
IP സംഭാഷണത്തിന്റെ ദിശ ഓർമ്മിക്കുന്നില്ല. പാക്കറ്റ് അയയ്ക്കുന്ന ഓരോ ഹോസ്റ്റും സ്വന്തം ഏറ്റവും നീളമുള്ള പ്രിഫിക്സ് തിരയൽ നടത്തുന്നു, ഒരു അടുത്ത ഹോപ്പ് തിരഞ്ഞെടുക്കുന്നു, തീരുമാനം മറക്കുന്നു. അഭ്യർത്ഥനയും മറുപടിയും ഒരേ കണക്ഷനിൽ യാദൃച്ഛികമായി ഉൾപ്പെട്ട ബന്ധമില്ലാത്ത രണ്ട് പാക്കറ്റുകളാണ്, ടണൽ അവയിൽ ഏതെങ്കിലും ഉപയോഗിക്കാവുന്നതോ ഉപയോഗിക്കാത്തതോ ആയ ഒരു ഹോപ്പാണ്. IKE കൈമാറ്റത്തിൽ ഒന്നും വിദൂര സെർവറിന് നിങ്ങളുടെ സബ്നെറ്റിലേക്ക് എത്താനുള്ള വഴി പഠിപ്പിക്കുന്നില്ല; ഏത് പ്രിഫിക്സുകൾ എൻക്രിപ്റ്റ് ചെയ്യാമെന്ന് മാത്രമാണ് ചർച്ച യോജിക്കുന്നത്.
ആ യോജിപ്പാണ് രണ്ടാം കവാടം. strongSwan-ൽ ട്രാഫിക് സെലക്ടറുകൾ leftsubnet ഉം rightsubnet ഉം ആണ്, ഉറവിടമോ ലക്ഷ്യമോ യോജിച്ച ജോടിക്ക് പുറത്തുവരുന്ന പാക്കറ്റ് റൂട്ടിംഗ് പട്ടിക എന്തു പറഞ്ഞാലും എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുന്നില്ല. ടണലിലേക്ക് റൂട്ട് ചെയ്യപ്പെടുന്നെങ്കിലും സെലക്ടറുകളിൽ ഇല്ലാത്ത പ്രിഫിക്സ് നിശ്ശബ്ദമായ ഒരു ദിശയിലുള്ള പരാജയമാണ്: റൂട്ട് ശരിയായി തോന്നുന്നു, പാക്കറ്റ് എങ്കിലും തുറന്ന് പുറത്തുപോകുന്നു അല്ലെങ്കിൽ വലിച്ചെറിയപ്പെടുന്നു, charon ലോഗ് മാത്രം പരാതിപ്പെടുന്നു.
വിദൂര ഹോസ്റ്റിന് നിങ്ങളുടെ ടണലിനെക്കുറിച്ച് ഒന്നും അറിയില്ല
വിദൂര LAN-നുള്ളിൽ മറുപടി നിങ്ങളുടെ ക്ലയന്റിന് അയച്ച ഒരു സാധാരണ പാക്കറ്റാണ്. ലക്ഷ്യ ഹോസ്റ്റിന് ഒരു IPsec തലക്കെട്ടും കാണാനില്ല, VPN ഗേറ്റ്വേയ്ക്ക് മുൻഗണന നൽകാൻ കാരണവുമില്ല; അത് നിങ്ങളുടെ പ്രിഫിക്സ് നോക്കുന്നു, സ്വന്തം ഡിഫോൾട്ട് റൂട്ടിനേക്കാൾ വ്യക്തമായ ഒന്നും കണ്ടെത്താതെ അത് പിന്തുടരുന്നു. ഡിഫോൾട്ട് ഒരു കോർ ഫയർവാളിലേക്ക് വിരൽ ചൂണ്ടിയാൽ, ഫയർവാളിന് ടണലിലേക്ക് തിരികെയുള്ള റൂട്ട് ഉണ്ടോ ഇല്ലയോ. ഇല്ലെങ്കിൽ നിങ്ങൾക്ക് നിശ്ശബ്ദമായ ഡ്രോപ്പ്, ICMP unreachable, അല്ലെങ്കിൽ ഇന്റർനെറ്റ് ഭാഗത്തേക്കുള്ള ഇന്റർഫേസിലൂടെ പുറത്തുപോയി ചാകുന്ന ഒരു മറുപടി ലഭിക്കും.
റൂട്ട് ഉണ്ടെങ്കിലും ഇത് തകർക്കാൻ രണ്ടാം ഇന്റർഫേസ് മതി. മറ്റൊരു VLAN-ൽ മാനേജ്മെന്റ് ലിങ്കുള്ള NAS, ബാക്കപ്പ് uplink ഉള്ള സെർവർ, ഒരു ഉറവിട ശ്രേണിയെ രണ്ടാം പട്ടികയിലേക്ക് അയയ്ക്കുന്ന പോളിസി നിയമം: ഇവയിൽ ഏതിനും മറുപടി പിടിച്ചെടുക്കാം. Linux-ൽ, ip rule show ഉം ip route show table all ഉം ഡിഫോൾട്ട് ലിസ്റ്റ് മറയ്ക്കുന്ന നിയമങ്ങളും പട്ടികകളും കാണിക്കുന്നു.
മറുപടി അയയ്ക്കുന്ന യന്ത്രത്തിൽ തീരുമാനം വായിക്കുക
എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് കേർണലിനോട് ചോദിക്കുക, ഉറവിട വിലാസം നൽകുക, കാരണം ഉറവിടാധിഷ്ഠിത നിയമങ്ങൾ മറുപടി മാറ്റുന്നു.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"ഔട്ട്പുട്ട് പുറത്തേക്കുള്ള ഇന്റർഫേസും അടുത്ത ഹോപ്പും പേരിടുന്നു. ഇന്റർഫേസ് VPN ഗേറ്റ്വേയ്ക്ക് അഭിമുഖമായതല്ലെങ്കിൽ നിങ്ങൾ തകരാറ് കണ്ടെത്തി, ബാക്കിയുള്ള ജോലി റൂട്ട് എവിടെ വേണമെന്ന് തിരഞ്ഞെടുക്കലാണ്. ഗേറ്റ്വേയിൽനിന്നുള്ള ping ഇവിടെ കുറച്ചേ തെളിയിക്കുന്നുള്ളൂ: വിദൂര ഹോസ്റ്റിന് സ്ഥാപിക്കാവുന്ന ഒരു വിലാസത്തോടെയാണ് അത് മറുപടി നൽകുന്നത്, നിങ്ങളുടെ ലാപ്ടോപ്പിന്റെ വിലാസത്തോടെയല്ല.
Windows-ൽ തത്തുല്യമായത് തീരുമാനത്തിന് Find-NetRoute -RemoteIPAddress 10.10.5.10 ഉം പട്ടികയ്ക്ക് Get-NetRoute ഉം ആണ്. ഡിഫോൾട്ടിനേക്കാൾ ഉയർന്ന മെട്രിക് വഹിക്കുന്ന New-NetRoute ഉപയോഗിച്ച് ചേർത്ത റൂട്ട് നിശ്ശബ്ദമായി തോൽക്കുന്നു, അതിനാൽ എൻട്രിയല്ല, മെട്രിക് കോളം വായിക്കുക. പിന്നെ പാക്കറ്റുകളാൽ സ്ഥിരീകരിക്കുക: വിദൂര LAN ഇന്റർഫേസിൽ tcpdump -ni any "host 10.10.5.10 and tcp port 445" അഭ്യർത്ഥന കാണിക്കുന്നു, ടണൽ ഭാഗത്ത് അതേ ഫിൽട്ടർ മറുപടി തിരികെ വന്നോയെന്ന് കാണിക്കുന്നു. അഭ്യർത്ഥന കാണുന്നു, മറുപടിയില്ല — മറുപടി മറ്റെവിടേക്കോ റൂട്ട് ചെയ്യപ്പെട്ടു അല്ലെങ്കിൽ വലിച്ചെറിയപ്പെട്ടു; തെറ്റായ ഇന്റർഫേസിലെ മറുപടി റൂട്ട് തൊടുന്നതിന് മുൻപ് കുറ്റവാളിയെ തരുന്നു.
സെർവറിന്റെ ഗേറ്റ്വേ VPN അന്ത്യബിന്ദു അല്ലാത്തപ്പോൾ
ഒരുപാട് സൈറ്റുകൾ സെർവറുകൾക്കും കോൺസെൻട്രേറ്ററിനും ഇടയിൽ ഫയർവാൾ വയ്ക്കുന്നു. ആ ഫയർവാൾ മറുപടി കൈമാറുന്നു, അതിനാൽ നിങ്ങളുടെ ക്ലയന്റ് പ്രിഫിക്സിന് VPN ഗേറ്റ്വേയിലേക്ക് ചൂണ്ടുന്ന റൂട്ടും ഇരു ദിശകളിലും കൈമാറ്റ പോളിസിയും അതിന് വേണം. സ്റ്റേറ്റ് സൂക്ഷിക്കുന്ന ഉപകരണങ്ങൾ കാര്യം വഷളാക്കുന്നു: അഭ്യർത്ഥന അത് അനുവദിച്ച ഒരു LAN ഹോസ്റ്റിൽനിന്ന് ഫയർവാൾ കടന്നു, മറുപടി ഇപ്പോൾ മറ്റൊരു ദിശയിൽനിന്ന് വരുന്നു, കണക്ഷൻ ട്രാക്കിംഗ് എൻട്രി ഇനി ഒത്തുപോകുന്നില്ല, അതിനാൽ പാക്കറ്റ് നിരസിക്കപ്പെടുന്നതിനുപകരം അസാധുവായി വലിച്ചെറിയപ്പെടുന്നു. ട്രാഫിക് അപ്രത്യക്ഷമാകുമ്പോൾ പോളിസി ലോഗ് ശൂന്യമായി തോന്നുന്നത് അതുകൊണ്ടാണ്.
ഗേറ്റ്വേയ്ക്ക് സ്വന്തമായി രണ്ടാം ഫിൽട്ടറുണ്ട്. Linux-ന്റെ റിവേഴ്സ് പാത്ത് ഫിൽട്ടറിംഗ്, അവ എത്തിയ ഇന്റർഫേസിലൂടെ ഉറവിടം എത്തിച്ചേരാനാവാത്ത പാക്കറ്റുകൾ വലിച്ചെറിയുന്നു, അത് സാധുവായ അസമമായ മടക്കപ്പാതയുടെ കൃത്യമായ രൂപമാണ്. strongSwan-ന്റെ ഫോർവേഡിംഗ് ഗൈഡ് അതുകൊണ്ടുതന്നെ net.ipv4.ip_forward ഉം അയച്ച net.ipv4.conf.all.rp_filter ഉം ആവശ്യപ്പെടുന്നു. ഏതെങ്കിലും ഗേറ്റ്വേയിൽ കർശനമായ 1 മൂല്യം ശരിയായ റൂട്ട് നിശ്ശബ്ദമായി തകർക്കുന്നു, എവിടെ നോക്കണമെന്ന് അറിയാമെങ്കിൽ nstat -az ഡ്രോപ്പുകൾ കാണിക്കുന്നു.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
റൂട്ട് ചെയ്യുകയോ വിവർത്തനം ചെയ്യുകയോ ചെയ്ത്, പിന്നെ ഇരു ദിശകളിലും പരിശോധിക്കുക
രണ്ട് അറ്റകുറ്റപ്പണികൾ തുല്യമല്ല. റൂട്ട് ചേർക്കുന്നത് ക്ലയന്റിന്റെ വിലാസം അതേപടി നിലനിർത്തുന്നു, അതിനാൽ ഉറവിടാധിഷ്ഠിത നിയമങ്ങളും ഓഡിറ്റ് ലോഗുകളും വിളിക്കുന്നയാളെ രേഖപ്പെടുത്തുന്ന ആപ്പുകളും തുടരുന്നു; വില അതാണ്, തീരുമാനമെടുക്കുന്ന ഓരോ ഹോപ്പിനും റൂട്ട് വേണം, അതായത് തെറ്റാകാൻ കൂടുതൽ സ്ഥലങ്ങൾ. വിദൂര ഗേറ്റ്വേയിലെ മുഖംമൂടി മടക്കപ്പാതയെ ഒരു ഹോപ്പിലേക്ക് ചുരുക്കുന്നു, കാരണം മറുപടി ഇപ്പോൾ ഗേറ്റ്വേയ്ക്കുതന്നെ അയയ്ക്കുന്നു, ഏത് ക്ലയന്റ് എന്ത് ചെയ്തുവെന്ന് മറയ്ക്കുന്നു.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEബോധപൂർവം തിരഞ്ഞെടുക്കുക: ക്ലയന്റുകൾ ഗേറ്റ്വേ വിലാസമായി കാണപ്പെടാൻ തുടങ്ങിയാൽ, ഉറവിടാധിഷ്ഠിത ACL-കൾ അവയെ വേർതിരിച്ചറിയുന്നത് നിർത്തുന്നു, മറുപടി ടണലിലേക്ക് തിരികെ എഴുതപ്പെടാൻ conntrack മാപ്പിംഗ് സൂക്ഷിക്കണം. സെലക്ടറുകൾ ഇപ്പോഴും ക്ലയന്റ് പ്രിഫിക്സ് ഒഴിവാക്കുന്നുവെങ്കിൽ, അഭ്യർത്ഥന ഒരിക്കലും ടണലിൽ കടന്നിട്ടില്ലാത്തതിനാൽ NAT ഒന്നും മാറ്റുന്നില്ല.
ഇത് ശരിയായി എന്ന് പറയുന്നതിന് മുൻപ് നാല് കാര്യങ്ങൾ ക്രമത്തിൽ സ്ഥിരീകരിക്കുക: മറുപടി അയയ്ക്കുന്ന ഹോസ്റ്റിലെ റൂട്ട്, അത് കൈമാറുന്ന ഓരോ ഹോപ്പിലെയും റൂട്ട്, രണ്ട് പ്രിഫിക്സുകളും ഉൾക്കൊള്ളുന്ന സെലക്ടറുകൾ, മറുപടി നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന ഉറവിടത്തോടെ ടണലിൽ കടക്കുന്നത് കാണിക്കുന്ന ഒരു ക്യാപ്ചർ. പിന്നെ മറ്റേ സൈറ്റിൽനിന്ന് പരീക്ഷണം ആവർത്തിക്കുക. ഒരു ദിശ കടന്നുപോകുന്നത് പകുതി തുറന്ന രൂപകൽപ്പനയാണ്, രണ്ടാം ദിശ സാധാരണയായി നിങ്ങൾ ഇപ്പോൾ നന്നാക്കിയതിൽനിന്ന് വ്യത്യസ്തമായ കാരണത്താൽ പരാജയപ്പെടുന്നു.