VPN ക്ലയന്റുകൾ സെർവറിലെത്തുന്നു, LAN-ലേക്ക് ഇല്ല: ഏത് പരിഹാരം?

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

ആദ്യം ഏത് ദിശയാണ് തകർന്നതെന്ന് ഉറപ്പാക്കുക

അഭ്യർത്ഥന VPN പൂളിൽ നിന്നുള്ള ഉറവിട വിലാസത്തോടെ ടണൽ ഇന്റർഫേസിൽ എത്തുന്നു. സെർവർ അത് LAN-ലെ ഹോസ്റ്റിലേക്ക് അയയ്ക്കുന്നു, ആ ഹോസ്റ്റ് തന്റെ സ്വന്തം പട്ടിക പേരിടുന്ന ഗേറ്റ്‌വേയ്ക്ക്, സാധാരണയായി LAN റൗട്ടറിന്, മറുപടി നൽകുന്നു. റൗട്ടറിന് പൂളിലേക്ക് മാർഗമില്ലെങ്കിൽ മറുപടി അവിടെ തന്നെ മരിക്കുന്നു അല്ലെങ്കിൽ ഇന്റർനെറ്റിലേക്ക് അലയുന്നു.

ഏതെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് രണ്ട് മെഷീനുകളും പരിശോധിക്കുക. സെർവറിന്റെ പട്ടിക ഏത് വഴിയാണ് ക്ലയന്റിലെത്തുന്നതെന്ന് ചോദിക്കുക; LAN-ലെ ഹോസ്റ്റ് അതേ വിലാസത്തിൽ എങ്ങനെ എത്തുമെന്ന് ചോദിക്കുക. ആദ്യ തിരയൽ സാധാരണയായി ടണലിലേക്ക് വിരൽ ചൂണ്ടുന്നു, രണ്ടാമത്തേത് LAN റൗട്ടറിലേക്ക്, ആ വ്യത്യാസമാണ് ഒരു വരിയിലെ തകരാർ. രണ്ട് തിരയലുകൾ ഫയർവാൾ ഓഡിറ്റിനേക്കാൾ വിലകുറഞ്ഞതാണ്, പ്രശ്നത്തിന്റെ ദിശ തീരുമാനിക്കുന്നു.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

LAN-ലെ ഹോസ്റ്റ് ഇതിനകം VPN സെർവറിലേക്ക് വിരൽ ചൂണ്ടുന്നുണ്ടെങ്കിൽ, നിങ്ങളുടെ പ്രശ്നം ഫയർവാൾ നിയമമോ MTU പരിധിയോ ആണ്, തിരിച്ചുവരവ് മാർഗം കാണാതിരിക്കലല്ല. ഫിൽട്ടർ ശരിയാക്കാൻ മാർഗം ചേർക്കരുത്.

ആദ്യ ചോദ്യം: വിദൂര LAN-ലെ റൗട്ടർ തിരുത്താൻ കഴിയുമോ?

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

ആരെങ്കിലും പൂൾ മാറ്റുന്ന ദിവസം ഇത് നിശ്ശബ്ദമായി പരാജയപ്പെടുന്നു. മൂല്യം ഒരിക്കൽ എഴുതി വയ്ക്കുക, മൂന്നിടത്തിൽ ഏതെങ്കിലും ഒന്നിലെ മാറ്റത്തെ മൂന്നിനും മാറ്റമായി കണക്കാക്കുക.

സേവനം ഹോസ്റ്റ് ചെയ്യുന്ന NAS അല്ലെങ്കിൽ Layer 3 സ്വിച്ചിനും അതേ മാർഗം വേണം, അത് എല്ലാം ആ മാർഗമുള്ള റൗട്ടർ വഴി അയയ്ക്കുന്നില്ലെങ്കിൽ. ഉപനെറ്റ്വർക്ക് അവസാനിപ്പിക്കുന്ന ഉപകരണം പരിശോധിക്കുക, ഇന്റർനെറ്റിലേക്ക് നോക്കുന്നത് മാത്രമല്ല. ചെറിയ നെറ്റ്വർക്കുകളിൽ റൗട്ടിംഗിനെക്കുറിച്ച് അഭിപ്രായമുള്ള മൂന്ന് ഉപകരണങ്ങൾ പലപ്പോഴും ഉണ്ടാകും.

രണ്ടാം ചോദ്യം: LAN-ന് ക്ലയന്റ് വിലാസങ്ങൾ കാണുന്നത് നിർത്താൻ കഴിയുമോ?

റൗട്ടർ മറ്റൊരാളുടേതാണെങ്കിൽ, VPN സെർവറിലെ വിവർത്തനത്തിന് സഹകരണം ആവശ്യമില്ല. LAN-ലെ ഹോസ്റ്റ് സെർവറിന്റെ LAN വിലാസം കാണുന്നു, അതിന് മറുപടി നൽകുന്നു, സെർവർ തിരികെ വിവർത്തനം ചെയ്യുന്നു. അതുകൊണ്ടാണ് ഉപകരണങ്ങളും NAT അടിസ്ഥാനമാക്കിയ വിദൂര ആക്സസ് റോളുകളും ഇങ്ങനെ പെരുമാറുന്നത്.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

വില ആട്രിബ്യൂഷനാണ്: ഓരോ ക്ലയന്റിന്റെയും വിലാസങ്ങൾ LAN ലോഗുകളിൽ നിന്ന് അപ്രത്യക്ഷമാകുന്നു. LAN-ലെ ഹോസ്റ്റിലെ ഏതെങ്കിലും അനുമതി പട്ടിക അപ്പോൾ പൂളിന് പകരം സെർവറിനെ പേരിടേണ്ടിവരും.

സഹകരണം ലഭ്യമല്ലാത്തപ്പോൾ വിവർത്തനം തിരഞ്ഞെടുക്കുക, വെറും ബുദ്ധിമുട്ടുള്ളപ്പോൾ അല്ല. ഇത് ക്ലയന്റിനെ ഓരോ ഭാവി അന്വേഷണത്തിൽ നിന്നും മറയ്ക്കുന്നു, ഏത് ലാപ്‌ടോപ്പാണ് കണക്ഷൻ തുറന്നതെന്ന് അറിയേണ്ടവയിൽ നിന്നും. വിലാസങ്ങൾ പേലോഡിൽ ഉൾക്കൊള്ളിക്കുന്ന പ്രോട്ടോക്കോളുകളും ഇത് തകർക്കാം, കാരണം വിവർത്തനം ഹെഡറിലാണ് ജീവിക്കുന്നത്. ഒരു തിരഞ്ഞെടുപ്പും മികച്ചതല്ല; രണ്ടും ഉടമസ്ഥതയെക്കുറിച്ചുള്ള വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് മറുപടി നൽകുന്നു.

മൂന്നാം ചോദ്യം: സെർവർ തന്നെ മറ്റൊരു ടണലിന്റെ ക്ലയന്റാണോ?

മറ്റൊരു ടോപ്പോളജി സങ്കൽപ്പിക്കുക: VPN സെർവർ ഒരു വാണിജ്യ ദാതാവിനെയും ഡയൽ ചെയ്യുന്നു, അതിനാൽ രണ്ട് ടണലുകളും രണ്ട് വിലാസ കൂട്ടങ്ങളും ഉണ്ട്. സ്വന്തം ക്ലയന്റുകൾക്കായി അയയ്ക്കുന്ന ട്രാഫിക് ദാതാവിലൂടെ പുറത്തുപോകുന്നു, അത് മറുപടികൾ പൂൾ വിലാസങ്ങളിലേക്ക് തിരികെ റൂട്ട് ചെയ്യില്ല. അതുകൊണ്ടാണ് രണ്ട് ടണലുകളും ആരോഗ്യകരമായിരിക്കെ മറുപടികൾ അപ്രത്യക്ഷമാകുന്നത്.

പരിഹാരം പുറത്തേക്കുള്ള ടണലും മാസ്ക് ചെയ്യുകയാണ്, ദാതാവ് സെർവറിന്റെ ടണൽ വിലാസം മാത്രം കാണണം. എതിർദിശയ്ക്ക് സ്വന്തം നിയമം വേണം, കാരണം സെർവർ സ്വന്തം ക്ലയന്റിലേക്ക് കണക്ഷൻ തുടങ്ങുന്നത് വേറെ പ്രവാഹമാണ്. ആ നിയമമില്ലാതെ ക്ലയന്റ് റൂട്ട് ചെയ്യാൻ കഴിയാത്ത വിലാസത്തിന് മറുപടി നൽകുന്നു. ഇടുങ്ങിയ നിയമം ഏതെങ്കിലും വിശാല മാസ്കിംഗിന് മുമ്പ് വയ്ക്കുക, നിർദ്ദിഷ്ട വിവർത്തനം ജയിക്കട്ടെ.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

പല ഇന്റർഫേസുകളുള്ള ഹോസ്റ്റുകൾ ക്ലയന്റ് വശത്തുനിന്ന് ഒരുപോലെ തോന്നുന്ന ബന്ധപ്പെട്ട തകരാർ ചേർക്കുന്നു. കുറഞ്ഞ മെട്രിക് ഇന്റർഫേസിലൂടെ മറുപടി പുറത്തുപോകുന്നു, കാരണം ഉറവിട വിലാസം മറ്റൊരു പട്ടികയിൽ നിന്നാണ് തിരഞ്ഞെടുത്തത്. തിരിച്ചുവരവ് മാർഗം തിരയലിലൂടെ പരിശോധിക്കുക, പോകുന്ന മാർഗം അത് ഉൾക്കൊള്ളുന്നു എന്ന് കരുതരുത്.

പിന്നീട് രണ്ട് ദിശകളും രണ്ട് വലിപ്പങ്ങളും പരിശോധിക്കുക

മാറ്റത്തിന് ശേഷം ക്ലയന്റിൽ നിന്ന് LAN ഹോസ്റ്റിലേക്കും പിന്നീട് LAN ഹോസ്റ്റിൽ നിന്ന് ക്ലയന്റിലേക്കും ping ചെയ്യുക. രണ്ടാം ദിശയാണ് ആളുകൾ ഒഴിവാക്കുന്നത്, അതാണ് അപൂർണ വിവർത്തന നിയമം വെളിപ്പെടുത്തുന്നത്. രണ്ട് ഫലങ്ങളും സമയ മുദ്രയോടെ രേഖപ്പെടുത്തുക, പിന്നീടുള്ള പിന്നോട്ടുപോക്ക് താരതമ്യപ്പെടുത്താവുന്നതാകും.

പിന്നീട് യഥാർത്ഥ ഡാറ്റ നീക്കുക, കാരണം ചെറിയ ping വിജയിക്കുമ്പോൾ വലിയ കൈമാറ്റം കുടുങ്ങുന്നത് MTU ലക്ഷണമാണ്. ആ തകരാർ മാർഗം ശരിയാക്കിയതിന് നിങ്ങളെത്തന്നെ അഭിനന്ദിച്ചതിന് തൊട്ടുപിന്നാലെ പ്രത്യക്ഷപ്പെടുന്നു.

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