VPN-ന് പിന്നിലെ സേവനത്തിന് ufw allow 443 ഒന്നും ചെയ്തില്ല

ഇൻബൗണ്ട് അനുമതി ഫയർവാൾ ഹോസ്റ്റിനുള്ളതാണ്, അതിന് പിന്നിലെ യന്ത്രത്തിനല്ല. UFW ബ്ലോക്ക് വായിച്ച്, ഫോർവേഡ് ചെയ്യുന്ന സേവനത്തിന് ഒരു റൂട്ട് നിയമം എഴുതുക.

VPN ക്ലയന്റിൽ നിന്ന് ping വിജയിക്കുന്നു, TCP സേവനം സമയം കവിയുന്നു, ufw allow 443/tcp ഒന്നും മാറ്റുന്നില്ല. ആപ്ലിക്കേഷൻ ഗേറ്റ്‌വേയിൽ തന്നെയല്ല, ഗേറ്റ്‌വേയ്ക്ക് പിന്നിലെ ഹോസ്റ്റിൽ പ്രവർത്തിക്കുമ്പോൾ, ആ അനുമതി തെറ്റായ ട്രാഫിക് പാതയ്ക്കാണ് എഴുതിയത്. പാക്കറ്റ് ഫയർവാളിലേക്ക് അഡ്രസ് ചെയ്തിട്ടില്ല, പ്രാദേശിക പ്രക്രിയയിലേക്ക് എത്തുന്നുമില്ല, അതിനാൽ ഇൻപുട്ട് നിയമങ്ങൾ അത് ഒരിക്കലും കാണുന്നില്ല. പരിഹാരം ഫോർവേഡ് ചെയ്യുന്ന ഫ്ലോയെ ലക്ഷ്യമിടുന്ന റൂട്ട് നിയമമാണ്, അതിന്റെ തെളിവ് ഇതിനകം ലോഗിൽ ഉണ്ട്.

ലക്ഷ്യസ്ഥാനം പ്രാദേശികമാണോ ഫോർവേഡ് ചെയ്തതാണോ എന്ന് തീരുമാനിക്കുക

കേർണൽ കാണുന്ന രീതിയിൽ പാക്കറ്റ് വായിക്കുക. ഗേറ്റ്‌വേയിലെ സേവനത്തിന് എത്തിക്കുന്ന ട്രാഫിക് പ്രാദേശിക ഇൻപുട്ടാണ്. ഗേറ്റ്‌വേ മറ്റൊരു ഹോസ്റ്റിലേക്ക് ഫോർവേഡ് ചെയ്യുന്ന ട്രാഫിക് ഫോർവേഡ് ചെയ്തതാണ്, UFW രണ്ട് പാതകൾക്കും വെവ്വേറെ നിയമക്കൂട്ടങ്ങൾ സൂക്ഷിക്കുന്നു. വ്യത്യാസം ലക്ഷ്യ വിലാസവും റൂട്ട് തിരച്ചിലും തീരുമാനിക്കുന്നു, പാക്കറ്റ് എത്തിയ ഇന്റർഫേസല്ല.

IN, OUT എന്നീ രണ്ട് ഫീൽഡുകളിലും ഒരേ ഇന്റർഫേസ് കാണിക്കുന്ന ലോഗ് വരി ഇപ്പോഴും റൂട്ട് ചെയ്ത പാക്കറ്റിനെ വിവരിക്കാം, കാരണം ഒരു ഉപകരണത്തിൽ നിന്ന് ക്ലയന്റുകളെ അകത്തേക്കും പുറത്തേക്കും കൊണ്ടുപോകുന്ന ടണൽ അതേപോലെയാണ് കാണുന്നത്. ഇന്റർഫേസ് പേരുകളെക്കാൾ വേഗത്തിൽ ലക്ഷ്യ വിലാസം ഈ ചോദ്യം തീർക്കുന്നു. ഒരേ പേര് രണ്ടുതവണ കാണുന്നത് പ്രാദേശിക ഡെലിവറി തെളിയിക്കുന്നില്ല, ഡിപ്ലോയ്മെന്റ് ഒരിക്കലും സൃഷ്ടിക്കാത്ത ഒരു ടണൽ ഇന്റർഫേസ് കെട്ടിച്ചമച്ചാലും സഹായിക്കില്ല.

ഏതെങ്കിലും നിയമം ചേർക്കുന്നതിന് മുമ്പ് ബ്ലോക്ക് വായിക്കുക

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

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

ആദ്യ കമാൻഡ് വിധി അതിന്റെ ഫീൽഡുകളോടെ തിരികെ നൽകുന്നു, രണ്ടാമത്തേത് എന്താണ് ഇതിനകം ലോഡ് ചെയ്തിരിക്കുന്നതെന്നും ഏത് ക്രമത്തിലെന്നും കാണിക്കുന്നു. എന്തെങ്കിലും എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് രണ്ടും വായിക്കുക, കാരണം നിങ്ങളുടെ നിയമത്തിന് മുകളിലുള്ള മുമ്പത്തെ നിരാകരണം വിട്ടുപോയ നിയമമില്ലാതെ തന്നെ അതേ ലക്ഷണം വിശദീകരിക്കുന്നു.

യോജിക്കുന്ന ഏറ്റവും ഇടുങ്ങിയ റൂട്ട് നിയമം എഴുതുക

ഈ ഉദാഹരണത്തിൽ ക്ലയന്റുകൾ 172.20.8.0/24-ൽ നിന്ന് tun0-ലേക്ക് വരുന്നു, സേവനം 8443 പോർട്ടിൽ 10.30.0.15-ൽ കേൾക്കുന്നു, ഗേറ്റ്‌വേ ens5 വഴി പുറത്തുപോകുന്നു. ആ മൂല്യങ്ങൾ ക്ലൗഡ് VPC-യുടെ സ്ഥിരസ്ഥിതി 10.0.0.0/16 അല്ലെങ്കിൽ വീട്ടിലെ 192.168.0.0/16 പോലെ തോന്നാതിരിക്കാൻ തിരഞ്ഞെടുത്തതാണ്, 8443 ഉദാഹരണത്തെ ഗേറ്റ്‌വേയുടെ സ്വന്തം 443 ശ്രോതാവിൽ നിന്ന് അകറ്റി നിർത്തുന്നു.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

മടക്ക പാത അവസ്ഥയോടെ നിലനിർത്തുക

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

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

UFW നിങ്ങൾക്കുവേണ്ടി നടപ്പാക്കാൻ കഴിയാത്തത് പരിശോധിക്കുക

ശരിയായ നിയമത്തിന് ഇപ്പോഴും കേർണൽ ഫോർവേഡിംഗും സേവനത്തിൽ എത്തുന്ന ഒരു റൂട്ടും ആവശ്യമാണ്. ഫയർവാളിനെ രണ്ടാം തവണ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് രണ്ടും ഉറപ്പാക്കുക.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

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

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

അനുബന്ധ ലേഖനങ്ങൾ