วิธีแก้ปัญหาถูกล็อกออกจาก VPS หลังตั้งค่า ufw ผิดพลาด

การเข้าถึงระบบอีกครั้ง

หาก ufw ทำให้คุณไม่สามารถเข้าถึง VPS ของคุณได้ วิธีเดียวที่จะกลับเข้าไปได้คือการใช้คอนโซลของผู้ให้บริการหรือโหมดกู้คืน (rescue mode) เนื่องจากไม่มีวิธีแก้ไขผ่าน SSH ได้เมื่อกฎการบล็อกมีผลใช้งานแล้ว เคอร์เนลจะทิ้งแพ็กเก็ตของคุณก่อนที่ sshd จะได้รับข้อมูล ทำให้ไม่มีช่องทางให้ล็อกอินและไม่สามารถแก้ไขผ่านเครือข่ายได้ ให้เปิดคอนโซลในแผงควบคุมของผู้ให้บริการ ล็อกอินที่พรอมต์นั้น แล้วรันคำสั่งเดียว

sudo ufw disable

คุณควรเห็น Firewall stopped and disabled on system startup การเชื่อมต่อ SSH ใหม่จะกลับมาใช้งานได้อีกครั้งภายในหนึ่งหรือสองวินาที สิ่งที่คุณตั้งค่าไว้จะไม่สูญหาย: disable จะนำกฎออกจากเคอร์เนลและเขียน ENABLED=no ลงใน /etc/ufw/ufw.conf ในขณะที่กฎของคุณยังคงอยู่ในดิสก์ที่ /etc/ufw/user.rules เพื่อรอการใช้งานใน ufw enable ครั้งถัดไป

อย่ารีบูตเครื่องโดยหวังว่าปัญหาจะหายไป ufw จะเริ่มทำงานเองเมื่อบูตเครื่อง ดังนั้น ENABLED=yes จึงหมายความว่าชุดกฎเดิมจะถูกโหลดขึ้นมาอีกครั้งก่อนที่เครือข่ายจะพร้อมใช้งาน การรีบูตไม่ช่วยแก้ไขปัญหาการถูกล็อกโดย ufw แต่อย่างใด

คอนโซลต้องการรหัสผ่านที่คุณอาจไม่มี

เว็บคอนโซล (VNC หรือ serial) เปรียบเสมือนคีย์บอร์ดที่เชื่อมต่อกับเครื่องโดยตรง ไม่ใช่เส้นทางเครือข่าย ดังนั้นจึงไม่มีกฎ firewall ใดที่สามารถบล็อกการเข้าถึงนี้ได้ อย่างไรก็ตาม คอนโซลจำเป็นต้องมีการล็อกอินในเครื่อง ซึ่งเป็นจุดที่การตั้งค่าแบบใช้เฉพาะ key ล้มเหลว หากคุณไม่เคยตั้งรหัสผ่านสำหรับผู้ใช้ sudo ของคุณ และการล็อกอินด้วย root ถูกปิดใช้งาน คอนโซลจะแสดงหน้าจอให้คุณป้อนข้อมูลที่คุณไม่สามารถตอบได้ ให้ตั้งรหัสผ่านนั้นเสียตั้งแต่ตอนนี้ ในขณะที่คุณยังสามารถเข้าถึงผ่าน SSH ได้: sudo passwd yourname แผงควบคุมส่วนใหญ่ยังสามารถรีเซ็ตรหัสผ่าน root ได้ ซึ่งโดยปกติแล้วจะต้องทำการรีบูตเครื่อง

หากคอนโซลไม่สามารถใช้งานได้ ให้บูตเข้าสู่ระบบกู้คืน (rescue system) ของผู้ให้บริการ ระบบนี้จะรันระบบปฏิบัติการแยกต่างหากโดยที่ดิสก์ของคุณยังไม่ได้ถูก mount ทำให้คุณสามารถปิด 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 เสมอไป จากนั้นรีบูตเข้าสู่ระบบปกติ แล้ว ufw จะยังคงปิดอยู่จนกว่าคุณจะเปิดใช้งานด้วยตนเอง

ลำดับการกู้คืนระบบขั้นต่ำ

ให้ดำเนินการตามลำดับนี้ สี่ขั้นตอนแรกมีความปลอดภัย ส่วนขั้นตอนสุดท้ายมีความเสี่ยง

1. ใช้ sudo ufw disable เพื่อยกเลิกการโหลดกฎและเรียกคืนสิทธิ์การเข้าถึงของคุณ
2. ใช้ sudo ufw show added เพื่อแสดงรายการกฎที่คุณเพิ่มเข้าไปในรูปแบบของคำสั่งที่ใช้สร้างกฎเหล่านั้น วิธีนี้ใช้ได้ในขณะที่ ufw ไม่ทำงาน ซึ่งต่างจาก ufw status ที่ทำไม่ได้
3. ใช้ sudo sshd -T | grep -i '^port' เพื่อยืนยันพอร์ตที่ sshd กำลังรับฟังอยู่จริง โดยปกติจะแสดงผลเป็น port 22 เว้นแต่คุณจะมีการเปลี่ยนแปลงค่าดังกล่าว
4. ใช้ sudo ufw allow 22/tcp โดยระบุพอร์ตที่คุณใช้งานจริง เพื่อป้องกันไม่ให้การเปิดใช้งานในครั้งถัดไปทำให้คุณถูกล็อกออกจากระบบอีก
5. ใช้ sudo ufw enable โดยต้องกำหนดเวลาการย้อนกลับ (rollback) ไว้ล่วงหน้า ซึ่งรายละเอียดจะอยู่ในส่วนถัดไปของหน้านี้

สิ่งที่ ufw reset ทำงานจริง

ufw reset เป็นทางเลือกสุดท้าย ไม่ใช่ขั้นตอนแรก คำสั่งนี้จะปิดการทำงานของไฟร์วอลล์ สำรองไฟล์กฎทั้งหมด และคืนค่าเริ่มต้นเป็นการปฏิเสธการเชื่อมต่อขาเข้า (deny incoming) และอนุญาตการเชื่อมต่อขาออก (allow outgoing) โดยจะแสดงบรรทัดการสำรองข้อมูลหนึ่งบรรทัดต่อหนึ่งไฟล์:

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

หลังจากรีเซ็ตแล้ว คุณจะไม่มีกฎอนุญาตใดๆ เหลืออยู่ ดังนั้นควรเรียกใช้คำสั่งนี้จากคอนโซลโดยตรงแทนการทำผ่าน SSH และต้องเพิ่มกฎสำหรับ SSH ก่อนที่จะเปิดใช้งานไฟร์วอลล์อีกครั้ง ไฟล์สำรองเหล่านั้นเป็นข้อความธรรมดา sudo grep -n dport /etc/ufw/user.rules.20260813_101500 จะแสดงให้เห็นว่ากฎเดิมเคยเป็นอย่างไร ซึ่งเป็นวิธีที่คุณจะใช้สร้างชุดกฎขึ้นมาใหม่ในกรณีที่คุณไม่ได้ตั้งใจจะลบทิ้ง

ตำแหน่งที่ ufw เก็บกฎต่างๆ

การอ่านไฟล์โดยตรงให้ผลลัพธ์ที่แม่นยำกว่าการคาดเดาจากความจำ สถานะทั้งหมดของระบบถูกจัดเก็บไว้ใน 5 ตำแหน่งหลัก:

• /etc/ufw/user.rules และ /etc/ufw/user6.rules: กฎที่คุณเพิ่มเข้าไป โดยเรียงตามลำดับการตรวจสอบ
• /etc/ufw/before.rules และ /etc/ufw/after.rules รวมถึงไฟล์สำรอง 6: โครงสร้างพื้นฐานที่ ufw ครอบกฎของคุณไว้ ซึ่งรวมถึงการอนุญาตการเชื่อมต่อที่สร้างไว้แล้ว (established connections) และกฎสำหรับ loopback
• /etc/default/ufw: นโยบายเริ่มต้น (default policies) และสวิตช์ IPV6
• /etc/ufw/ufw.conf: ENABLED และระดับการบันทึก log
• /var/log/ufw.log: บันทึกสิ่งที่ถูกบล็อก เมื่อมีการเปิดใช้งานการบันทึก log แล้ว

ufw จะสร้างสำเนาไฟล์พร้อมประทับเวลาไว้ก่อนที่จะเขียนทับไฟล์เดิม ดังนั้น ls /etc/ufw/ จึงเต็มไปด้วยชื่อไฟล์เช่น user.rules.20260813_101500 ซึ่งถือเป็นประวัติการแก้ไขย้อนกลับของคุณ และควรตรวจสอบไฟล์เหล่านี้ก่อนที่จะเริ่มย้อนการตั้งค่าต่างๆ

หากต้องการดูว่ากฎใดที่ถูกโหลดเข้าสู่ kernel แทนการดูจากไฟล์บนดิสก์ ให้ใช้ sudo ufw show raw หรือ sudo iptables -S และ sudo ip6tables -S สำหรับ Ubuntu 22.04 และ 24.04 คำสั่งเหล่านี้จะทำงานผ่าน nft ดังนั้น sudo nft list ruleset จะแสดงกฎชุดเดียวกันในรูปแบบไวยากรณ์ใหม่

เหตุใดการเปิดใช้งาน ufw จึงทำให้เซสชัน SSH ของฉันถูกตัดการเชื่อมต่อ?

นโยบายขาเข้าเริ่มต้นคือ deny การเปิดใช้งาน ufw โดยไม่มีกฎสำหรับพอร์ต SSH ของคุณจะตัดการเชื่อมต่อใหม่ทั้งหมด ufw มีการแจ้งเตือนคุณ: Command may disrupt existing ssh connections. Proceed with operation (y|n)? การตอบรับ y โดยไม่มีกฎอนุญาต SSH เป็นสาเหตุที่พบบ่อยที่สุดของปัญหาทั้งหมดในหน้านี้

ส่วนที่น่าสับสนคือความล่าช้า /etc/ufw/before.rules ยอมรับแพ็กเก็ตในสถานะ ESTABLISHED,RELATED ก่อนที่จะถึงกฎของคุณ ดังนั้นเซสชันที่คุณใช้พิมพ์คำสั่งจึงยังคงทำงานได้ตามปกติ การถูกล็อกเอาต์จะเกิดขึ้นในการเชื่อมต่อครั้งถัดไป ซึ่งอาจเป็นเวลาหลายชั่วโมงหลังจากนั้น และเมื่อถึงตอนนั้นการเปลี่ยนแปลงไฟร์วอลล์ก็ดูไม่เกี่ยวข้องกับปัญหาแล้ว ควรเปิดเซสชัน SSH สำรองไว้เสมอและตรวจสอบว่าใช้งานได้ก่อนที่จะปิดเซสชันแรก

เหตุใด apt และ DNS จึงหยุดทำงานหลังจากการเปลี่ยนแปลงนโยบาย

sudo ufw default deny outgoing ปิดกั้นการสอบถาม DNS (domain name system) ขาออกและ HTTP ขาออก ส่งผลให้การแปลงชื่อโดเมนล้มเหลวและไม่สามารถอัปเดตแพ็กเกจได้ apt update จะรายงานข้อผิดพลาด Temporary failure resolving 'archive.ubuntu.com' การเชื่อมต่อ SSH ขาเข้ายังคงใช้งานได้ เนื่องจากแพ็กเกจตอบกลับถูกจัดอยู่ในสถานะ ESTABLISHED และผ่านกฎของ framework ทำให้ firewall ดูเหมือนไม่มีส่วนเกี่ยวข้อง ทั้งที่จริงแล้วเป็นสาเหตุของปัญหา

หากคุณต้องการใช้นโยบายปฏิเสธการเชื่อมต่อขาออก (deny outgoing) ให้เปิดพอร์ตที่เครื่องจำเป็นต้องใช้งานจริงดังนี้:

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

หากไม่มีกฎข้อสุดท้าย นาฬิกาของระบบจะคลาดเคลื่อน และเมื่อเวลาไม่ตรงกันจะทำให้การตรวจสอบใบรับรอง TLS (transport layer security) ล้มเหลว ส่งผลให้ curl เริ่มแจ้งเตือนข้อผิดพลาดเกี่ยวกับวันที่แทนที่จะเป็นเรื่องพอร์ต อาการนี้จะปรากฏให้เห็นหลังจากทำการเปลี่ยนแปลงไปแล้วหลายวัน นี่คือเหตุผลว่าทำไมนโยบาย deny outgoing จึงเหมาะสำหรับเครื่องที่คุณเฝ้าระวังอยู่ตลอดเวลา ไม่ใช่สำหรับเครื่องที่ตั้งค่าไว้เพียงครั้งเดียวแล้วปล่อยทิ้งไว้

ทำไมกฎ ufw ของฉันถึงไม่ทำงานตามที่คาดไว้?

ufw จะประเมินกฎที่ผู้ใช้กำหนดตามลำดับและหยุดทันทีเมื่อพบกฎแรกที่ตรงกัน กฎ deny ที่เพิ่มเข้ามาหลังจากกฎแบบกว้างอย่าง allow จะไม่มีวันทำงาน เพราะกฎอนุญาตได้ตัดสินใจจัดการแพ็กเก็ตนั้นไปเรียบร้อยแล้ว ให้แสดงลำดับของกฎพร้อมหมายเลขกำกับ จากนั้นจึงแทรกกฎใหม่ในตำแหน่งที่ต้องการ

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 จะแสดงรายการกฎที่จะถูกเขียนลงไปโดยไม่มีการเปลี่ยนแปลงใดๆ เกิดขึ้นจริง นี่เป็นวิธีที่ปลอดภัยในการตรวจสอบกฎก่อนที่จะนำไปใช้งานจริง

อีกหนึ่งจุดที่มักเกิดปัญหาคือโปรไฟล์ของแอปพลิเคชัน คำสั่ง sudo ufw allow OpenSSH จะใช้โปรไฟล์ที่อยู่ใน /etc/ufw/applications.d/openssh-server ซึ่งโปรไฟล์ดังกล่าวหมายถึงพอร์ต 22 หาก sshd กำลังฟังอยู่ที่พอร์ต 2222 กฎนี้จะเปิดพอร์ตที่ไม่มีบริการใดใช้งานอยู่ และอาจทำให้คุณถูกล็อกออกจากระบบด้วยชุดกฎที่ดูเหมือนว่าถูกต้อง ให้ใช้หมายเลขพอร์ตโดยตรงเมื่อคุณมีการเปลี่ยนพอร์ตใช้งานแล้ว สำหรับไวยากรณ์ส่วนที่เหลือสามารถดูได้ที่ พื้นฐานการใช้งาน ufw firewall สำหรับ VPS

เหตุใดกฎ IPv4 จึงไม่อธิบายสิ่งที่ฉันเห็น?

เนื่องจากทราฟฟิกครึ่งหนึ่งไม่ใช่ IPv4 โดย Ubuntu มาพร้อมกับ IPV6=yes ใน /etc/default/ufw และ ufw จะเก็บชุดกฎ v6 แบบขนานไว้ใน /etc/ufw/user6.rules กฎที่เขียนด้วยที่อยู่ IPv4 เช่น ufw allow from 203.0.113.10 to any port 22 จะไม่สร้างกฎ v6 ใดๆ ขึ้นมาเลย หาก VPS ของคุณมีระเบียน AAAA ไคลเอนต์ของคุณจะเลือกใช้ IPv6 เป็นอันดับแรก และการเชื่อมต่อของคุณจะหมดเวลา (timeout) ในขณะที่ ufw status แสดงกฎที่ดูเหมือนถูกต้อง ให้ทดสอบความแตกต่างด้วย ssh -4 user@host เทียบกับ ssh -6 user@host หากคำสั่งแรกทำงานได้แต่คำสั่งที่สองไม่ได้ ช่องว่างนั้นก็คือชุดกฎ v6

กรณีตรงกันข้ามนั้นแย่กว่าในแง่ของความปลอดภัย เนื่องจาก IPV6=no ทำให้ ufw ไม่จัดการ ip6tables เลย นโยบาย v6 จึงคงค่าเริ่มต้นของเคอร์เนลไว้ที่ ACCEPT พอร์ตที่คุณเชื่อว่าปิดอยู่จะตอบสนองผ่านที่อยู่ IPv6 และไม่มีคำสั่ง ufw ใดที่จะแสดงพอร์ตนั้น ให้ตรวจสอบด้วย sudo ip6tables -S และ ss -tlnp และอ่าน วิธีที่ ufw จัดการพอร์ต IPv6 เพื่อดูภาพรวมทั้งหมด

เหตุใดพอร์ต Docker จึงเปิดอยู่ทั้งที่ ufw ปฏิเสธการเชื่อมต่อไว้?

Docker เผยแพร่พอร์ตโดยการเขียนกฎ DNAT (destination network address translation) ลงในตาราง nat และแทรก chain ของตนเองเข้าไปใน FORWARD กฎของ ufw นั้นอยู่ในเส้นทาง INPUT การรับส่งข้อมูลไปยังคอนเทนเนอร์จะถูกส่งต่อ (forward) แทนที่จะส่งมอบให้กับโฮสต์โดยตรง ข้อมูลจึงไม่ผ่าน chain ที่คุณตั้งกฎปฏิเสธไว้ docker run -p 5432:5432 จึงสามารถเข้าถึงได้จากอินเทอร์เน็ตแม้ว่า ufw จะทำงานอยู่และปฏิเสธการเชื่อมต่อทั้งหมดก็ตาม

sudo iptables -t nat -S DOCKER

วิธีแก้ไขที่ง่ายที่สุดคือการเผยแพร่พอร์ตบน loopback: -p 127.0.0.1:5432:5432 จะผูกฝั่งโฮสต์เข้ากับ 127.0.0.1 ทำให้ไม่มีแหล่งภายนอกใดเข้าถึงได้ไม่ว่า ufw จะตั้งค่าไว้อย่างไรก็ตาม การเผยแพร่พอร์ต Docker โดยคำนึงถึง ufw ครอบคลุมกรณีที่บริการจำเป็นต้องเปิดให้สาธารณะเข้าถึงได้

กำหนดเวลาการย้อนกลับก่อนที่คุณจะใช้กฎ

นี่คือแนวทางปฏิบัติที่ช่วยให้การจัดการ firewall มีความปลอดภัย หากเกิดข้อผิดพลาดก่อนการเปลี่ยนแปลงที่มีความเสี่ยง ให้กำหนดเวลาการย้อนกลับไว้เสมอ หากการเปลี่ยนแปลงนั้นทำให้คุณไม่สามารถเข้าถึงระบบได้ เครื่องจะคืนค่าสถานะเดิมให้โดยอัตโนมัติภายใน 5 นาที และคุณไม่จำเป็นต้องเปิดใช้งาน console เลย

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

systemd จะแสดงผล Running timer as unit: ufw-rollback.timer จากนั้นให้คุณทำการเปลี่ยนแปลง หากคุณยังสามารถเปิด SSH session ใหม่ได้หลังจากนั้น ให้ยกเลิกการย้อนกลับ:

sudo systemctl stop ufw-rollback.timer

หากคุณไม่สามารถเปิด session นั้นได้ ให้รอ ufw จะปิดการทำงานลงด้วยตัวมันเอง และความพยายามครั้งถัดไปของคุณจะเชื่อมต่อได้สำเร็จ เทคนิค shutdown -r +5 แบบดั้งเดิมไม่สามารถช่วยแก้ปัญหากับ ufw ได้ เนื่องจาก ufw จะโหลดชุดกฎเดิมซ้ำอีกครั้งเมื่อบูตเครื่องใหม่

รักษาช่องทางเข้าถึงสำรองไว้

• ล็อกอินเข้าสู่คอนโซลของผู้ให้บริการหนึ่งครั้งก่อนที่คุณจะจำเป็นต้องใช้งานจริง เพื่อยืนยันว่ารหัสผ่านใช้งานได้ คอนโซลที่คุณไม่เคยทดสอบมาก่อนไม่ถือว่าเป็นช่องทางสำรอง
• สร้างผู้ใช้ที่มีสิทธิ์ sudo สำรองไว้อีกหนึ่งบัญชีโดยใช้คีย์แยกต่างหาก เพื่อป้องกันไม่ให้ไฟล์ authorized_keys ที่เสียหายเพียงไฟล์เดียวทำให้คุณสูญเสียสิทธิ์การเข้าถึงทั้งหมด
• ตรวจสอบว่าผู้ให้บริการของคุณมีการใช้งาน network firewall ในแผงควบคุมแยกต่างหากจาก ufw หรือไม่ เพราะมันจะบล็อกพอร์ตเดียวกันและ ufw status จะไม่แจ้งเตือนคุณเกี่ยวกับเรื่องนี้
• อย่ากำหนดให้ ufw allow from <your home address> เป็นกฎ SSH เพียงกฎเดียวของคุณหากที่อยู่ดังกล่าวเป็นแบบ dynamic เพราะผู้ให้บริการอาจเปลี่ยนที่อยู่ดังกล่าวในข้ามคืนและทำให้คุณเข้าถึงเซิร์ฟเวอร์ไม่ได้

ช่วงเวลาที่ประหยัดที่สุดในการดำเนินการทั้งหมดนี้คือตอนที่เซิร์ฟเวอร์ยังใหม่ โดยทำไปพร้อมกับงานตั้งค่าอื่นๆ ใน สิบนาทีแรกบน VPS ใหม่

การปฏิเสธการเชื่อมต่อหรือการหมดเวลาช่วยระบุว่าเลเยอร์ใดล้มเหลว

Connection refused หมายความว่าแพ็กเก็ตส่งถึงเซิร์ฟเวอร์แล้ว แต่มีบางอย่างส่ง TCP reset กลับมา เส้นทางเครือข่ายทำงานปกติ ดังนั้นสาเหตุคือ sshd หยุดทำงานหรือกำลังฟังพอร์ตอื่นอยู่ ไฟร์วอลล์มักไม่ใช่สาเหตุในกรณีนี้ เนื่องจาก ufw จะใช้วิธี drop แพ็กเก็ตเป็นค่าเริ่มต้นแทนการปฏิเสธ (reject)

Connection timed out หมายความว่าไม่มีการตอบกลับใดๆ เลย นี่คือลักษณะเฉพาะของการ drop แพ็กเก็ต ซึ่งเกิดจาก ufw, ไฟร์วอลล์ของเครือข่ายผู้ให้บริการ หรือการระบุที่อยู่ผิด การอ่านค่าความผิดพลาดทั้งสองแบบนี้อย่างถูกต้องช่วยประหยัดเวลาในการคาดเดาได้นับชั่วโมง และ ความแตกต่างระหว่างการปฏิเสธการเชื่อมต่อและการหมดเวลา จะช่วยอธิบายกรณีที่เหลือทั้งหมด

เปิดใช้งานการบันทึก log ก่อนทำการเปลี่ยนแปลงครั้งถัดไป

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

แพ็กเก็ตที่ถูกบล็อกจะมีลักษณะดังนี้:

[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= เป็นหลักฐานว่า ufw คือสิ่งที่บล็อกคุณ ไม่ใช่เครือข่ายและไม่ใช่ sshd ในอิมเมจแบบ minimal ที่ไม่มี rsyslog จะไม่มีไฟล์ /var/log/ufw.log และบรรทัดเดียวกันจะมาจาก sudo journalctl -k | grep UFW แทน ufw จะจำกัดอัตราการบันทึก log ของกฎตัวเอง ดังนั้นการที่บรรทัดหายไปไม่ได้เป็นหลักฐานว่าแพ็กเก็ตนั้นได้รับอนุญาตให้ผ่านได้

หากคุณพบกฎที่คุณไม่ได้เพิ่มเข้าไป

กฎที่เปลี่ยนแปลงไปเองไม่ใช่ปัญหาของ firewall แต่เป็นฝีมือของผู้ที่มีสิทธิ์ root ให้รัน sudo grep ufw /var/log/auth.log เพื่อดูว่ามีการใช้คำสั่ง sudo ใดบ้างและใช้ผ่านบัญชีใด จากนั้นใช้ last เพื่อตรวจสอบการเข้าสู่ระบบในช่วงเวลาดังกล่าว หากบัญชีเหล่านั้นไม่ตรงกับบุคคลที่คุณรู้จัก ให้หยุดการแก้ไขปัญหา firewall และ ดำเนินการตามรายการตรวจสอบสำหรับ VPS ที่ถูกบุกรุก แทน การเปิดใช้งาน firewall บนเครื่องที่ผู้อื่นควบคุมอยู่จะช่วยเพียงแค่ปกปิดปัญหาเท่านั้น

การประกอบระบบกลับคืน

เมื่อทราบสาเหตุแล้ว ให้เปิดใช้งาน ufw อีกครั้งด้วยวิธีที่ไม่ทำให้คุณถูกล็อกออกจากระบบ เริ่มจากการอนุญาตพอร์ต SSH ที่ใช้งานจริง กำหนดเวลาการย้อนกลับการตั้งค่า (rollback) เปิดใช้งาน ufw จากนั้นให้เปิดเซสชัน SSH ใหม่จากเทอร์มินัลอื่นเพื่อตรวจสอบว่าสามารถเชื่อมต่อได้จริง เมื่อยืนยันว่าเซสชันใหม่ใช้งานได้แล้วเท่านั้นจึงค่อยปิดเซสชันเดิมที่กำลังทำงานอยู่ ควรเปิดระบบบันทึก log ทิ้งไว้หนึ่งวัน เนื่องจาก log จะช่วยให้คุณทราบว่าลืมอนุญาตส่วนใดได้รวดเร็วกว่าการอ่าน user.rules มาก

FAQ

ufw disable จะลบกฎของฉันหรือไม่?

ไม่ disable จะทำการ unload กฎออกจาก kernel และเขียน ENABLED=no ลงใน /etc/ufw/ufw.conf กฎของคุณจะยังคงอยู่ใน /etc/ufw/user.rules และ /etc/ufw/user6.rules และ sudo ufw show added จะแสดงรายการกฎเหล่านั้นในขณะที่ firewall ไม่ทำงาน ufw reset คือคำสั่งที่ใช้ล้างกฎดังกล่าว โดยจะทำการสำรองข้อมูลแต่ละไฟล์ไว้ก่อน และแสดงข้อความเช่น Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

การรีบูต VPS จะช่วยแก้ปัญหาการถูกล็อกออกจาก ufw หรือไม่?

ไม่ ufw จะเริ่มทำงานตอนบูตจาก ENABLED=yes ใน /etc/ufw/ufw.conf ดังนั้นกฎเดิมจะถูกโหลดก่อนที่เครือข่ายจะพร้อมใช้งานและคุณจะถูกล็อกอีกครั้ง การรีบูตจะช่วยได้ก็ต่อเมื่อคุณปิด ufw ไปแล้ว หรือหลังจากที่คุณแก้ไขไฟล์นั้นจากโหมด rescue โดยที่ mount ดิสก์ไว้แล้ว ให้ใช้ console ของผู้ให้บริการและรัน sudo ufw disable ที่นั่น

ทำไม Docker container ของฉันถึงยังเข้าถึงได้ทั้งที่ ufw ปฏิเสธพอร์ตนั้นไว้?

Docker จะเขียนกฎ DNAT และ FORWARD ของตัวเองสำหรับทุกพอร์ตที่เปิดใช้งาน ทราฟฟิกดังกล่าวจะถูกส่งต่อไปยัง container แทนที่จะส่งมาที่ host ดังนั้นมันจึงไม่ผ่าน chain INPUT ที่กฎ deny ของ ufw ทำงานอยู่ ให้เปิดใช้งานบน loopback ด้วย -p 127.0.0.1:5432:5432 หากพอร์ตนั้นมีไว้สำหรับ host เท่านั้น และตรวจสอบสิ่งที่ Docker ติดตั้งไว้ด้วย sudo iptables -t nat -S DOCKER

ฉันไม่มีรหัสผ่าน console และไม่มีโหมด rescue ฉันมีทางเลือกอะไรบ้าง?

ทางเลือกที่เหลือขึ้นอยู่กับผู้ให้บริการของคุณ: การรีเซ็ตรหัสผ่านจากแผงควบคุม ซึ่งมักจะทำการรีบูตเซิร์ฟเวอร์ หรือการนำดิสก์ไปต่อกับ instance อื่นเพื่อให้คุณแก้ไข /etc/ufw/ufw.conf จากที่นั่นได้ โปรดสอบถามฝ่ายสนับสนุนก่อนที่คุณจะสร้างเซิร์ฟเวอร์ใหม่ (rebuild) เพราะการ rebuild จะทำลายข้อมูลทั้งหมดบนเซิร์ฟเวอร์ เมื่อคุณกลับเข้าใช้งานได้แล้ว ให้รัน sudo passwd yourname และทดสอบการล็อกอินผ่าน console หนึ่งครั้ง เพื่อให้การถูกล็อกในครั้งถัดไปใช้เวลาแก้ไขเพียงสองนาทีเท่านั้น