ufw lockout சிக்கலை சரிசெய்வது எப்படி?

மீண்டும் உள்ளே நுழைதல்

ufw உங்கள் VPS-ஐ முடக்கிவிட்டால், provider console அல்லது rescue mode மூலமே மீண்டும் உள்ளே நுழைய முடியும். ஏனெனில், blocking rule செயல்பாட்டில் இருக்கும்போது SSH மூலம் சரிசெய்ய முடியாது. SSHD-க்கு பாக்கெட்டுகள் வருவதற்கு முன்பே kernel அவற்றை நிராகரித்துவிடும், எனவே network வழியாக எதையும் சரிசெய்யவோ அல்லது உள்நுழையவோ முடியாது. உங்கள் provider-ன் control panel-ல் console-ஐத் திறந்து, அந்த prompt-ல் உள்நுழைந்து, பின்வரும் கட்டளையை இயக்கவும்.

sudo ufw disable

நீங்கள் Firewall stopped and disabled on system startup-ஐக் காண்பீர்கள். புதிய SSH இணைப்புகள் ஓரிரு வினாடிகளில் மீண்டும் வேலை செய்யத் தொடங்கும். நீங்கள் அமைத்த எவையும் அழியாது: disable கட்டளையானது kernel-லிருந்து விதிகளை நீக்கி, /etc/ufw/ufw.conf-ல் ENABLED=no-ஐ எழுதும். அதே சமயம் உங்கள் விதிகள் /etc/ufw/user.rules-ல் அடுத்த ufw enable-க்காகக் காத்திருக்கும்.

reboot செய்து சரிசெய்ய முயற்சி செய்யாதீர்கள். ufw தானாகவே boot-ல் தொடங்கும், எனவே ENABLED=yes என்பது network தொடங்குவதற்கு முன்பே அதே விதிகள் மீண்டும் ஏற்றப்படும் என்பதையே குறிக்கும். ஒரு reboot, ufw lockout சிக்கலை மாற்றாது.

Console-க்கு உங்களுக்குத் தெரியாத கடவுச்சொல் தேவைப்படலாம்

Web console (VNC அல்லது serial) என்பது அந்த machine-உடன் இணைக்கப்பட்ட ஒரு விசைப்பலகை போன்றது. இது network வழியாகச் செயல்படுவதில்லை, எனவே எந்த firewall விதியும் இதைத் தடுக்க முடியாது. இதற்கு local login தேவை; SSH key-களை மட்டும் பயன்படுத்தும் அமைப்புகளில் இது சிக்கலை ஏற்படுத்தும்: நீங்கள் sudo user-க்கு கடவுச்சொல் அமைக்காமல், root login-ஐயும் முடக்கியிருந்தால், console-ல் உங்களால் பதில் அளிக்க முடியாத prompt தோன்றும். SSH அணுகல் இருக்கும்போதே sudo passwd yourname கட்டளையைப் பயன்படுத்தி கடவுச்சொல்லை இப்போதே அமைக்கவும். பெரும்பாலான control panel-கள் root கடவுச்சொல்லை மாற்ற அனுமதிக்கும், ஆனால் இது பொதுவாக machine-ஐ reboot செய்ய வைக்கும்.

Console-ஐப் பயன்படுத்த முடியாவிட்டால், உங்கள் provider வழங்கும் rescue system-ஐ boot செய்யவும். இது உங்கள் disk-ஐ mount செய்யாமல் ஒரு தனி operating system-ஐ இயக்கும், இதன் மூலம் நீங்கள் வெளியிலிருந்து ufw-ஐ முடக்க முடியும்.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

முதலில் lsblk கட்டளையை இயக்கவும், ஏனெனில் root partition எப்போதும் /dev/vda1 நிலையில் இருக்காது. பின்னர் சாதாரண system-க்கு reboot செய்யவும்; நீங்கள் கைமுறையாக இயக்கும் வரை ufw முடக்கப்பட்டே இருக்கும்.

குறைந்தபட்ச மீட்பு வரிசை

இந்த வரிசையில் செயல்படவும். முதல் நான்கு படிகள் பாதுகாப்பானவை. அதற்குப் பிறகு வரும் படி பாதுகாப்பானது அல்ல.

1. sudo ufw disable - விதிகளை நீக்கி உங்கள் அணுகலை மீண்டும் பெற.
2. sudo ufw show added - நீங்கள் சேர்த்த விதிகளை, அவற்றைச் சேர்த்த கட்டளைகளின் வடிவிலேயே அச்சிட. ufw status போலல்லாமல், ufw செயலிழந்து இருக்கும்போதும் இது வேலை செய்யும்.
3. sudo sshd -T | grep -i '^port' - sshd உண்மையில் எந்த port-ல் இயங்குகிறது என்பதை உறுதிப்படுத்த. நீங்கள் மாற்றவில்லை என்றால், இது port 22 என்று அச்சிடும்.
4. sudo ufw allow 22/tcp - உங்கள் உண்மையான port-ஐப் பயன்படுத்தி, அடுத்தமுறை enable செய்யும்போது மீண்டும் லாக்-அவுட் ஆகாமல் இருக்க.
5. sudo ufw enable - முதலில் ஒரு rollback-ஐத் திட்டமிட்டுவிட்டு இதைச் செய்யவும். அது இந்தப் பக்கத்தின் கீழே கொடுக்கப்பட்டுள்ளது.

ufw reset உண்மையில் என்ன செய்கிறது

ufw reset என்பது முதல் கட்ட நடவடிக்கையல்ல, இதுவே இறுதி முயற்சியாகும். இது firewall-ஐ முடக்கி, அனைத்து rules கோப்புகளையும் backup எடுத்து, உள்வரும் போக்குவரத்தை (incoming) மறுக்கவும், வெளியேறும் போக்குவரத்தை (outgoing) அனுமதிக்கவும் இயல்புநிலை அமைப்புகளை மாற்றுகிறது. இது ஒவ்வொரு கோப்பிற்கும் ஒரு backup வரியை வெளியிடும்:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

reset செய்த பிறகு, அனுமதிக்கப்பட்ட விதிகள் (allow rules) எதுவும் இருக்காது. எனவே, SSH வழியாகச் செய்யாமல், நேரடியாக console மூலம் இதை இயக்கவும். மீண்டும் firewall-ஐ enable செய்வதற்கு முன் SSH விதியைச் சேர்க்கவும். அந்த backup கோப்புகள் plain text வடிவில் இருக்கும். sudo grep -n dport /etc/ufw/user.rules.20260813_101500 மூலம் பழைய விதிகள் என்னவாக இருந்தன என்பதைப் பார்க்கலாம்; தவறுதலாக நீக்கப்பட்ட ruleset-ஐ மீண்டும் உருவாக்க இதுவே வழி.

ufw அதன் விதிகளை எங்கு சேமிக்கிறது

கோப்புகளை வாசிப்பது, நினைவகத்திலிருந்து ஊகிப்பதை விட சிறந்தது. ஐந்து பாதைகள் முழு நிலையைத் தக்கவைக்கின்றன:

• /etc/ufw/user.rules மற்றும் /etc/ufw/user6.rules: நீங்கள் சேர்த்த விதிகள், அவை மதிப்பீடு செய்யப்படும் வரிசையில் உள்ளன.
• /etc/ufw/before.rules மற்றும் /etc/ufw/after.rules, மற்றும் 6 வகைகள்: உங்கள் விதிகளைச் சுற்றி ufw உருவாக்கும் கட்டமைப்பு; இதில் ஏற்கனவே உள்ள இணைப்புகளுக்கான ஏற்பு (accept) மற்றும் loopback விதிகள் அடங்கும்.
• /etc/default/ufw: இயல்புநிலை கொள்கைகள் (default policies) மற்றும் IPV6 சுவிட்ச்.
• /etc/ufw/ufw.conf: ENABLED மற்றும் log நிலை.
• /var/log/ufw.log: logging செயல்பாட்டில் இருக்கும்போது, தடுக்கப்பட்டவை.

ufw ஒரு கோப்பை மீண்டும் எழுதும் முன், அதன் நேர முத்திரையிடப்பட்ட (timestamped) நகலை உருவாக்குகிறது, எனவே ls /etc/ufw/ என்பது user.rules.20260813_101500 போன்ற பெயர்களால் நிரம்பும். இதுவே உங்கள் undo வரலாறு; மாற்றங்களைச் செய்வதற்கு முன் இதை வாசிப்பது பயனுள்ளது.

வட்டில் உள்ளதை விட, kernel-ல் என்ன ஏற்றப்பட்டுள்ளது என்பதைப் பார்க்க, sudo ufw show raw அல்லது sudo iptables -S மற்றும் sudo ip6tables -S ஆகியவற்றைப் பயன்படுத்தவும். Ubuntu 22.04 மற்றும் 24.04-ல் இந்த கட்டளைகள் nft-ஆல் ஆதரிக்கப்படுபவை, எனவே sudo nft list ruleset அதே விதிகளை புதிய syntax-ல் அச்சிடும்.

ufw-ஐ enable செய்தபோது எனது SSH session ஏன் துண்டிக்கப்பட்டது?

இயல்பான incoming policy 'deny' என்று உள்ளது. உங்கள் SSH port-க்கு எந்த விதியும் (rule) இல்லாமல் ufw-ஐ enable செய்வது, புதிய இணைப்புகள் அனைத்தையும் துண்டித்துவிடும். ufw இதற்கான எச்சரிக்கையை வழங்கும்: Command may disrupt existing ssh connections. Proceed with operation (y|n)? SSH அனுமதி விதி இல்லாமல் y என்று பதிலளிப்பதுதான் இந்தப் பக்கத்தில் உள்ள அனைத்து சிக்கல்களுக்கும் பொதுவான காரணமாகும்.

இதில் குழப்பத்தை ஏற்படுத்துவது அந்தத் தாமதம்தான். /etc/ufw/before.rules என்பது ESTABLISHED,RELATED நிலையில் உள்ள பாக்கெட்டுகளை, உங்கள் விதிகள் அமலுக்கு வருவதற்கு முன்பே அனுமதிக்கும். எனவே, நீங்கள் கட்டளையைத் தட்டச்சு செய்த அதே session வழக்கம்போல இயங்கும். அடுத்தமுறை இணைக்க முயற்சிக்கும்போதுதான் இந்த lockout தெரியும். அது பல மணிநேரம் கழித்து நடக்கலாம் என்பதால், firewall மாற்றத்திற்கும் இதற்கும் தொடர்பு இருப்பதாகத் தோன்றாது. எப்போதும் இரண்டாவது SSH session-ஐத் திறந்து, அது வேலை செய்கிறதா என்பதை உறுதிப்படுத்திய பிறகே முதல் session-ஐ மூடவும்.

கொள்கை மாற்றத்திற்குப் பிறகு apt மற்றும் DNS ஏன் வேலை செய்யவில்லை?

sudo ufw default deny outgoing வெளிச்செல்லும் DNS (domain name system) வினவல்கள் மற்றும் வெளிச்செல்லும் HTTP ஆகியவற்றைத் தடுக்கிறது, எனவே பெயர் தீர்மானம் (name resolution) செயலிழந்து, தொகுப்பு மேம்படுத்தல்கள் (package updates) நின்றுவிடுகின்றன. apt update, Temporary failure resolving 'archive.ubuntu.com' என்று தெரிவிக்கிறது. உள்வரும் SSH தொடர்ந்து வேலை செய்கிறது, ஏனெனில் அதற்கான பதில்கள் ESTABLISHED நிலையில் இருப்பதால் அவை framework விதிகளின்படி அனுமதிக்கப்படுகின்றன. இதனால் firewall சரியாகச் செயல்படுவது போலத் தோன்றினாலும், அதுவே இந்தச் சிக்கலுக்குக் காரணமாகிறது.

நீங்கள் வெளிச்செல்லும் போக்குவரத்தைத் தடுக்கும் கொள்கையை (deny outgoing policy) அமல்படுத்த விரும்பினால், அந்த machine-க்குத் தேவையானவற்றை மட்டும் அனுமதிக்கவும்:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

கடைசி விதி இல்லையென்றால், system clock-ல் கால மாற்றம் (drift) ஏற்படும். தவறான நேரம் TLS (transport layer security) certificate சரிபார்ப்பைப் பாதிக்கும், இதனால் curl போர்ட் சிக்கல்களை விட, தேதி தொடர்பான பிழைகளைக் காட்டத் தொடங்கும். இந்த அறிகுறி கொள்கை மாற்றத்திற்குப் பல நாட்களுக்குப் பிறகே வெளிப்படும். இதனால்தான், வெளிச்செல்லும் போக்குவரத்தைத் தடுக்கும் கொள்கையை நீங்கள் தொடர்ந்து கண்காணிக்கும் machine-களுக்கு மட்டும் பயன்படுத்த வேண்டும்; ஒருமுறை அமைத்துவிட்டு விட்டுவிடும் பெட்டிகளுக்கு (box) இதைப் பயன்படுத்தக்கூடாது.

எனது ufw விதி ஏன் பொருந்தவில்லை?

ufw பயனர் விதிகளை வரிசையாக மதிப்பீடு செய்து, முதலில் பொருந்தும் விதியுடன் நிறுத்திவிடும். ஒரு பொதுவான allow விதிக்கு பிறகு சேர்க்கப்படும் deny விதி ஒருபோதும் செயல்படாது, ஏனெனில் அந்த packet-ஐ அனுமதிக்கும் முடிவை முந்தைய விதியே எடுத்துவிடுகிறது. விதிகளின் வரிசையை எண்களுடன் சரிபார்க்கவும், பின்னர் தேவையான இடத்தில் புதிய விதியைச் சேர்க்கவும்.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp கட்டளையானது, நடைமுறைப்படுத்தப்பட வேண்டிய விதிகளை மட்டும் காட்டும், எதையும் மாற்றாது. ஒரு விதியைச் செயல்படுத்துவதற்கு முன்பு அதைச் சரிபார்க்க இதுவே பாதுகாப்பான வழியாகும்.

மற்றொரு சிக்கல் application profiles-ல் உள்ளது. sudo ufw allow OpenSSH கட்டளையானது /etc/ufw/applications.d/openssh-server-ல் உள்ள profile-ஐப் பயன்படுத்துகிறது, அந்த profile என்பது port 22-ஐக் குறிக்கும். ஒருவேளை sshd ஆனது 2222-ல் இயங்கினால், இந்த விதி யாரும் பயன்படுத்தாத ஒரு port-ஐத் திறந்துவிடும்; இதனால் விதிகள் சரியாக இருப்பது போலத் தெரிந்தாலும், உங்களால் server-க்குள் நுழைய முடியாமல் போகலாம். port-ஐ மாற்றிய பிறகு, port எண்ணையே நேரடியாகப் பயன்படுத்தவும். இதர syntax விவரங்களுக்கு VPS-க்கான ufw firewall அடிப்படைகள் பகுதியைப் பார்க்கவும்.

IPv4 விதிகள் நான் காண்பதை ஏன் விளக்குவதில்லை?

பாதி traffic IPv4-ல் இல்லாததே இதற்குக் காரணம். Ubuntu IPV6=yes-ஐ /etc/default/ufw-ல் வழங்குகிறது, எனவே ufw ஒரு இணையான v6 விதிகளின் தொகுப்பை /etc/ufw/user6.rules-ல் பராமரிக்கிறது. ufw allow from 203.0.113.10 to any port 22 போன்ற IPv4 முகவரியைக் கொண்டு எழுதப்படும் ஒரு விதி, எந்தவொரு v6 விதியையும் உருவாக்காது. உங்கள் VPS-ல் AAAA record இருந்தால், உங்கள் client IPv6-ஐ முன்னுரிமைப்படுத்தும், மேலும் ufw status சரியான விதியைக் காட்டினாலும் உங்கள் connection காலாவதியாகிவிடும் (timeout). ssh -4 user@host மற்றும் ssh -6 user@host ஆகியவற்றைக் கொண்டு இந்த வித்தியாசத்தைச் சோதிக்கவும். முதலாவது வேலை செய்து, இரண்டாவது வேலை செய்யவில்லை என்றால், v6 விதிகளின் தொகுப்பில் தான் இடைவெளி உள்ளது என்று அர்த்தம்.

பாதுகாப்பைப் பொறுத்தவரை இதற்கு நேர்மாறான நிலை இன்னும் மோசமானது. IPV6=no அமைப்பில், ufw ip6tables-ஐ நிர்வகிப்பதில்லை, எனவே v6 கொள்கை (policy) kernel-ன் இயல்புநிலை அமைப்பான ACCEPT-லேயே இருக்கும். நீங்கள் மூடியிருப்பதாகக் கருதும் ஒரு port அதன் IPv6 முகவரியில் பதிலளிக்கும், எந்தவொரு ufw கட்டளையும் அதைக் குறிப்பிடாது. sudo ip6tables -S மற்றும் ss -tlnp மூலம் சரிபார்க்கவும், மேலும் முழுமையான விவரங்களுக்கு ufw IPv6 போர்ட்களை எவ்வாறு கையாள்கிறது என்பதைப் படிக்கவும்.

ufw மூலம் ஒரு port மறுக்கப்பட்டாலும், Docker-ல் ஏன் அது திறந்திருக்கிறது?

Docker ஒரு port-ஐ வெளியிடும்போது, அது nat அட்டவணையில் DNAT (destination network address translation) விதிகளை எழுதி, தனது சொந்த chain-ஐ FORWARD-ல் சேர்க்கிறது. ufw-ன் விதிகள் INPUT பாதையில் அமைகின்றன. Container-க்கு வரும் traffic, host-க்கு வழங்கப்படாமல் நேரடியாக forward செய்யப்படுகிறது; எனவே, உங்கள் deny விதி இருக்கும் chain-க்கு அது செல்வதில்லை. ufw செயல்பாட்டில் இருந்து, அனைத்தையும் மறுக்கும் நிலையிலும் docker run -p 5432:5432 இணையத்திலிருந்து அணுகக்கூடியதாகவே இருக்கும்.

sudo iptables -t nat -S DOCKER

இதற்கான மிக எளிமையான தீர்வு, loopback-ல் வெளியிடுவதுதான்: -p 127.0.0.1:5432:5432, host-ன் பக்கத்தை 127.0.0.1-உடன் பிணைக்கிறது (bind). ufw என்னதான் சொன்னாலும், வெளிப்புறத்திலிருந்து எவராலும் அதை அணுக முடியாது. ufw-ஐத் தாண்டி Docker port-களை வெளியிடுதல் என்ற பகுதி, சேவை பொதுவெளியில் கிடைக்க வேண்டிய சூழல்களை விளக்குகிறது.

விதிமுறையைச் செயல்படுத்தும் முன் rollback-ஐத் திட்டமிடுங்கள்

Firewall நிர்வாகத்தை பாதுகாப்பானதாக மாற்றும் பழக்கம் இதுவாகும். எந்தவொரு ஆபத்தான மாற்றத்தைச் செய்யும் முன்பும், அதைத் திரும்பப் பெறுவதற்கான (undo) திட்டத்தை முன்கூட்டியே அமைக்கவும். இந்த மாற்றம் உங்களை server-லிருந்து வெளியேற்றிவிட்டால் (lock out), ஐந்து நிமிடங்களில் கணினி தானாகவே பழைய நிலைக்குத் திரும்பிவிடும்; நீங்கள் console-ஐத் திறக்க வேண்டிய அவசியமே இருக்காது.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd Running timer as unit: ufw-rollback.timer-ஐ அச்சிடும். இப்போது உங்கள் மாற்றத்தைச் செய்யுங்கள். மாற்றத்திற்குப் பிறகும் உங்களால் புதிய SSH session-ஐத் திறக்க முடிந்தால், rollback-ஐ ரத்து செய்யவும்:

sudo systemctl stop ufw-rollback.timer

உங்களால் அந்த session-ஐத் திறக்க முடியவில்லை என்றால், காத்திருக்கவும். ufw தானாகவே செயலிழந்துவிடும், அடுத்த முயற்சியில் உங்களால் இணைக்க முடியும். ufw-ஐப் பொறுத்தவரை, பழைய shutdown -r +5 தந்திரம் உதவாது; ஏனெனில், boot-ன் போது ufw அதே ruleset-ஐ மீண்டும் ஏற்றுகிறது.

இரண்டாவது அணுகல் வழியைப் பராமரித்தல்

• தேவைப்படுவதற்கு முன்பே, ஒருமுறை provider console-ல் உள்நுழைந்து கடவுச்சொல் சரியாக வேலை செய்கிறதா என்பதை உறுதிப்படுத்தவும். நீங்கள் ஒருபோதும் சோதிக்காத console ஒரு backup ஆகாது.
• தனிப்பட்ட key-உடன் கூடிய இரண்டாவது sudo user-ஐ வைத்திருக்கவும். அப்போதுதான் ஒரு சிதைந்த authorized_keys கோப்பு உங்கள் அணுகலை முழுமையாகத் தடுக்காது.
• உங்கள் provider, ufw-க்கு வெளியே தனிப்பட்ட network firewall-ஐ வழங்குகிறாரா என்று சரிபார்க்கவும். அதுவும் அதே ports-ஐத் தடுக்கும், ஆனால் ufw status அதைப் பற்றி ஒருபோதும் குறிப்பிடாது.
• உங்கள் IP address dynamic ஆக இருந்தால், ufw allow from <your home address>-ஐ மட்டும் உங்கள் ஒரே SSH விதியாக (rule) வைக்க வேண்டாம். உங்கள் provider அதை இரவோடு இரவாக மாற்றினால், நீங்கள் server-ஐ அணுக முடியாமல் போகும்.

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

Refused அல்லது timed out பிழைகள் எந்த அடுக்கில் தோல்வி ஏற்பட்டது என்பதை உணர்த்துகின்றன

Connection refused என்பது ஒரு packet server-ஐ அடைந்து, ஏதோ ஒன்று TCP reset-ஐ திருப்பி அனுப்பியுள்ளது என்று பொருள். Network பாதை சரியாக உள்ளது, எனவே sshd நிறுத்தப்பட்டிருக்கலாம் அல்லது வேறு port-ல் இயங்கிக்கொண்டிருக்கலாம். Firewall-ஆல் இது நிகழ வாய்ப்பு குறைவு, ஏனெனில் ufw இயல்பாகவே packet-களை நிராகரிப்பதற்கு (reject) பதிலாக drop செய்கிறது.

Connection timed out என்பது எந்த பதிலும் வரவில்லை என்று பொருள். இது ஒரு drop-ன் அறிகுறியாகும்: ufw, provider network firewall, அல்லது தவறான முகவரி காரணமாக இது நிகழலாம். இந்த இரண்டு பிழைகளையும் சரியாகப் புரிந்துகொள்வது தேவையற்ற ஊகங்களைத் தவிர்க்க உதவும், மேலும் connection refused மற்றும் timed out ஆகியவற்றுக்கு இடையேயான வேறுபாடு மீதமுள்ள சூழல்களை விளக்குகிறது.

அடுத்த மாற்றத்திற்கு முன் logging-ஐ இயக்கவும்

sudo ufw logging on
sudo tail -f /var/log/ufw.log

தடுக்கப்பட்ட packet பின்வருமாறு தோன்றும்:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22-ல் உங்கள் சொந்த முகவரியுடன் SRC= இருப்பது, உங்களைத் தடுப்பது network அல்லது sshd அல்ல, ufw தான் என்பதற்குச் சான்றாகும். rsyslog இல்லாத minimal image-ல் /var/log/ufw.log இருக்காது, அதே வரிகள் sudo journalctl -k | grep UFW-லிருந்து வரும். ufw தனது சொந்த logging விதிகளை rate limit செய்கிறது, எனவே ஒரு வரி விடுபட்டிருப்பது packet அனுமதிக்கப்பட்டது என்பதற்குச் சான்றாகாது.

நீங்கள் சேர்க்காத விதிகள் (rules) இருந்தால்

தானாகவே மாறிய ஒரு ruleset என்பது firewall தொடர்பான சிக்கல் அல்ல. root அனுமதி கொண்ட யாரோ ஒருவரே அதை எழுதியுள்ளனர். எந்தெந்த sudo கட்டளைகள், எந்தக் கணக்கின் கீழ் இயக்கப்பட்டன என்பதைப் பார்க்க sudo grep ufw /var/log/auth.log-ஐ இயக்கவும். பின்னர், அந்த நேரத்திற்கு அருகில் நடந்த logins-ஐப் பார்க்க last-ஐப் பயன்படுத்தவும். அந்தக் கணக்குகள் உங்களுக்குத் தெரிந்த யாருடையதும் இல்லை என்றால், firewall-ஐச் சரிபார்ப்பதை நிறுத்திவிட்டு, compromised VPS சரிபார்ப்புப் பட்டியலைப் பின்பற்றிச் செயல்படவும். மற்றவர் கட்டுப்பாட்டில் உள்ள ஒரு கணினியில் firewall-ஐ மீண்டும் செயல்படுத்துவது சிக்கலை மறைக்க மட்டுமே உதவும்.

மீண்டும் ஒருங்கிணைத்தல்

காரணத்தை கண்டறிந்த பிறகு, மீண்டும் lockout ஏற்படாத வகையில் ufw-ஐ enable செய்யவும். உங்கள் உண்மையான SSH port-ஐ அனுமதிக்கவும், rollback-ஐ திட்டமிடவும், enable செய்யவும். பின்னர், மற்றொரு terminal-லிருந்து புதிய SSH session-ஐத் தொடங்கி, அது connect ஆகிறதா என்பதை உறுதிப்படுத்தவும். அந்த புதிய session சரியாக இயங்கிய பிறகு மட்டுமே, நீங்கள் தற்போது பயன்படுத்தும் session-ஐ மூடவும். ஒரு நாள் முழுவதும் logging-ஐ செயல்பாட்டில் வைக்கவும்; ஏனெனில், user.rules-ஐ வாசிப்பதை விட, எதை அனுமதிக்க மறந்துவிட்டீர்கள் என்பதை log மிக விரைவாகத் தெரிவிக்கும்.

FAQ

ufw disable எனது விதிகளை நீக்கிவிடுமா?

இல்லை. disable கர்னலில் (kernel) இருந்து விதிகளை நீக்கிவிட்டு, ENABLED=no-ஐ /etc/ufw/ufw.conf-ல் எழுதும். உங்கள் விதிகள் /etc/ufw/user.rules மற்றும் /etc/ufw/user6.rules-ல் அப்படியே இருக்கும், மேலும் firewall செயலிழந்திருக்கும்போது sudo ufw show added அவற்றை பட்டியலிடும். ufw reset என்பது விதிகளை அழிக்கும் கட்டளை, இது ஒவ்வொரு கோப்பையும் முதலில் பேக்கப் (backup) எடுத்துவிட்டு, Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500' போன்ற ஒரு வரியை அச்சிடும்.

எனது VPS-ஐ ரீபூட் (reboot) செய்வது ufw லாக்அவுட்டை (lockout) சரிசெய்யுமா?

இல்லை. /etc/ufw/ufw.conf-ல் உள்ள ENABLED=yes மூலம் கணினி தொடங்கும்போதே ufw இயங்கத் தொடங்கும். எனவே, நெட்வொர்க் இணைக்கப்படுவதற்கு முன்பே அதே விதிகள் ஏற்றப்பட்டு, நீங்கள் மீண்டும் லாக்அவுட் செய்யப்படுவீர்கள். நீங்கள் ufw-ஐ அணைத்த பிறகு அல்லது rescue mode-ல் டிஸ்க்கை மவுண்ட் (mount) செய்து அந்த கோப்பைத் திருத்திய பிறகு மட்டுமே ரீபூட் செய்வது உதவும். உங்கள் சேவை வழங்குநரின் கன்சோலைப் (provider console) பயன்படுத்தி, அங்கு sudo ufw disable கட்டளையை இயக்கவும்.

ufw போர்ட்டைத் (port) தடுத்தாலும், எனது Docker container ஏன் அணுகக்கூடியதாக உள்ளது?

Docker ஒவ்வொரு வெளியிடப்பட்ட போர்ட்டிற்கும் அதன் சொந்த DNAT மற்றும் FORWARD விதிகளை எழுதுகிறது. அந்த டிராஃபிக் (traffic) ஹோஸ்டிற்கு வழங்கப்படாமல் நேரடியாக கன்டெய்னருக்கு அனுப்பப்படுகிறது. எனவே, அது உங்கள் ufw deny விதி இருக்கும் INPUT செயினுக்குள் (chain) செல்வதில்லை. போர்ட் ஹோஸ்டிற்கு மட்டுமே தேவைப்படும்போது -p 127.0.0.1:5432:5432 மூலம் loopback-ல் வெளியிடவும், மேலும் Docker என்ன விதிகளை நிறுவியுள்ளது என்பதை sudo iptables -t nat -S DOCKER மூலம் சரிபார்க்கவும்.

என்னிடம் கன்சோல் கடவுச்சொல் மற்றும் rescue mode இல்லை. எனது விருப்பங்கள் என்ன?

மீதமுள்ள விருப்பங்கள் உங்கள் சேவை வழங்குநரைச் சார்ந்தவை: கண்ட்ரோல் பேனலில் இருந்து கடவுச்சொல்லை மீட்டமைத்தல் (இது பொதுவாக சர்வரை ரீபூட் செய்யும்), அல்லது டிஸ்க்கை மற்றொரு instance-உடன் இணைத்து அங்கிருந்து /etc/ufw/ufw.conf கோப்பைத் திருத்துதல். சர்வரை ரீபில்ட் (rebuild) செய்வதற்கு முன் ஆதரவு குழுவைத் (support) தொடர்பு கொள்ளுங்கள், ஏனெனில் ரீபில்ட் செய்வது அதில் உள்ள தரவுகளை அழித்துவிடும். நீங்கள் மீண்டும் உள்ளே சென்றதும், sudo passwd yourname கட்டளையை இயக்கி கன்சோல் லாகினை ஒருமுறை சோதிக்கவும், இதனால் அடுத்த முறை லாக்அவுட் ஏற்பட்டால் இரண்டு நிமிடங்களில் சரிசெய்ய முடியும்.