SSD Nodes Learn 🎉 VPS $5.50/மாதம் முதல்
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-08-13

Rocky Linux மற்றும் AlmaLinux-ல் firewalld அமைப்பது

Rocky அல்லது AlmaLinux VPS-ல் SSH மற்றும் Web port-களை எவ்வாறு திறப்பது என்பதை அறியுங்கள். --permanent flag-ன் முக்கியத்துவம் மற்றும் firewalld zones-களை கையாள்வது எப்படி?

firewalld என்றால் என்ன, Rocky மற்றும் AlmaLinux ஏன் அதை வழங்குகின்றன

firewalld என்பது Rocky Linux, AlmaLinux மற்றும் பிற Red Hat Enterprise Linux (RHEL) மறுபதிப்புகளில் இயல்பாக நிறுவப்பட்ட firewall மேலாளர் ஆகும். இது பாக்கெட்டுகளை நேரடியாக ஆய்வு செய்வதில்லை. இது ஒரு சேமிக்கப்பட்ட உள்ளமைவை (configuration) பராமரித்து, அந்த உள்ளமைவை nftables விதிகளாக மாற்றுகிறது. firewall-cmd என்ற ஒரே கட்டளையைப் பயன்படுத்தி, server இயங்கிக்கொண்டிருக்கும்போதே மாற்றங்களைச் செய்ய முடியும்.

Ubuntu VPS-ல் ufw எவ்வாறு செயல்படுகிறது என்பது உங்களுக்கு ஏற்கனவே தெரிந்திருந்தால், இதன் பணியையும் நீங்கள் புரிந்துகொள்ளலாம். ufw-ல் இல்லாத இரண்டு கூடுதல் அம்சங்களை firewalld வழங்குகிறது. முதலாவது zones: பாக்கெட்டுகள் வகைப்படுத்தப்படும் ஒரு பெயரிடப்பட்ட கொள்கை (named policy). இரண்டாவது, நேரடி விதிகளுக்கும் (live rules) சேமிக்கப்பட்ட விதிகளுக்கும் (saved rules) இடையிலான வேறுபாடு; இதுதான் --permanent flag ஆகும், மேலும் இதுவே இந்த கருவியில் குழப்பத்தை ஏற்படுத்தும் முக்கிய காரணியாகும்.

கீழே கொடுக்கப்பட்டுள்ள அனைத்தும் உங்கள் சொந்த server-ல் நீங்கள் இயக்க வேண்டிய கட்டளைகள் ஆகும். ஒவ்வொரு மாற்றத்தையும் மற்றொரு கணினியிலிருந்து சோதிக்கவும், ஏனெனில் server-ல் சரியாகத் தோன்றும் ஒரு விதி, இணையத்திலிருந்து பார்க்கும்போது தவறாக இருக்கலாம்.

வேறெதையும் செய்வதற்கு முன் SSH-ஐத் திறக்கவும்

பெரும்பாலான Rocky மற்றும் AlmaLinux நிறுவல்களில் firewalld ஏற்கனவே இருக்கும் மற்றும் இயங்கிக்கொண்டிருக்கும், மேலும் அதன் இயல்புநிலை கட்டமைப்பு SSH-ஐ அனுமதிக்கிறது. சில minimal cloud images-ல் இது நீக்கப்பட்டிருக்கலாம். எனவே, ஊகிப்பதற்குப் பதிலாகச் சரிபார்க்கவும்.

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --state

firewall-cmd --state கட்டளையானது running-ஐ அச்சிடும். service நிறுத்தப்பட்டிருந்தால், மற்ற அனைத்து firewall-cmd அழைப்புகளும் FirewallD is not running என்று பதிலளித்து non-zero exit code-ஐத் தரும். ஒரு கட்டளை எந்த மாற்றத்தையும் செய்யவில்லை என்று தோன்றினால், முதலில் இதையே சரிபார்க்க வேண்டும்.

தற்போது அனுமதிக்கப்பட்டுள்ளவை என்னவென்று இப்போது பார்க்கவும்.

sudo firewall-cmd --list-all

உண்மையான output-ல் இன்னும் சில வரிகள் இருக்கும். அவற்றில் முக்கியமானவை இவை:

public (active)
  target: default
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  rich rules:

services: வரியில் உள்ள ssh தான் உங்கள் session தொடர்ந்து இயங்குவதற்குக் காரணம். அது இல்லையென்றால், வேறெந்த மாற்றத்தைச் செய்வதற்கு முன்பும் அதைச் சேர்க்கவும். ஏனெனில், SSH விதி இல்லாமல் firewall-ஐத் தொடங்கினால், உங்கள் session துண்டிக்கப்பட்டு, மீண்டும் உள்ளே நுழைய முடியாமல் போகும்.

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

target: default என்பது, எதனுடனும் பொருந்தாத packet-கள் ICMP (internet control message protocol) host-prohibited பதிலுடன் நிராகரிக்கப்படும் என்று பொருள். இதனால், மூடப்பட்ட port-ஐ அணுகும் client-க்கு உடனடியாக No route to host என்று காட்டும். target-ஐ DROP என்று மாற்றினால், server எந்தப் பதிலும் அளிக்காது; இதனால் scanners timeout ஆகும் வரை காத்திருக்கும்.

sudo firewall-cmd --permanent --zone=public --set-target=DROP
sudo firewall-cmd --reload

அதை இயக்குவதற்கு முன் அதன் விளைவை அறிந்துகொள்ளுங்கள்: DROP அமைப்பானது server ping-க்கு பதிலளிப்பதையும் நிறுத்திவிடும், எனவே உங்கள் monitoring அமைப்பும் எந்தத் தகவலையும் பெறாது.

எனது விதி ஏன் மறைந்துவிட்டது? --permanent flag

firewalld ஒரே நேரத்தில் இரண்டு உள்ளமைவுகளை (configurations) வைத்திருக்கிறது. runtime உள்ளமைவு என்பது கர்னல் (kernel) தற்போது அமல்படுத்தும் விதியாகும். permanent உள்ளமைவு என்பது /etc/firewalld/zones/public.xml-ல் சேமிக்கப்பட்டு, reload அல்லது reboot-க்கு பிறகு மீண்டும் செயல்பாட்டுக்கு வருவது ஆகும்.

--permanent இல்லாமல் ஒரு கட்டளையை இயக்கினால், அது runtime-ஐ மட்டுமே மாற்றும். இது உடனடியாகச் செயல்படும், ஆனால் அடுத்த reload அல்லது boot-ன் போது மறைந்துவிடும். --permanent-உடன் ஒரு கட்டளையை இயக்கினால், அது கோப்பில் எழுதும், ஆனால் தற்போது இயங்கிக்கொண்டிருக்கும் எதையும் மாற்றாது; எனவே நீங்கள் reload செய்யும் வரை port மூடியே இருக்கும். இவை இரண்டுமே பிழைகள் அல்ல. கட்டளை இரண்டு முறைகளிலும் success என்று வெளியீட்டைக் காட்டுவதால், பயனர்கள் குழப்பமடைகிறார்கள்.

ஒவ்வொரு முறையும் இரண்டு கட்டளைகளையும் சேர்த்துப் பயன்படுத்தவும்.

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload

நீங்கள் இரண்டு உள்ளமைவுகளையும் சரிபார்க்கலாம்; நீங்கள் செய்த இரண்டு தவறுகளில் எது என்பதை அறிய இதுவே விரைவான வழியாகும்.

sudo firewall-cmd --list-services
sudo firewall-cmd --permanent --list-services

முதல் கட்டளை தற்போது இயங்கும் விதிகளையும், இரண்டாவது கட்டளை சேமிக்கப்பட்ட விதிகளையும் காட்டும். தற்போது இயங்கும் விதிகளில் ஒரு service இருந்து, சேமிக்கப்பட்ட விதிகளில் அது இல்லை என்றால், அடுத்த reload-ன் போது அந்த விதி நீங்கிவிடும். சேமிக்கப்பட்ட விதிகளில் ஒரு service இருந்து, தற்போது இயங்கும் விதிகளில் அது இல்லை என்றால், நீங்கள் reload செய்ய மறந்துவிட்டீர்கள் என்று அர்த்தம். sudo firewall-cmd --runtime-to-permanent தற்போது இயங்கும் அனைத்து விதிகளையும் சேமிக்கப்பட்ட கோப்பிற்கு நகலெடுக்கும்; இது சோதனைகளுக்குப் பிறகு மிகவும் பயனுள்ளதாக இருக்கும்.

--reload connection tracking நிலையைத் தக்கவைக்கும், எனவே உங்கள் SSH session துண்டிக்கப்படாது. --complete-reload கர்னல் தொகுதிகளையும் (kernel modules) மீண்டும் ஏற்றும், இதனால் அந்த நிலை இழக்கப்படும்; இது பொதுவாக உங்கள் SSH session உட்பட அனைத்து இணைப்புகளையும் துண்டித்துவிடும். எனவே சாதாரண reload-ஐப் பயன்படுத்தவும்.

இதில் ஒரு பாதுகாப்பு அம்சம் உள்ளது. ஒரு runtime விதி தானாகவே காலாவதியாகும்படி அமைக்கலாம்.

sudo firewall-cmd --add-service=http --timeout=5m

இந்த விதி ஐந்து நிமிடங்களுக்குப் பிறகு தானாகவே நீங்கிவிடும். இதை --permanent-உடன் இணைக்க முடியாது, அதுவே இதன் நோக்கம்: நீங்கள் உறுதியாக இல்லாத ஒரு மாற்றத்தைச் சோதிக்க இது பயன்படுகிறது. பழைய பாதுகாப்பு முறையே சிறந்தது. விதிகளை மாற்றும்போது இரண்டாவது SSH session-ஐத் திறந்து வைத்திருக்கவும்; புதிய விதிகள் சரியாகச் செயல்படுகின்றன என்பதை உறுதி செய்த பின்னரே அதை மூடவும்.

Zones, மற்றும் ஒரு VPS-ல் default zone மட்டும் ஏன் முக்கியமானது

Zone என்பது ஒரு குறிப்பிட்ட நம்பகத்தன்மை (trust level) கொண்ட அனுமதிகளின் தொகுப்பாகும். firewalld ஒவ்வொரு உள்வரும் packet-ஐயும் ஏதேனும் ஒரு zone-க்குள் வகைப்படுத்தும். இது முதலில் packet-ன் source address-ஐ ஒவ்வொரு zone-ன் sources: பட்டியலுடனும் ஒப்பிடும். எதுவும் பொருந்தவில்லை என்றால், அந்த packet எந்த interface வழியாக வருகிறதோ, அந்த interface எந்த zone-உடன் இணைக்கப்பட்டுள்ளதோ அதைப் பயன்படுத்தும். ஒரு interface எந்த zone-உடனும் இணைக்கப்படவில்லை என்றால், packet default zone-க்குச் செல்லும்.

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --get-active-zones

ஒரே ஒரு network interface கொண்ட VPS-ல், முதல் விடை எப்போதும் public ஆகத்தான் இருக்கும், அதுவே நீங்கள் பயன்படுத்தும் ஒரே zone ஆகும். --zone= argument இல்லாத firewall-cmd கட்டளைகள் default zone-ல் செயல்படும், இதனால்தான் இந்த வழிகாட்டியில் உள்ள அனைத்து குறுகிய கட்டளைகளும் zone-ஐக் குறிப்பிடாமலேயே வேலை செய்கின்றன.

ஒரு மதிய நேரத்தை வீணடிக்கும் தோல்வி இதோ. உங்கள் interface வேறொரு zone-உடன் இணைக்கப்பட்டிருந்தால், நீங்கள் சேர்க்கும் விதிகள் public-ல் சேரும், ஆனால் traffic வேறொரு இடத்தில் கையாளப்படும். இதனால் நீங்கள் சேர்க்கும் எந்த விதியும் வேலை செய்யாது, எந்த எச்சரிக்கையும் வராது. --get-active-zones அந்த இணைப்பைக் காட்டும்:

public
  interfaces: eth0

interface வேறொரு zone பெயரின் கீழ் இருந்தால், --zone=-ஐப் பயன்படுத்தி உங்கள் விதிகளை அங்கு எழுதவும் அல்லது அந்த interface-ஐ மாற்றவும்.

sudo firewall-cmd --permanent --zone=public --change-interface=eth0
sudo firewall-cmd --reload

Rocky மற்றும் AlmaLinux-ல் NetworkManager தான் interface-களை நிர்வகிக்கிறது, connection தொடங்கும் போது அது zone-ஐ மீண்டும் உறுதிப்படுத்தும். எனவே, reboot செய்தாலும் உங்கள் மாற்றங்கள் மாறாமல் இருக்க, அங்கேயும் இதை அமைக்கவும். முதல் கட்டளையிலிருந்து connection பெயரைப் பெறவும், ஏனெனில் அது பெரும்பாலும் device பெயராக இருக்காது.

sudo nmcli connection show
sudo nmcli connection modify "System eth0" connection.zone public

Source matching என்பது interface matching-ஐ விட முன்னுரிமை பெறும், இதன் மூலமே ஒரு குறிப்பிட்ட address-க்கு மட்டும் மாறுபட்ட policy-ஐ வழங்க முடியும். உள்ளமைக்கப்பட்ட trusted zone அனைத்தையும் அனுமதிக்கும்.

sudo firewall-cmd --permanent --zone=trusted --add-source=203.0.113.10/32
sudo firewall-cmd --reload

அதில் கவனமாக இருக்கவும். அது அந்த address-க்கு server-ல் உள்ள அனைத்து port-களையும் திறந்துவிடும், நீங்கள் தனிப்பட்டதாகக் கருதிய database-ம் இதில் அடங்கும். ஒரு குறிப்பிட்ட host-க்கு அனுமதி அளிப்பதற்குப் பதிலாக, ஒரு port-க்கு மட்டும் அனுமதி தேவைப்பட்டால் rich rule-ஐப் பயன்படுத்தவும்.

firewalld service என்றால் என்ன?

ஒரு service என்பது XML கோப்பாக வழங்கப்பட்ட, பெயரிடப்பட்ட ports தொகுப்பாகும். --add-service=https என்பது 443/tcp-ஐத் திறக்கிறது, ஏனெனில் https எதைக் குறிக்கிறது என்பதை /usr/lib/firewalld/services/https.xml வரையறுக்கிறது.

sudo firewall-cmd --get-services
sudo firewall-cmd --info-service=https

பெயருக்குப் பின்னால் மறைந்துள்ள ports-ஐக் காண --info-service கட்டளையைப் பயன்படுத்தவும்:

https
  ports: 443/tcp

ஒரு service பெயர் இருக்கும்போது அதையே பயன்படுத்தவும். ஆறு மாதங்களுக்குப் பிறகு --list-all கோப்பைப் பார்க்கும்போது இது தெளிவாக இருக்கும். மேலும், Cockpit போன்ற தொகுப்புகள் அவற்றின் சொந்த service கோப்புகளை நிறுவுகின்றன. வரையறை இல்லாத எதற்கும் --add-port கட்டளையைப் பயன்படுத்தவும்.

கவனிக்க வேண்டிய இடைவெளி: ssh service என்பது 22/tcp-ஐ மட்டுமே குறிக்கும். நீங்கள் server-ல் SSH access-ஐ பலப்படுத்துதல் என்பதன் மூலம் SSH-ஐ வேறொரு port-க்கு மாற்றியிருந்தால், --add-service=ssh நீங்கள் உண்மையில் பயன்படுத்தும் port-ஐத் திறக்காது.

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

RHEL-ஐ மீண்டும் கட்டமைக்கும்போது, அந்தத் கதவில் இரண்டாவது பூட்டு இருக்கும். SELinux (security-enhanced Linux) port எண்களுக்கு லேபிள்களை இடுகிறது. அதன் லேபிள்களுக்கு வெளியே உள்ள ஒரு port-ல் sshd bind செய்ய அனுமதிக்கப்படாது. அப்போது அது தொடங்க மறுக்கும், log கோப்பில் error: Bind to port 2222 on 0.0.0.0 failed: Permission denied. என்று காட்டும். முதலில் அந்த port-க்கு லேபிளிடுங்கள்.

sudo dnf install -y policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2222

தற்போது எவை திறந்த நிலையில் உள்ளன என்பதை எவ்வாறு பார்ப்பது?

sudo firewall-cmd --list-all
sudo firewall-cmd --list-rich-rules
sudo nft list table inet firewalld | head -n 40

முதல் இரண்டு கட்டளைகளும் firewalld எதைச் சரியாகக் கருதுகிறது என்பதைத் தெரிவிக்கின்றன. மூன்றாவது கட்டளை, firewalld-ன் கட்டுப்பாட்டில் உள்ள table-ல் kernel உண்மையில் வைத்துள்ள விதிகளைப் படிக்கிறது. இவை அனைத்தும் ஒன்றாக இருக்க வேண்டும்.

இவை எதுவும் முழுமையான ஆதாரமல்ல. மற்றொரு கணினியிலிருந்து சோதிக்கவும்:

nc -zv 203.0.113.20 443

இந்தச் சோதனையை server-லேயே இயக்க வேண்டாம். loopback interface-க்கு வரும் அனைத்தையும் firewalld அனுமதிக்கும், எனவே உங்கள் விதிகள் என்னவாக இருந்தாலும் curl http://localhost:8080 வெற்றி பெறும். அந்தச் சோதனை service இயங்குகிறது என்பதை மட்டுமே உறுதிப்படுத்தும். அது firewall-ஐப் பற்றி எதையும் தெரிவிக்காது.

வலை போர்ட்டை (web port) அனுமதித்தல்

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

கடைசியாக இயக்கிய கட்டளை, ஏற்கனவே இருந்தவற்றுடன் http https-ஐயும் பட்டியலிட வேண்டும். தளம் இன்னும் பதிலளிக்கவில்லை என்றால், உங்கள் சிக்கல் firewall-ல் இல்லாமல் இருக்கலாம். ஒரு விதி (rule) பாக்கெட்டை அனுமதிக்கிறது. ஆனால், ஒரு process அதற்காகக் காத்திருக்க (listening) வேண்டும்.

sudo ss -tlnp

0.0.0.0:443 அல்லது *:443 எனக் காட்டப்படும் socket, எந்த முகவரியிலிருந்தும் வரும் இணைப்புகளை ஏற்கும். 127.0.0.1:443 எனக் காட்டப்படுவது loopback-ல் மட்டுமே பதிலளிக்கும்; எந்த firewall விதியும் அதை வெளியிலிருந்து அணுகக்கூடியதாக மாற்ற முடியாது. Linux-ல் போர்ட்கள் மற்றும் listening sockets அந்த வேறுபாட்டைப் பற்றி விரிவாக விளக்குகிறது.

ஒரு port-ஐ மீண்டும் மூடுவது எப்படி?

sudo firewall-cmd --permanent --remove-service=http
sudo firewall-cmd --reload

இங்கும் --permanent விதி பொருந்தும், இது இந்த திசையில் இன்னும் தீவிரமாகச் செயல்படும். ஒரு service-ஐ runtime-லிருந்து மட்டும் நீக்கினால் port மூடப்பட்டது போலத் தோன்றும், ஆனால் அடுத்த முறை reload அல்லது reboot செய்யும்போது, சேமிக்கப்பட்ட கோப்பிலிருந்து அது மீண்டும் திறக்கப்படும். இது நீங்கள் கவனிக்காத ஒரு பாதுகாப்பு ஓட்டையாகும், ஏனெனில் நீங்கள் செய்த சரிபார்ப்பு (check) வெற்றிகரமாக முடிந்திருக்கும்.

அங்கு இல்லாத ஒன்றை நீக்க முயற்சித்தால் Warning: NOT_ENABLED: http என்று காட்டும், ஆனாலும் அது 0 என்ற exit code-ஐயே தரும். ஒரே விஷயத்தை இரண்டு முறை சேர்த்தால் Warning: ALREADY_ENABLED: http என்று காட்டும். இவை இரண்டுமே பாதுகாப்பானவை. பிழையான பெயரை உள்ளிட்டால் நிலைமை வேறு: Error: INVALID_SERVICE என்பது firewalld-ல் அந்தப் பெயரில் எந்த வரையறையும் இல்லை என்பதையும், எவ்வித மாற்றமும் செய்யப்படவில்லை என்பதையும் குறிக்கிறது.

உங்கள் --list-all பட்டியலில் cockpit என்று காட்டப்பட்டு, நீங்கள் 9090 port-ல் இயங்கும் Cockpit web console-ஐப் பயன்படுத்தவில்லை என்றால், அதை நீக்கிவிடவும். திறந்திருக்கும் ஒவ்வொரு port-ம் நீங்கள் தொடர்ந்து patch செய்து பராமரிக்க வேண்டிய ஒரு service ஆகும்.

ஒரு குறிப்பிட்ட source address-க்கு மட்டும் port-ஐக் கட்டுப்படுத்துதல்

Plain service name மூலம் உங்கள் தேவையை விளக்க முடியாதபோது, Rich rules பயன்படுத்தப்படுகின்றன. SSH-ஐ ஒரு அலுவலக முகவரிக்கு மட்டும் கட்டுப்படுத்த இரண்டு கட்டளைகள் தேவை; இரண்டாவது கட்டளையைத்தான் பலரும் மறந்துவிடுகிறார்கள்.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" service name="ssh" accept'
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Zone என்பது அனுமதிகளின் தொகுப்பு; இது முதல் பொருத்தத்துடன் நின்றுவிடும் வரிசைப்படுத்தப்பட்ட பட்டியல் அல்ல. Rich rule ஒரு குறிப்பிட்ட முகவரிக்கு மட்டும் 'accept' அனுமதியைச் சேர்க்கிறது. இது யாரையும் தடுக்காது. ssh என்பது இன்னும் services: வரியில் இருப்பதால், ஒட்டுமொத்த இணையமும் port 22-ஐ அணுக முடியும்; இந்த rich rule-ஆல் எந்த மாற்றமும் ஏற்படாது. பரவலான அனுமதியை நீக்கினால் மட்டுமே, குறுகிய வரம்பு கொண்ட விதி செயல்படும்.

Service name இல்லாத port-க்கு, service name-க்கு பதிலாக port எண்ணையே குறிப்பிடவும்.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port port="5432" protocol="tcp" accept'

அதிகப்படியான நெட்வொர்க் போக்குவரத்தைத் தவிர்க்கவும், பதிவுகளைச் சேமிக்கவும், 'action'-க்கு முன்னால் 'log' element-ஐச் சேர்க்கவும். Rich rule மொழியின் கட்டமைப்பு இந்த வரிசையையே எதிர்பார்க்கிறது.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" log prefix="fw-drop " level="info" limit value="3/m" drop'
sudo firewall-cmd --reload
sudo journalctl -k -g fw-drop

limit மதிப்பு, அதிகப்படியான பாக்கெட்டுகள் journal-ஐ நிரப்புவதைத் தடுக்கிறது. SSH-ஐ ஒரு குறிப்பிட்ட முகவரிக்கு மட்டும் கட்டுப்படுத்தும் முன், அந்த முகவரி நிலையானது என்பதை உறுதிப்படுத்தவும். மாறும் IP முகவரி கொண்ட வீட்டு இணைய இணைப்பைப் பயன்படுத்தினால், IP மாறும் நாளில் நீங்கள் வெளியேற்றப்படுவீர்கள். எனவே, உங்கள் service provider வழங்கும் console access சரியாகச் செயல்படுகிறதா என்பதை முதலில் சோதித்துக்கொள்ளவும்.

ufw கட்டளைகள் மற்றும் அவற்றுக்கு இணையான firewall-cmd கட்டளைகள்

ஒரே பணிகள், வெவ்வேறு கருவிகள். ஒவ்வொரு --permanent வரியும் ஒரு sudo firewall-cmd --reload-ஐத் தொடர்ந்து வர வேண்டும், இது போன்ற ஒரு பட்டியலில் காட்ட முடியாத ஒரே விஷயம் இதுதான்.

  • sudo ufw enable என்பது sudo systemctl enable --now firewalld ஆக மாறுகிறது
  • sudo ufw disable என்பது sudo systemctl disable --now firewalld ஆக மாறுகிறது
  • sudo ufw status verbose என்பது sudo firewall-cmd --list-all ஆக மாறுகிறது
  • sudo ufw allow OpenSSH என்பது sudo firewall-cmd --permanent --add-service=ssh ஆக மாறுகிறது
  • sudo ufw allow 443/tcp என்பது sudo firewall-cmd --permanent --add-port=443/tcp ஆக மாறுகிறது
  • sudo ufw delete allow 443/tcp என்பது sudo firewall-cmd --permanent --remove-port=443/tcp ஆக மாறுகிறது
  • sudo ufw allow from 203.0.113.10 to any port 22 என்பது மேலே காட்டப்பட்டுள்ள rich rule ஆக மாறுகிறது
  • sudo ufw reload என்பது sudo firewall-cmd --reload ஆக மாறுகிறது
  • sudo ufw default deny incoming என்பது public zone செயல்படும் விதமாகும், மேலும் --set-target=DROP என்பது அதன் அமைதியான (silent) பதிப்பாகும்
  • sudo ufw logging on என்பது sudo firewall-cmd --set-log-denied=all ஆக மாறுகிறது

ஒரு முக்கியமான வித்தியாசத்தை தெளிவாகக் குறிப்பிடுவது அவசியம். ufw ஒரு எண்ணிடப்பட்ட பட்டியலைப் பராமரிக்கிறது, அதில் நீங்கள் முதல் இடத்தில் ஒரு விதியைச் சேர்க்கலாம். firewalld-ல் விதி எண்கள் கிடையாது, எனவே "இந்த விதியை முதலில் வைக்கவும்" என்பதற்கு அங்கு அர்த்தமில்லை. இரண்டு firewalld உள்ளீடுகள் ஒன்றுக்கொன்று முரணாகத் தோன்றினால், பொதுவான (broad) accept விதியே வெற்றி பெறும், ஏனெனில் அந்தத் தொகுப்பில் எதையும் மறுக்கும் (deny) விதி இல்லை. அந்தப் பொதுவான உள்ளீட்டை நீங்களே நீக்க வேண்டும்.

எனது firewall மூடப்பட்ட நிலையில் இருக்கும்போது, Docker container எப்படி அணுக முடிகிறது?

ஏனெனில், publish செய்யப்பட்ட container port-ஆனது உங்கள் zone கட்டுப்படுத்தும் firewall பகுதிக்குச் செல்வதில்லை. docker run -d -p 8080:80 nginx, Docker-ஐ அதன் சொந்த NAT (network address translation) மற்றும் forwarding விதிகளை எழுதச் சொல்கிறது. 8080 port-க்கு வரும் ஒரு packet மாற்றியமைக்கப்பட்டு container-க்கு அனுப்பப்படுகிறது; எனவே அது host-க்கு வழங்கப்படாமல், forward செய்யப்படுகிறது. உங்கள் zone-ல் உள்ள services: மற்றும் ports: வரிகள் host-க்கு வழங்கப்படும் packet-களைக் கட்டுப்படுத்துகின்றன. Docker-ன் விதிகள் forward பாதையைக் கட்டுப்படுத்துகின்றன, அவை அவற்றை ஏற்றுக்கொள்கின்றன.

இதன் விளைவாக, sudo firewall-cmd --list-all கட்டளையில் 8080 port காட்டப்படாது, ஆனால் மற்றொரு machine-லிருந்து nc -zv 203.0.113.20 8080 மூலம் இணைக்க முடியும். Docker என்ன நிறுவியுள்ளது என்பதைப் பார்க்கவும்:

sudo iptables -t nat -L DOCKER -n

இதற்கான தீர்வு publish flag-ல் உள்ளது. Port-ஐ loopback-ல் bind செய்து, அதற்கு முன்னால் ஒரு reverse proxy-ஐ அமைக்கவும்.

docker run -d -p 127.0.0.1:8080:80 nginx

இப்போது container அந்த server-ல் curl http://127.0.0.1:8080-க்கு மட்டுமே பதிலளிக்கும், வெளியிலிருந்து எதற்கும் பதிலளிக்காது. Ubuntu பயனர்களும் இதே சிக்கலைச் சந்திக்கின்றனர், இது why Docker containers publish ports straight past ufw என்பதில் விவரிக்கப்பட்டுள்ளது. Rocky மற்றும் AlmaLinux-ன் base repositories-ல் உள்ள Rootful Podman-ம் அதே NAT அணுகுமுறையில்தான் port-களை publish செய்கிறது, எனவே zone list-ஐ மட்டும் நம்பாமல் மற்றொரு machine-லிருந்து சோதிக்கவும்.

Reboot-க்கு பிறகும் செயல்பட வைத்தல் மற்றும் நீங்கள் காணக்கூடிய பிழைகள்

sudo systemctl is-enabled firewalld
sudo systemctl status firewalld

enabled மற்றும் active (running) ஆகியவை உங்களுக்குத் தேவையானவை. இயங்கிக்கொண்டிருக்கும் ஆனால் enable செய்யப்படாத firewall, முதல் reboot வரை மட்டுமே உங்களைப் பாதுகாக்கும். புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற பட்டியலில், SSH keys மற்றும் updates-க்கு அடுத்ததாக இந்தச் சரிபார்ப்பைச் சேர்க்க வேண்டும்.

Raw nftables கட்டளைகளும் firewalld-ம் ஒன்றிணைந்து செயல்படாது. firewalld, inet firewalld என்ற அட்டவணையைத் தன் கட்டுப்பாட்டில் வைத்திருக்கும். sudo nft flush ruleset அதை நீக்கிவிட்டால், server அனைத்துத் தொடர்புகளுக்கும் திறந்துவிடும். ஆனாலும், firewall-cmd --list-all உங்கள் கட்டளைகளைக் காட்டும்; ஏனெனில், kernel-ல் உள்ளதை விட, தான் என்ன நினைக்கிறதோ அதையே firewalld அறிக்கையாகத் தரும். sudo firewall-cmd --reload விதிகளை மீண்டும் நிறுவும். விதிகளை firewall-cmd மூலம் எழுதினால் மட்டுமே, reload செய்த பிறகு அவை மீண்டும் செயல்படும்.

ஒரே server-ல் இரண்டு firewall மேலாளர்கள். firewalld-க்கு அருகில் ufw அல்லது iptables-services-ஐ நிறுவுவது, ஒன்றுக்கொன்று தெரியாமல் விதிகளை எழுதும் இரண்டு நிரல்களை உருவாக்குவதாகும். கடைசியாக எந்த service தொடங்குகிறதோ அதுவே வெற்றி பெறும். ஏதேனும் ஒன்றை மட்டும் தேர்ந்தெடுக்கவும். Rocky மற்றும் AlmaLinux-ல், distribution ஆதரவு கொண்ட firewalld-ஐப் பயன்படுத்துவதே சிறந்தது.

Server-க்கு முன்னால் உள்ள provider firewall. பல VPS panels-ல் தனிப்பட்ட network firewall இருக்கும். --list-all ஒரு port திறந்திருப்பதாகக் காட்டியும், வெளியிலிருந்து தொடர்பு கொள்ள முடியவில்லை என்றால், server-ல் எதையும் மாற்றுவதற்கு முன் panel-ஐச் சரிபார்க்கவும். இது தலைகீழாகவும் நடக்கும்: panel-ல் விதி திறந்திருந்தாலும், firewalld packet-ஐ நிராகரித்தால் அது செயல்படாது.

sudo இல்லாமல் firewall-cmd-ஐ இயக்குதல். ஒவ்வொரு மாற்றத்திற்கும் root அனுமதி தேவை. அது இல்லையென்றால், அங்கீகாரச் சரிபார்ப்பால் கோரிக்கை நிராகரிக்கப்படும். எவ்வித மாற்றமும் நடக்காது, ஆனால் கட்டளை புறக்கணிக்கப்பட்டது போலத் தோன்றும்.

தினசரி பயன்பாட்டிற்கு ஆறு கட்டளைகள் போதுமானவை: நிலையை அறிய --list-all, ஏதேனும் ஒன்றைத் திறக்க --permanent --add-service அல்லது --add-port, அதை மூட --permanent --remove-service, சேமிக்கப்பட்ட கோப்பைச் செயல்படுத்த --reload, மற்றும் சோதனைகளுக்குப் பிறகு --runtime-to-permanent. இதில் zone என்பது public, flag என்பது --permanent. உண்மையான சரிபார்ப்பை மற்றொரு machine-லிருந்து மட்டுமே செய்ய முடியும்.

FAQ

Reboot செய்த பிறகு எனது firewalld விதி ஏன் மறைந்துவிட்டது?

அந்த விதி runtime configuration-ல் மட்டுமே சேர்க்கப்பட்டது. sudo firewall-cmd --add-service=http உடனடியாகச் செயல்படும், ஆனால் அடுத்த முறை reload அல்லது reboot செய்யும்போது அது நீக்கப்படும், ஏனெனில் /etc/firewalld/zones/public.xml-ல் உள்ள சேமிக்கப்பட்ட configuration-ல் எந்த மாற்றமும் செய்யப்படவில்லை. --permanent-ஐச் சேர்த்து, பின் sudo firewall-cmd --reload-ஐ இயக்கவும். நீங்கள் ஏற்கனவே கைமுறையாகச் சேர்த்த விதிகளைத் தக்கவைக்க, sudo firewall-cmd --runtime-to-permanent-ஐ இயக்கவும்; இது தற்போதைய விதிகளைச் சேமிக்கப்பட்ட கோப்பிற்கு நகலெடுக்கும்.

--permanent கொண்டு விதியைச் சேர்த்த பிறகு ஏன் எந்த மாற்றமும் இல்லை?

ஏனெனில் --permanent கோப்பை மட்டுமே எழுதும், இயங்கிக்கொண்டிருக்கும் firewall-ஐ மாற்றாது. sudo firewall-cmd --reload மூலம் சேமிக்கப்பட்ட configuration kernel-க்கு ஏற்றப்படும் வரை அந்த port மூடியே இருக்கும். sudo firewall-cmd --list-services மற்றும் sudo firewall-cmd --permanent --list-services ஆகியவற்றை ஒப்பிட்டுப் பார்க்கவும்: சேமிக்கப்பட்ட பட்டியலில் உள்ள ஒரு entry தற்போதைய பட்டியலில் இல்லை என்றால், நீங்கள் reload செய்யத் தவறிவிட்டீர்கள் என்று அர்த்தம்.

நான் --add-service அல்லது --add-port எதைப் பயன்படுத்த வேண்டும்?

நீங்கள் இயக்கும் சேவைக்கு ஏற்கனவே பெயர் இருந்தால் --add-service-ஐப் பயன்படுத்தவும். இது உங்கள் நோக்கத்தைத் தெளிவாகக் குறிக்கும், மேலும் அந்தப் பெயரில் எந்தெந்த ports உள்ளன என்பதை sudo firewall-cmd --info-service=https காட்டும். உங்கள் சேவைக்கு எந்த வரையறையும் இல்லையென்றால் அல்லது அது வழக்கத்திற்கு மாறான port-ல் இயங்கினால் --add-port-ஐப் பயன்படுத்தவும். ssh சேவை என்பது 22/tcp-ஐ மட்டுமே குறிக்கும், எனவே SSH-ஐ 2222-க்கு மாற்றினால், --add-port=2222/tcp மற்றும் அந்த port-க்கான SELinux label தேவைப்படும்.

firewall-cmd-ல் port மூடப்பட்டிருப்பதாகக் காட்டியும், எனது Docker container-ஐ ஏன் அணுக முடிகிறது?

ஒரு published port, Docker-ன் சொந்த NAT விதிகளால் மாற்றப்பட்டு container-க்கு அனுப்பப்படுகிறது. எனவே, அந்த packet host-க்கு வருவதில்லை; ஒரு zone-ன் service மற்றும் port பட்டியல்கள் host-க்கு வரும் packet-களை மட்டுமே கட்டுப்படுத்தும். --list-all எதையும் காட்டாதபோதும், container இணையத்திலிருந்து பதிலளிக்கும். அதற்குப் பதிலாக docker run -d -p 127.0.0.1:8080:80 nginx மூலம் loopback-ல் publish செய்து, அதன் முன்னால் ஒரு reverse proxy-ஐ அமைக்கவும்.

Rocky Linux-ல் firewalld-க்கு பதிலாக ufw-ஐ நிறுவலாமா?

ஒரே server-ல் இரண்டு firewall மேலாளர்கள் இருந்தால், அவை ஒன்றுக்கொன்று தெரியாமல் விதிகளை எழுதும். எந்த service கடைசியாகத் தொடங்குகிறதோ, அதன் விதிகளே நிலைத்திருக்கும். Rocky Linux மற்றும் AlmaLinux-ல் firewalld மட்டுமே ஆதரிக்கப்படும் கருவியாகும்; அது ஏற்கனவே நிறுவப்பட்டிருக்கும், மேலும் அது ufw பயன்படுத்தும் அதே nftables backend-ஐத்தான் இயக்குகிறது. default zone மற்றும் --permanent flag-ஐப் புரிந்துகொண்டால், இந்த முழு கருவியையும் நீங்கள் எளிதாகக் கையாளலாம்.