VPN ഗേറ്റ്‌വേയുടെ സ്വന്തം വിലാസത്തിൽ LAN സേവനം പ്രസിദ്ധീകരിക്കുക

ഗേറ്റ്‌വേയുടെ സ്വന്തം ടണൽ വിലാസങ്ങളിലൊന്നിൽ LAN ഉപകരണം അവതരിപ്പിക്കാൻ ഒരു വരി NAT മതി. എന്നിട്ടും കണക്ഷൻ പരാജയപ്പെടുന്നു, കാരണം മറുപടി നൽകുന്ന ഉപകരണത്തിന് ക്ലയന്റിന്റെ വിലാസം ആ ഗേറ്റ്‌വേ വഴി എത്താവുന്നതാണെന്ന് അറിയില്ല. പാക്കറ്റ് ക്ലയന്റിൽ നിന്ന് അകത്തേക്ക് പിന്തുടരുക, തുടർന്ന് മറുപടി തിരികെ പുറത്തേക്ക് പിന്തുടരുക, എന്നാൽ കാണാത്ത പകുതി വ്യക്തമാകും.

ക്ലയന്റിന്റെ വീക്ഷണകോണിൽ നിന്ന് തുടങ്ങുക

ഈ ഉദാഹരണത്തിലെ ക്ലയന്റ് VPN പൂളിൽ 10.62.0.0/24-ൽ ഇരിക്കുന്നു, 8080 പോർട്ടിൽ 10.62.0.1-ലേക്ക് കണക്ട് ചെയ്യുന്നു. ആ വിലാസം ഗേറ്റ്‌വേയുടേത് തന്നെയാണ്, അതിനാൽ പാക്കറ്റ് മറ്റൊരു പിയറിലേക്കല്ല, ഗേറ്റ്‌വേയുടെ കർണലിലേക്ക് എത്തുന്നു. ഗേറ്റ്‌വേയുടെ പിന്നിൽ LAN 172.21.4.0/24 ആണ്. ഗേറ്റ്‌വേയ്ക്ക് 172.21.4.10 ഉണ്ട്, യഥാർത്ഥത്തിൽ HTTP നൽകുന്ന ഉപകരണം 172.21.4.40 ആണ്.

മറ്റൊരു VPN പിയറിന് ഉള്ള വിലാസം ഗേറ്റ്‌വേയുടെ സേവന വിലാസവുമായി പരസ്പരം മാറ്റാൻ കഴിയില്ല. ക്ലയന്റ് ഒരു പിയറിന്റെ വിലാസത്തിലേക്ക് കണക്ട് ചെയ്യുന്നുണ്ടെങ്കിൽ, ഗേറ്റ്‌വേയുടെ ഒരു നിയമവും ഒട്ടും ഉൾപ്പെടുന്നില്ല, ഈ മുഴുവൻ യാത്രയും തെറ്റായ കേസാണ്.

ലക്ഷ്യസ്ഥാന വിവർത്തനത്തിന്റെ പരിധി ബോധപൂർവ്വം നിർണ്ണയിക്കുക

ഇടുങ്ങിയ പതിപ്പ് ഒരു പോർട്ട് അവതരിപ്പിക്കുന്നു, ലക്ഷ്യസ്ഥാനം മാത്രം വീണ്ടും എഴുതുന്നു. പാക്കറ്റ് അതിന്റെ പ്രോട്ടോക്കോളും ഉറവിടവും നിലനിർത്തുന്നു, അതാണ് ബാക്കി യാത്രയെ രസകരമാക്കുന്നത്.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

പ്രോട്ടോക്കോളും പോർട്ട് മാനദണ്ഡങ്ങളും ഇല്ലാത്ത നിയമം വിശാല പതിപ്പാണ്: ക്ലയന്റ് തിരഞ്ഞെടുത്ത ഏത് പോർട്ടും നിലനിർത്തി വിലാസം മാത്രം മാറ്റുന്നു. മുഴുവൻ ഹോസ്റ്റും അവതരിപ്പിക്കാൻ ഉദ്ദേശിക്കുമ്പോൾ ഇത് ന്യായമാണ്, ഒരു സേവനം മാത്രമാണ് ഉദ്ദേശ്യമെങ്കിൽ തെറ്റാണ്. നിയമം വീണ്ടും വായിച്ച് ഇന്റർഫേസിന്റെ പേര് സ്ഥിരീകരിക്കുക. തെറ്റായ ഇന്റർഫേസിലെ DNAT നിയമം ഒന്നുമായും പൊരുത്തപ്പെടുന്നില്ല, അത് നിയമം ഇല്ലാത്തതിന് സമാനമായ സമയപരിധി ഉണ്ടാക്കുകയും ഉപകരണത്തിലേക്ക് നോക്കി ഒരു മണിക്കൂർ പാഴാക്കുകയും ചെയ്യുന്നു.

ഫോർവേഡിംഗ് അതിർത്തി യോജിക്കട്ടെ

വിവർത്തനം ഹെഡർ മാറ്റുന്നു, അനുമതി നൽകുന്നില്ല. സ്ഥിരസ്ഥിതി ഡ്രോപ്പ് നയത്തിൽ ഫോർവേഡ് ചെയ്ത ഫ്ലോയ്ക്ക് സ്വന്തം അനുമതി വേണം, തിരിച്ചുള്ള ദിശയ്ക്ക് നിങ്ങളുടെ നയത്തിൽ ഇപ്പോൾ തന്നെ ഉണ്ടാകാൻ സാധ്യതയുള്ള സ്ഥാപിത ബന്ധ നിയമം വേണം.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ഓരോ DNAT ഫ്ലോയ്ക്കും വ്യവസ്ഥയില്ലാത്ത അനുമതി ഈ രൂപകൽപ്പനയേക്കാൾ വിശാലമാണ്, പിന്നീട് മറ്റാരെങ്കിലും ചേർക്കുന്ന മാപ്പിംഗുകൾക്കും അത് അനുവാദം നൽകും. ലക്ഷ്യസ്ഥാനത്തിന്റെയും പോർട്ടിന്റെയും പേര് പറയുക, ബാക്കി അടച്ചിടുക. ഫോർവേഡ് നിയമത്തിലെ കൗണ്ടറുകൾ പൂജ്യത്തിൽ നിൽക്കുമ്പോൾ NAT കൗണ്ടറുകൾ ഉയരുന്നുണ്ടെങ്കിൽ, പാക്കറ്റ് നിങ്ങളുടെ നിയമത്തിന് മുമ്പ് തന്നെ വലിച്ചെറിയപ്പെടുന്നു. രണ്ടാം പകർപ്പ് ചേർക്കുന്നതിന് പകരം ചെയിനുകളുടെ ക്രമം വായിക്കുക.

ഉപകരണം ഏതെങ്കിലും വിധത്തിൽ മറുപടി നൽകണം

വിവർത്തനത്തിന് ശേഷം ഉപകരണം 10.62.0.0/24-നുള്ളിൽ ഒരു ഉറവിടം കാണുന്നു. അതിന്റെ മറുപടി അതിന്റെ സ്ഥിരസ്ഥിതി ഗേറ്റ്‌വേയിലേക്ക് പോകുന്നു, അത് LAN റൂട്ടർ ആണ്, VPN ഗേറ്റ്‌വേ അല്ല, മറ്റെന്തെങ്കിലും വേറെ പറയുന്നില്ലെങ്കിൽ. രണ്ട് ശൃംഖലകൾ ഇത് ശരിയാക്കുന്നു, അവ തുല്യമല്ല. ഉപകരണത്തിലോ LAN റൂട്ടറിലോ ഉള്ള ഒരു റൂട്ട് 10.62.0.0/24-നെ 172.21.4.10-ലേക്ക് അയക്കുകയും ക്ലയന്റ് ഉറവിടം നിലനിർത്തുകയും ചെയ്യുന്നു. പരിമിതമായ ഉറവിട വിവർത്തനം പകരം ക്ലയന്റിനെ ഗേറ്റ്‌വേയുടെ LAN വിലാസത്തിന് പിന്നിൽ ഒളിപ്പിക്കുന്നു.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

സേവനത്തിന് എന്ത് വേണം എന്നതിന് അനുസരിച്ച് തിരഞ്ഞെടുക്കുക. ഓരോ ക്ലയന്റിനുമുള്ള നയവും അർത്ഥവത്തായ ലോഗുകളും റൂട്ട് ചെയ്ത രൂപം ആഗ്രഹിക്കുന്നു; റൂട്ട് നൽകാൻ കഴിയാത്ത ഉപകരണമോ നിർബന്ധമായും LAN വിലാസം കാണേണ്ട സേവനമോ വിവർത്തനം ചെയ്ത രൂപത്തിലേക്ക് വിരൽ ചൂണ്ടുന്നു. ഒരു മറുപടി പ്രവർത്തിക്കാൻ ആഗോള masquerade നിയമത്തിലേക്ക് കൈ നീട്ടരുത്. അത് ഓരോ ക്ലയന്റിനെയും ഓരോ ലക്ഷ്യസ്ഥാനത്തിൽ നിന്നും ഒളിപ്പിക്കുകയും ഉറവിട വിലാസങ്ങളെ ആശ്രയിക്കുന്ന നയങ്ങൾ നിശബ്ദമായി തകർക്കുകയും ചെയ്യുന്നു.

ഗേറ്റ്‌വേയിൽ നിന്ന് തന്നെ പരീക്ഷിക്കരുത്

ഗേറ്റ്‌വേയിൽ 10.62.0.1-ലേക്ക് സൃഷ്ടിക്കുന്ന അഭ്യർത്ഥന വരുന്ന PREROUTING വഴിയല്ല, OUTPUT ചെയിൻ വഴി പുറത്തുപോകുന്നു. അതിന്റെ പരാജയമോ വിജയമോ ക്ലയന്റിന് അഭിമുഖമായ നിയമത്തെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അങ്ങനെയാണ് പ്രവർത്തിക്കുന്ന ഒരു നിയമം തകർന്നിരിക്കുന്നു എന്ന് ആളുകൾ നിഗമനം ചെയ്യുന്നത്.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

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