Mở cổng bằng UFW và kiểm tra dịch vụ không truy cập được
Kiểm tra listener, địa chỉ bind, UFW và firewall VPS để tìm lỗi kết nối; giữ đường SSH quản trị và nhận biết giới hạn của UFW khi server có Docker.
Mở một cổng trên firewall không làm ứng dụng tự chạy. Một dịch vụ không truy cập được có thể do tiến trình chưa hoạt động, bind vào loopback, route sai, firewall trên máy hoặc chính sách từ nhà cung cấp VPS. Bài này dùng Ubuntu Server 24.04 LTS để kiểm tra từng lớp, rồi mới thay đổi UFW khi đã xác định đúng nhu cầu.
Xác định phạm vi trước khi mở cổng
Ghi lại tên dịch vụ, TCP hay UDP, cổng, địa chỉ nguồn được phép và cách xác nhận chức năng. Port 8080 trong bài chỉ dành cho HTTP server lab. Không mở any hoặc cả dải cổng chỉ vì chưa biết ứng dụng dùng gì.
Chuẩn bị console và giữ phiên SSH hiện tại. Kiểm tra server đang dùng UFW, nftables trực tiếp, firewalld hay một hệ quản trị khác. Không để nhiều công cụ cùng sửa policy mà không hiểu quan hệ giữa chúng. Trên VPS, firewall do nhà cung cấp quản lý nằm ngoài UFW và cần được kiểm tra riêng.
Ubuntu mô tả cách dùng công cụ trong Firewall. UFW là giao diện quản lý firewall; cơ chế kernel bên dưới có thể sử dụng backend khác nhau theo hệ thống. Bài này không thay thế bài nftables/iptables nâng cao trong chuyên mục.
Kiểm tra ứng dụng từ chính server
systemctl status lab-web.service --no-pager
sudo ss -lntp
curl --fail http://127.0.0.1:8080/
Nếu service đã dừng hoặc HTTP local lỗi, điều tra ứng dụng và journal trước. Firewall không sửa được binary sai, file cấu hình hỏng hoặc dependency chưa có. Với ứng dụng không phải HTTP, dùng client và health check đúng giao thức thay vì áp dụng curl cho mọi cổng.
Trong output ss, listener 127.0.0.1:8080 chỉ nhận kết nối loopback IPv4. Listener 0.0.0.0:8080 thường nhận trên mọi địa chỉ IPv4 cục bộ; nó không có nghĩa mọi client Internet chắc chắn truy cập được. IPv6 là phạm vi riêng cần đối chiếu; kết quả listen [::] còn phụ thuộc socket option và ứng dụng.
Để thử kết nối mạng với service mẫu ở bài systemd, cần sửa bind sang IP lab phù hợp hoặc 0.0.0.0, rồi daemon-reload và restart. Thay đổi này tăng phạm vi phơi dịch vụ và restart làm gián đoạn các kết nối đang xử lý. Chỉ làm trên mạng lab có kiểm soát; Python HTTP server mẫu không được dùng như dịch vụ production công khai.
Đọc policy hiện tại và giữ đường SSH
sudo ufw status verbose
sudo ufw status numbered
sudo ss -lntp
Nếu UFW inactive, các rule bạn thêm chưa có hiệu lực theo cách một firewall đang bật. Đừng bật ngay trước khi xác nhận cổng SSH thực tế, địa chỉ nguồn và đường khôi phục. Cổng SSH có thể khác 22 và có thể được chuyển tiếp từ cổng ngoài khác.
Trên lab mới, cần inbound SSH TCP 22 từ mạng quản trị đã xác định. Ví dụ dưới dùng địa chỉ tài liệu; phải thay bằng IP nguồn thật trước khi chạy:
sudo ufw allow from 192.0.2.50 to any port 22 proto tcp
Địa chỉ nguồn mà server nhìn thấy có thể là NAT hoặc VPN egress, không phải địa chỉ đang hiển thị trên card mạng của laptop. Nếu cấp nhầm nguồn, rule có vẻ đúng nhưng phiên mới vẫn bị chặn. Xác nhận qua log hoặc công cụ mạng, và chỉ dùng phạm vi subnet khi thật sự cần.
Mô hình kỹ thuật để giải thích cơ chế; không phải bằng chứng kiểm thử.
Thêm rule cho dịch vụ lab
Ví dụ cho HTTP TCP 8080 từ cùng máy quản trị:
sudo ufw allow from 192.0.2.50 to any port 8080 proto tcp
sudo ufw status numbered
Không sao chép địa chỉ 192.0.2.50 vào môi trường thật; nó chỉ minh họa cú pháp. Rule cho toàn Internet chỉ phù hợp với dịch vụ được chủ động công khai, có cấu hình và bảo vệ ứng dụng tương ứng. Firewall giới hạn ai kết nối được, không thay thế xác thực hoặc bảo mật của phần mềm.
Trên lab chưa có policy khác, sau khi đã có rule SSH đúng và console hoạt động, có thể thiết lập mặc định:
Các lệnh này thay đổi chính sách mạng của host. Chúng có thể làm mất đường quản trị hoặc chặn dịch vụ đang dùng nếu rule thiếu. Không chạy nguyên nhóm lệnh trên máy dùng chung trước khi kiểm kê toàn bộ dịch vụ, forwarded traffic và các policy có sẵn.
Xác nhận từ một client bên ngoài
Mở phiên SSH mới từ nguồn được cho phép, giữ phiên cũ. Sau đó thử HTTP bằng IP thật của server:
Trên Windows có thể kiểm tra TCP bằng Test-NetConnection SERVER_IP -Port 8080. Kết quả TCP thành công chỉ chứng minh kết nối tới cổng ở thời điểm đó; vẫn phải kiểm tra phản hồi ứng dụng đúng nội dung và protocol. Thử từ chính server bằng IP của nó không thay thế phép thử từ client bên ngoài.
Tiếp tục thử từ một nguồn không được phép trong lab. Chỉ kiểm tra positive case sẽ bỏ sót rule quá rộng. Không quét mạng doanh nghiệp hoặc dải IP của người khác để tìm máy thử; dùng client do bạn quản lý và trong phạm vi đã cho phép.
Phân loại lỗi để tránh sửa nhầm lớp
Connection refused: có thể host phản hồi nhưng không có listener phù hợp hoặc có cơ chế chủ động reject. Kiểm tra bind, port, protocol và service. Không kết luận UFW là nguyên nhân duy nhất.
Timeout: có thể là drop, route, địa chỉ đích sai hoặc đường về. Đối chiếu IP, cổng, firewall VPS và mạng trung gian. Ping không trả lời chưa chứng minh HTTP không hoạt động, vì ICMP có policy riêng.
HTTP trả 403 hoặc 500: TCP đã tới một HTTP service, nhưng vẫn cần xác định có đúng service dự kiến hay reverse proxy nào khác. Chuyển sang log ứng dụng hoặc proxy; mở thêm cổng không sửa lỗi phân quyền HTTP hay exception.
IPv4 chạy, hostname không chạy: kiểm tra DNS trả cả A và AAAA, listener IPv6 và policy tương ứng. Đừng tắt IPv6 toàn server chỉ để che khác biệt khi chưa biết ứng dụng hoặc mạng khác đang phụ thuộc vào nó.
Sơ đồ chẩn đoán: kiểm tra theo từng lớp trước khi thay đổi cấu hình.
Giới hạn quan trọng khi server có Docker
Docker tạo rule để thực hiện port publishing và kết nối container. Luồng tới cổng container được publish có thể không chịu bộ rule INPUT mà bạn tưởng UFW đang bảo vệ. Vì vậy, ufw status không đủ để kết luận một cổng container không công khai.
Theo Docker: Packet filtering and firewalls, cần hiểu rule do Docker tạo và không tùy tiện sửa chúng. Kiểm tra địa chỉ publish, policy nhà cung cấp và cơ chế firewall phù hợp với backend Docker đang dùng. Không áp dụng mù quáng một hướng dẫn DOCKER-USER cho mọi backend hoặc phiên bản.
Nếu chỉ cần truy cập qua reverse proxy trên host, cân nhắc bind cổng publish vào loopback khi kiến trúc cho phép. Đây là quyết định triển khai ứng dụng cần kiểm chứng riêng; nội dung chi tiết nằm ở chuyên mục Docker, không phải một rule UFW bổ sung là giải quyết hết.
Thu hồi rule và xác nhận phục hồi
Xem lại danh sách có số trước khi xóa một rule. Sau mỗi lần xóa, số thứ tự có thể đổi; không dùng một danh sách số cũ để xóa hàng loạt. ufw reset xóa cấu hình rule và không phải bước dọn mặc định khi chỉ cần bỏ một rule lab.
Hoàn thành khi client được phép truy cập chức năng đúng, client ngoài phạm vi bị chặn, phiên SSH mới hoạt động và bạn giải thích được từng rule đang giữ. Ghi lại nguồn, cổng, protocol, mục đích và người chịu trách nhiệm. Nếu kết nối liên quan VPN, router doanh nghiệp hoặc firewall nhà cung cấp ngoài quyền của bạn, chuyển bằng chứng kiểm tra từng lớp cho đội phụ trách.
Ghi lại rule để tránh tích lũy quyền mở không rõ mục đích
Mỗi rule nên có lý do, phạm vi nguồn và dịch vụ sở hữu. Khi một ứng dụng được gỡ, kiểm tra rule liên quan thay vì để mở mãi. Trên máy có nhiều người quản trị, đối chiếu thay đổi gần nhất trước khi xóa vì một rule trông giống dư thừa có thể phục vụ đường quản trị dự phòng.
Logging của firewall có thể giúp điều tra nhưng cũng tăng lượng log khi có nhiều gói bị chặn. Chọn mức ghi phù hợp và theo dõi dung lượng; không bật mức tối đa vô thời hạn chỉ để tìm một lỗi. Nếu dùng log làm bằng chứng, ghi thời điểm và cặp nguồn/đích cần kiểm tra, đồng thời tránh chia sẻ toàn bộ thông tin mạng nội bộ ra ngoài.
