UFW നിയമങ്ങൾ ഉപയോഗിച്ച് OpenVPN ഗേറ്റ്വേയെ ഒരു LAN-ൽ പരിമിതപ്പെടുത്തുക

ഒരു ഫയർവാൾ ഫയൽ തുറക്കുന്നതിന് മുമ്പ് അനുമതി തീരുമാനിക്കുക: പ്രാമാണീകരിച്ച ക്ലയന്റുകൾക്ക് ഒരു നിർദ്ദിഷ്ട സബ്നെറ്റിലേക്ക് കണക്ഷനുകൾ തുറക്കാം, ഒരു ക്ലയന്റ് അധിക റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്താലും ഗേറ്റ്വേ മറ്റെല്ലാ ട്രാൻസിറ്റ് പാതയും നിരസിക്കണം. ആ വാക്യമാണ് രൂപകൽപ്പന, താഴെയുള്ള ഓരോ നിയമവും അത് നടപ്പാക്കാൻ ഉള്ളതാണ്. അതിലും വിശാലമായ എന്തെങ്കിലും, ഉദാഹരണത്തിന് മുഴുവൻ സ്വകാര്യ വിലാസ മേഖല, ടണലിലൂടെയുള്ള ഇന്റർനെറ്റ് പുറത്തേക്കുള്ള പോക്ക്, അല്ലെങ്കിൽ സമപീരുകൾ തമ്മിലുള്ള ട്രാഫിക്, സ്വന്തം തീരുമാനം ആവശ്യമുള്ള മറ്റൊരു രൂപകൽപ്പനയാണ്. നിയമങ്ങൾ മനഃപൂർവം വിരസവുമാണ്, കാരണം മിടുക്കുള്ള ഫയർവാൾ എന്നത് പിന്നീട് ആർക്കും ഓഡിറ്റ് ചെയ്യാൻ കഴിയാത്തതാണ്.

ആദ്യം ടോപ്പോളജിയും അനുമതിയും എഴുതുക

ഉദാഹരണം ഉപയോഗിക്കുന്നത് ഉപയോക്തൃ മേഖലയിലെ TUN ഉപകരണത്തിന് എന്ന പേരുള്ള Community OpenVPNtun0 സെർവർ, ക്ലയന്റ് പൂൾ 10.77.0.0/24, കൂടാതെ ഒരു ബന്ധിപ്പിച്ച സബ്നെറ്റ് 192.168.60.0/24 lan0 എന്നിവയിൽ ആണ്. IPv4 ഫോർവേഡിംഗ് ഇപ്പോൾ തന്നെ പ്രവർത്തിക്കുന്നു, LAN-ന് പൂളിലേക്കുള്ള തിരിച്ചുപോക്ക് റൂട്ട് ഇപ്പോൾ തന്നെ ഉണ്ട്, അതിനാൽ ഇവിടെ ഒന്നും അവയ്ക്കിടയിലുള്ള വിവർത്തനത്തെ ആശ്രയിക്കുന്നില്ല.

ഈ ഹോസ്റ്റിലെ ഫയർവാൾ UFW-യുടെ ഉടമസ്ഥതയിലാണ്, ഒരു കണ്ടെയ്നർ നിയമക്കൂട്ടമോ വേറിട്ട nftables പട്ടികയോ മുൻകാല അംഗീകാര പാത ഇടാൻ പാടില്ല. ഫിൽട്ടർ ഒഴിവാക്കുന്ന ഫ്ലോ-ഓഫ്ലോഡ് ഷോർട്ട്കട്ട് കാവൽ ശൃംഖലകളെ അലങ്കാരമാക്കും, അതിനാൽ ഒന്നും സജീവമല്ലെന്ന് ഉറപ്പാക്കുക. OpenVPN-ന്റെ സ്വന്തം client-to-client ഫോർവേഡിംഗ് ഓഫാക്കി വയ്ക്കുക, കാരണം ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ ഫിൽട്ടർ ഒരിക്കലും കടക്കാത്ത സമപീരുകൾ തമ്മിലുള്ള ട്രാഫിക് അതിലൂടെ പരിമിതപ്പെടുത്താൻ കഴിയില്ല. ബാഹ്യ ശ്രോതാവും ഭരണ നിയമങ്ങളും ഉള്ളതുപോലെ തുടരുന്നു, കാരണം ഈ മാറ്റം ഫയർവാൾ മാറ്റിസ്ഥാപിക്കുന്നതിനുപകരം ഡീക്രിപ്റ്റ് ചെയ്ത ടണൽ ട്രാഫിക് നിയന്ത്രിക്കുന്നു.

കാവലുകളെ UFW-യുടെ ആദ്യകാല അംഗീകാരങ്ങൾക്ക് മുമ്പ് നിർത്തുക

ഒരു റൂട്ട് അനുമതിക്ക് ശേഷം നിരസിക്കൽ കർശനമായ അതിർത്തിക്ക് മതിയാകില്ല. സ്റ്റോക്ക് before നിയമങ്ങൾ ഏതെങ്കിലും ഉപയോക്തൃ നിയമം പരിശോധിക്കുന്നതിന് മുമ്പ് സ്ഥാപിത ട്രാഫിക്കും ചില ICMP-യും സ്വീകരിക്കുന്നു, അതിനാൽ കഴിഞ്ഞ ആഴ്ച അനുവദിച്ച ഒരു ഫ്ലോയ്ക്ക് ഇപ്പോഴും അവസ്ഥ ഉള്ളതിനാൽ മാത്രം പുതിയ ലക്ഷ്യ നിയന്ത്രണത്തിന് പുറത്ത് തുടരാം. UFW ഫയലുകൾ ബാക്കപ്പ് ചെയ്യുക, എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് ഒരു ഓഫ്-ബാൻഡ് കൺസോൾ തുറന്ന് സൂക്ഷിക്കുക.

ഫയലിന്റെ *filter വിഭാഗത്തിൽ /etc/ufw/before.rules, നിലവിലുള്ള പ്രഖ്യാപനങ്ങൾക്ക് അടുത്തും ഏതെങ്കിലും നിയമ വരിക്ക് മുമ്പും രണ്ട് ശൃംഖലകൾ പ്രഖ്യാപിക്കുക.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

പ്രഖ്യാപനങ്ങൾക്ക് ശേഷം ഉടനെ, ഇൻപുട്ട്, ഫോർവേഡിംഗ് അനുമതികൾക്ക് മുമ്പ്, അവയിലേക്ക് ചാടി എന്താണ് അനുവദിക്കുന്നതെന്ന് നിർവചിക്കുക.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

വിഭാഗത്തിന്റെ ബാക്കി ഭാഗവും അതിന്റെ COMMIT വരിയും നിലനിർത്തുക. രണ്ടാമത്തെ ഫിൽട്ടർ പട്ടിക ഒട്ടിക്കുകയോ ബന്ധമില്ലാത്ത നിയമങ്ങൾ ഒഴിവാക്കുകയോ ചെയ്യുന്നതാണ് ഫയർവാൾ മാറ്റം തടസ്സമാകുന്ന വഴി, ഫയൽ പ്രധാനമായ ഏക പകർപ്പാകുന്നതിൽ നിന്ന് ഒരു റീബൂട്ട് അകലെയാണ്.

ഓരോ കാവലും എന്ത് അനുവദിക്കുന്നു, എന്ത് നിരസിക്കുന്നു എന്ന് വായിക്കുക

ഉറവിടം പൂളിലും ലക്ഷ്യം ആ ഒരു സബ്നെറ്റും എക്സിറ്റ് ഇന്റർഫേസ് LAN-ഉം പാക്കറ്റ് അതിന്റെ ഫ്ലോയുടെ മൂല ദിശയിലും ആകുമ്പോൾ മാത്രമാണ് ആദ്യ ശൃംഖല പ്രോസസ്സിംഗ് തുടരുന്നത്. ടണലിൽ നിന്ന് വരുന്ന ബാക്കിയെല്ലാം ഉപേക്ഷിക്കപ്പെടുന്നു, പൂളിന് പുറത്തുള്ള ഉറവിടവും അനുവദിച്ച സബ്നെറ്റിന് അപ്പുറമുള്ള ഏത് ലക്ഷ്യവും ഉൾപ്പെടെ.

സമപീര പാക്കറ്റ് tun0 ലേക്ക് കയറി അതിൽ നിന്ന് പുറത്തുപോകുന്നു, അതിനാൽ ലക്ഷ്യ പരിശോധനയിൽ എത്തുന്നതിന് മുമ്പ് തന്നെ അത് LAN ഇന്റർഫേസ് പരിശോധനയിൽ പരാജയപ്പെടുന്നു. LAN-ൽ നിന്ന് ക്ലയന്റുകളിലേക്കുള്ള പുതിയ കണക്ഷനുകളും മറുപടി ദിശ പരിശോധനയിൽ പരാജയപ്പെടുന്നു, ഇത് സ്വതേ വിപരീത കോൾബാക്ക് പാത അടയ്ക്കുന്നു.

RETURN ലക്ഷ്യം സാധാരണ UFW നയം പ്രാബല്യത്തിൽ നിർത്തുന്നു. ഈ ശൃംഖലകൾ ഫിൽട്ടർ ചെയ്യുന്നു, അടുത്തതായി ചേർക്കുന്ന റൂട്ട് അനുമതി അതിജീവിച്ച പാക്കറ്റ് സ്വീകരിക്കുമോ എന്ന് ഇപ്പോഴും തീരുമാനിക്കുന്നു. ആ വേർതിരിവാണ് പിന്നീട് അനുവദിച്ച സബ്നെറ്റ് ഒരിടത്ത് മാറ്റാൻ അനുവദിക്കുന്നത്. കാവലുകൾ പാക്കറ്റുകൾ നേരിട്ട് സ്വീകരിച്ചിരുന്നെങ്കിൽ എല്ലാ ഭാവി നിയമവും രണ്ടുതവണ ചേർക്കേണ്ടിവരുമായിരുന്നു.

സബ്നെറ്റിന് അധികാരം നൽകി വശത്തെ വാതിലുകൾ അടയ്ക്കുക

ആദ്യം റൂട്ട് അനുമതി പ്രിവ്യൂ ചെയ്യുക, പിന്നീട് പ്രയോഗിക്കാൻ പ്രിവ്യൂ ഫ്ലാഗ് നീക്കുക: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. അതിനുശേഷം ഉപയോക്തൃ നിയമങ്ങളുടെ ക്രമം പരിശോധിക്കുക, കാരണം മുൻകാല നിരസിക്കൽ പിന്നീടുള്ള അനുമതിയെ ഇപ്പോഴും തോൽപ്പിക്കുന്നു. മുഴുവൻ സബ്നെറ്റിനുള്ള അനുമതിയും തെറ്റായ രൂപമാണ്, എപ്പോൾ ഒരു ഹോസ്റ്റിന്റെ HTTPS പോർട്ട് മാത്രം എത്തിച്ചേരാവുന്നതാകണം എന്നുണ്ടെങ്കിൽ.

ഇൻപുട്ട് ഉപേക്ഷിക്കൽ എന്ത് ചെയ്യുന്നു എന്ന് ശ്രദ്ധിക്കുക: ടണൽ ക്ലയന്റുകൾക്ക് ഗേറ്റ്വേയിലെ ഒരു സേവനത്തിലും എത്താൻ കഴിയില്ല, അതിന്റെ LAN വിലാസത്തിൽ ബന്ധിച്ച DNS ശ്രോതാവ് ഉൾപ്പെടെ. അവിടെ DNS ഹോസ്റ്റ് ചെയ്യാൻ ഉപേക്ഷിക്കലിന് മുമ്പ് ബോധപൂർവമായ ഒരു ഒഴിവാക്കലും പരിഷ്കരിച്ച അനുമതി കരാറും വേണം. UFW IPv6 കൈകാര്യം ചെയ്യുന്നുണ്ടെങ്കിൽ, tun0 എന്നതിന് before6.rules ഫയലിലും അനുയോജ്യമായ ഉപേക്ഷിക്കലുകൾ ചേർക്കുക, കാരണം IPv4 ലക്ഷ്യ പട്ടിക IPv6 പാക്കറ്റുകളെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

പ്രിവ്യൂ അല്ല, ലോഡ് ചെയ്ത നയം പരിശോധിക്കുക

റീലോഡ് പ്രിവ്യൂ ചെയ്യുക, അറ്റകുറ്റപ്പണി വിൻഡോയിൽ അത് പ്രയോഗിക്കുക, തത്സമയ നിയമക്കൂട്ടം വായിക്കുക.

sudo ufw --dry-run reload
sudo ufw show raw

ടണൽ കാവലുകൾ സ്വതേയുള്ള സ്റ്റേറ്റ്, ICMP അനുമതികൾക്ക് മുമ്പ് പ്രത്യക്ഷപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക. സാധാരണ ufw status കൈകൊണ്ട് തിരുത്തിയ before നിയമങ്ങൾ കാണിക്കുന്നില്ല, അതിനാൽ പ്രവർത്തകർ ഒരു നിയമം ഇല്ലെന്ന് അനുമാനിക്കുന്നു, എന്നാൽ അത് യഥാർത്ഥത്തിൽ ലോഡ് ചെയ്തിട്ടുണ്ട്. ഒരു ഭാഗം തിരയുന്നതിനുപകരം അസംസ്കൃത പട്ടിക മുകളിൽ നിന്ന് താഴേക്ക് വായിക്കുക. കാവലുകൾ സ്റ്റേറ്റ് അനുമതിക്ക് ശേഷം പ്രത്യക്ഷപ്പെടുന്നുവെങ്കിൽ, ഫയൽ നിർദ്ദേശിക്കുന്നത് അതിർത്തി ചെയ്യുന്നില്ല.

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

നിയമങ്ങൾക്കൊപ്പം പരിധികളും രേഖപ്പെടുത്തുക: ഇത് ട്രാൻസിറ്റ് പരിമിതപ്പെടുത്തുന്നു, മറ്റൊന്നുമില്ല. ഇത് ഒരു ക്ലയന്റിനെ സ്വന്തം ഇന്റർനെറ്റ് കണക്ഷൻ ഉപയോഗിക്കുന്നതിൽ നിന്ന് തടയുന്നില്ല, അനുവദിച്ച LAN ഹോസ്റ്റ് ട്രാഫിക് കൂടുതൽ കൈമാറുന്നതിൽ നിന്ന് തടയുന്നില്ല, അനുവദിച്ച സേവനങ്ങൾക്കുള്ളിലെ പ്രാമാണീകരണത്തിന് പകരമാകുന്നുമില്ല.