UFW-യുടെ before.rules-ൽ VPN NAT എവിടെ വരണം, അത് എങ്ങനെ പരിശോധിക്കാം

ഷെല്ലിൽ ടൈപ്പ് ചെയ്യുമ്പോൾ പ്രവർത്തിക്കുന്ന NAT നിയമം before.rules-ലേക്ക് പേസ്റ്റ് ചെയ്യുമ്പോൾ പരാജയപ്പെടുന്നു, കാരണം ആ ഫയൽ ഒരു സ്ക്രിപ്റ്റ് അല്ല. ടേബിൾ വിഭാഗങ്ങൾ, ചെയിൻ പ്രഖ്യാപനങ്ങൾ, ഓരോ ടേബിളിനും COMMIT അടയാളം എന്നിവയുള്ള റിസ്റ്റോർ ഫോർമാറ്റ് ഡോക്യുമെന്റാണ് അത്. തെറ്റായ സ്ഥലത്തുള്ള ഒരു വരി മുഴുവൻ റിസ്റ്റോർ നിർത്തുകയോ നിങ്ങൾ അവിടെയുണ്ടെന്ന് കരുതിയ നിയമങ്ങൾ നിശ്ശബ്ദമായി ഒഴിവാക്കുകയോ ചെയ്യും. താഴെയുള്ള റൺബുക്ക് ശകലത്തെ ഫ്രെയിംവർക്ക് പ്രതീക്ഷിക്കുന്ന സ്ഥലത്ത് വയ്ക്കുകയും അടുത്ത റീലോഡിന് മുമ്പ് ഫലം തെളിയിക്കുകയും ചെയ്യുന്നു.

ഷെൽ കമാൻഡ് ഒരു റിസ്റ്റോർ ഫയലല്ല

iptables -t nat ൽ തുടങ്ങുന്ന വരി iptables ബൈനറിക്കുള്ള നിർദ്ദേശമാണ്, അതേസമയം UFW വായിക്കുന്ന ഫയൽ പൂർണ്ണ നിയമക്കൂട്ടത്തിന്റെ വിവരണമാണ്. വ്യത്യാസം കോസ്മെറ്റിക് അല്ല: റിസ്റ്റോർ ഫോർമാറ്റിന് ഏത് ടേബിളിലാണ്, ഏത് ചെയിനുകൾ നിലവിലുണ്ട്, ടേബിൾ എവിടെ അവസാനിക്കുന്നു എന്നിവ അറിയണം. ആ ഡോക്യുമെന്റിൽ പേസ്റ്റ് ചെയ്യുന്ന കമാൻഡ് ഒന്നുകിൽ സിന്റാക്സ് പിശകാണ്, അല്ലെങ്കിൽ അതിലും മോശമായി, തെറ്റായ ടേബിളിൽ ഘടിപ്പിച്ച നിയമമാണ്. ഈ ഫയലുകൾ റിസ്റ്റോർ ടൂളുകൾ വഴി ലോഡ് ചെയ്യുന്നത് അവ ക്രമാനുസൃതമല്ലാത്തതിനാൽ, പ്രഖ്യാപനാത്മകമായതിനാലാണ്.

ഡോക്യുമെന്റ് മൊത്തമായും ലോഡ് ചെയ്യുന്നു, അതിനാൽ ഒരു വികലമായ വിഭാഗം ബാക്കി ഫയൽ പ്രയോഗിക്കുന്നത് തടയാം. അതിനാൽ NAT ശകലത്തിലെ ചെറിയ തെറ്റ് ഫിൽട്ടർ നിയമങ്ങളെയും കൂടെ താഴേക്ക് വലിച്ചിടുന്നു, അങ്ങനെ ഫയർവാൾ മാറ്റം ഒരു തടസ്സമായി മാറുന്നു.

നിലവിലുള്ള ടേബിൾ വിഭാഗത്തിനുള്ളിൽ ശകലം വയ്ക്കുക

NAT ശകലത്തിന് ഒരു രൂപമുണ്ട്, രൂപം അതിലെ നിയമപാഠത്തേക്കാൾ പ്രധാനമാണ്. ടേബിൾ തലക്കെട്ട് വിഭാഗം തുറക്കുന്നു, ചെയിൻ പ്രഖ്യാപനങ്ങൾ കൗണ്ടറുകൾ സ്ഥാപിക്കുന്നു, നിയമങ്ങൾ പിന്തുടരുന്നു, COMMIT വിഭാഗം അടയ്ക്കുന്നു.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

മുകളിലെ പൂളും ഇന്റർഫേസും നിങ്ങളുടെ മൂല്യങ്ങൾക്കുള്ള പ്ലേസ്ഹോൾഡറുകളാണ്; പകർത്താൻ യോഗ്യമായ ഭാഗം ഘടനയാണ്. ഫയലിൽ ഇതിനകം *nat വിഭാഗമുണ്ടെങ്കിൽ, രണ്ടാമത്തേത് തുറക്കുന്നതിന് പകരം അതേ വിഭാഗത്തിനുള്ളിൽ നിയമം ചേർക്കുക, കാരണം ഫോർമാറ്റ് ഓരോ ടേബിളിനും ഒരു COMMIT പ്രതീക്ഷിക്കുന്നു, ഒരേ ടേബിളിന് രണ്ട് വിഭാഗങ്ങൾ സംഭവിക്കാൻ കാത്തിരിക്കുന്ന ഒരു അറ്റകുറ്റപ്പണിയാണ്. വിതരണത്തിന്റെ ചെയിൻ നിർവചനങ്ങൾ അതേപടി സൂക്ഷിക്കുക, വെണ്ടർ സ്വന്തം സംയോജനത്തിനായി ചേർത്തവ ഉൾപ്പെടെ. UFW ഫ്രെയിംവർക്ക് മാനുവൽ before, user, after ഫയലുകളും പൊരുത്തപ്പെടുന്ന COMMIT ആവശ്യകതയും രേഖപ്പെടുത്തുന്നു.

ഫയൽ ശൂന്യമാണെങ്കിൽ, ഒരു ട്യൂട്ടോറിയലിൽ നിന്ന് അത് നിറയ്ക്കരുത്. ഏത് പാക്കേജ് അതിന്റെ ഉടമയാണെന്നും യഥാർത്ഥ ലൈവ് നയം എന്താണെന്നും സ്ഥിരീകരിക്കുക, കാരണം ശൂന്യമായ സ്ഥിര ഫയൽ കെർണലിൽ നിയമങ്ങളില്ലെന്ന് തെളിയിക്കുന്നില്ല, ലോഡ് ചെയ്ത നിയമക്കൂട്ടം അടുത്ത റീലോഡിന് വായിക്കാൻ പൂർണ്ണ ഫയൽ ഉണ്ടെന്ന് തെളിയിക്കുന്നുമില്ല. ആദ്യം പിന്തുണയ്ക്കുന്ന അടിസ്ഥാനരേഖ പുനഃസ്ഥാപിക്കുക, തുടർന്ന് സൈറ്റ് മാറ്റങ്ങൾ അതിന് മുകളിൽ വീണ്ടും പ്രയോഗിക്കുക.

പ്രയോഗിക്കാതെ സ്ഥാനാർത്ഥിയെ പരിശോധിക്കുക

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

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

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

ഇൻസ്റ്റാൾ ചെയ്ത ബാക്കെൻഡിനും വിലാസ കുടുംബത്തിനും യോജിക്കുന്ന ടൂൾ തിരഞ്ഞെടുക്കുക. അനുയോജ്യതാ പാളി വഴി nft ബാക്കെൻഡ് പ്രവർത്തിപ്പിക്കുന്ന ഹോസ്റ്റിന് അനുബന്ധ കമാൻഡ് ആവശ്യമാണ്, IPv6 നിയമങ്ങൾ തികച്ചും വ്യത്യസ്തമായ ഒരു ഫയലിലാണ്.

ഫോർവേഡിംഗ്, NAT, ആക്സസ് നയം വേർതിരിച്ച് നിർത്തുക

സ്രോതസ്സ് വിവർത്തനം ഒരു വിലാസ പ്രശ്നം പരിഹരിക്കുന്നു, ഒന്നും അനുവദിക്കുന്നുമില്ല. ഫോർവേഡിംഗ് sysctl-ഉം ഫിൽട്ടർ ടേബിളും നിയന്ത്രിക്കുന്ന പ്രത്യേക അനുമതിയാണ്, ടണൽ റൂട്ട് ചെയ്യുന്നുവെങ്കിലും ട്രാഫിക് കടത്തിവിടുന്നില്ലെങ്കിൽ ആളുകൾ മറക്കുന്നത് അതാണ്. ആക്സസ് നയം ഏത് ഉറവിടങ്ങൾക്ക് ഏത് സേവനങ്ങളിൽ എത്താമെന്നതിനെക്കുറിച്ചുള്ള മൂന്നാമത്തെ തീരുമാനമാണ്, ഒരു NAT നിയമവും അത് പ്രകടിപ്പിക്കുന്നില്ല. ഈ മൂന്നും വേർതിരിച്ച് നിർത്തുന്നതാണ് ഒരു അവ്യക്ത ലക്ഷണത്തിന് പകരം പരാജയത്തെ രോഗനിർണ്ണയയോഗ്യമാക്കുന്നത്.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

ആ മൂന്ന് ഔട്ട്പുട്ടുകൾ ഒന്നൊന്നായല്ല, ഒരുമിച്ച് വായിക്കുക. ഫോർവേഡിംഗ് പ്രവർത്തനരഹിതമായ masquerade നിയമം കണക്ട് ചെയ്യുന്നുവെങ്കിലും എങ്ങും എത്താത്ത ഒരു ക്ലയന്റ് സൃഷ്ടിക്കുന്നു, ഇത് ക്ലയന്റ് വശത്തുനിന്ന് കൃത്യമായി ഒരു റൂട്ടിംഗ് തകരാറായി തോന്നുകയും ആളുകളെ തെറ്റായ ഫയലിലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു. ഫിൽട്ടർ ടേബിൾ വളരെ വീതിയുള്ള accept ഒളിച്ചിരിക്കുന്ന സ്ഥലവുമാണ്, അതിനാൽ അവിടെയുള്ളപ്പോൾ അതിന്റെ സ്ഥിരനയം പരിശോധിക്കുക.

റീലോഡ്, നിരസിക്കൽ, VPN നഷ്ടം എന്നിവ സ്ഥിരീകരിക്കുക

മൂന്ന് നിരീക്ഷണങ്ങൾ പൂർണ്ണ സ്വീകാര്യതാ പരിശോധന രൂപപ്പെടുത്തുന്നു: റീലോഡ് വിജയിക്കുന്നു, അനുവദിച്ച ക്ലയന്റ് പ്രവർത്തനം നടക്കുന്നു, നിരസിക്കേണ്ട അഭ്യർത്ഥന യഥാർത്ഥത്തിൽ നിരസിക്കപ്പെടുന്നു. മൂന്നാമത്തേതാണ് ഒഴിവാക്കപ്പെടുന്നത്, നയം എന്തെങ്കിലും ചെയ്യുന്നുണ്ടെന്നതിന്റെ ഏക തെളിവ് അതാണ്.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

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

IPv4 NAT IPv6-നെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അതിനാൽ നിയമത്തോടൊപ്പം അതേ കുറിപ്പിൽ രണ്ട് കുടുംബങ്ങൾക്കുമുള്ള ഉദ്ദേശിച്ച പരിധി രേഖപ്പെടുത്തുക. ലക്ഷ്യം സുസ്ഥിരമായ നിയന്ത്രിത നയമാണ്, യാദൃച്ഛികമായി പാഴ്സ് ചെയ്യപ്പെട്ട ഒരു ശകലം അതിന്റെ തെളിവല്ല.