Rào cản kết nối lúc 2 giờ sáng
Đang là giữa đêm. Bạn đang cố gắng đẩy một bản vá lỗi quan trọng lên một node production, nhưng terminal SSH chỉ đứng im. Thay vì yêu cầu mật khẩu, bạn nhận được một lời từ chối thẳng thừng:
ssh: connect to host 192.168.1.100 port 22: No route to host
Lỗi này thường xuyên bị hiểu lầm. Nó khác với "Connection refused", xảy ra khi máy chủ có thể truy cập được nhưng không có dịch vụ nào đang lắng nghe. "No route to host" chỉ ra một sự đứt gãy nghiêm trọng hơn trong stack mạng. Ở đâu đó giữa bàn phím của bạn và ổ đĩa của máy chủ, một thiết bị đang chủ động thông báo rằng không thể truy cập được đích đến.
Cô lập điểm đứt gãy
Đừng vội vàng khởi động lại router hay thay đổi địa chỉ IP ngay lập tức. Bạn cần tìm chính xác vị trí gói tin bị mất. Đó là do máy cục bộ, một router trung gian, hay cấu hình bảo mật nội bộ của máy đích?
1. Kiểm tra kết nối cơ bản
Bắt đầu với một lệnh ping đơn giản. Mặc dù các máy chủ được bảo mật thường bỏ qua các yêu cầu ICMP, nhưng một phản hồi thành công chứng minh rằng hệ thống dây vật lý và ảo vẫn nguyên vẹn.
ping -c 4 192.168.1.100
Hãy chú ý đến phản hồi cụ thể. Nếu terminal báo Destination Host Unreachable, máy cục bộ của bạn không biết sử dụng gateway nào. Nếu nó báo cụ thể No route to host, rất có thể bạn đang nhận được một gói tin "Communication Prohibited" (Cấm giao tiếp) từ tường lửa.
2. Kiểm tra bảng định tuyến
Kiểm tra đường dẫn cục bộ của bạn bằng lệnh ip route show. Bạn cần đảm bảo máy tính của mình biết cách xử lý subnet 192.168.1.0/24.
ip route show
Tìm kiếm subnet của máy đích. Nếu lưu lượng truy cập cho 192.168.1.100 đang mặc định đi qua một giao diện hướng ngoại (như eth0) thay vì VPN quản trị (như tun0), gói tin sẽ không bao giờ đến nơi.
Kẻ tình nghi thường gặp: Tường lửa phần mềm
Thông thường, lỗi này bắt nguồn từ cấu hình tường lửa của máy đích. Tường lửa Linux thường xử lý lưu lượng theo hai cách: DROP hoặc REJECT. Lệnh DROP khiến kết nối của bạn bị hết thời gian (timeout) trong im lặng. Tuy nhiên, lệnh REJECT sẽ gửi lại một gói tin ICMP nhỏ thông báo cho máy khách rằng tuyến đường đã bị đóng. Đây chính là nguyên nhân gây ra thông báo lỗi.
Khắc phục trên RHEL/CentOS/Fedora (Firewalld)
Trên các hệ thống dựa trên Red Hat, firewalld thường chặn mọi thứ theo mặc định trừ các dịch vụ cụ thể. Để kiểm tra xem đây có phải là nút thắt cổ chai hay không, hãy thử dừng dịch vụ tạm thời trong một mạng an toàn:
sudo systemctl stop firewalld
Nếu SSH kết nối được ngay lập tức, hãy khởi động lại tường lửa và cho phép cổng 22 một cách rõ ràng:
sudo systemctl start firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
Khắc phục trên Ubuntu/Debian (UFW)
Người dùng Ubuntu nên kiểm tra trạng thái của Uncomplicated Firewall (UFW):
sudo ufw status
Nếu trạng thái là active nhưng cổng 22 không có trong danh sách, hãy chạy các lệnh sau để mở cổng:
sudo ufw allow 22/tcp
sudo ufw reload
Bẫy Subnet
Mặt nạ mạng (mask) không khớp có thể dẫn đến sự im lặng hoàn toàn. Tôi đã từng dành ba giờ để debug một máy chủ có hai card mạng được gán cho các subnet 10.0.0.0/24 chồng chéo nhau. Kernel bị nhầm lẫn và cố gắng gửi lưu lượng phản hồi qua sai cổng, dẫn đến lỗi "No route" cho bất kỳ ai cố gắng kết nối.
Mẹo nhỏ: Kiểm tra kỹ toán học CIDR trước khi gán IP tĩnh. Tôi thường sử dụng Trình tính toán Subnet này để trực quan hóa dải host và địa chỉ broadcast. Đây là một công cụ dựa trên trình duyệt rất nhanh chóng giúp ngăn chặn những lỗi đánh máy đơn giản biến thành sự cố toàn mạng.
Xác minh cuối cùng
Đừng bao giờ mặc định rằng việc sửa lỗi đã thành công chỉ vì một lệnh thực hiện được. Sử dụng nc (netcat) để kiểm tra tình trạng của cổng từ một máy hoặc subnet khác:
nc -zv 192.168.1.100 22
Kết nối thành công sẽ trả về:
Connection to 192.168.1.100 22 port [tcp/ssh] succeeded!
Những điểm chính cần nhớ
- Reject vs. Drop: Nếu bạn thấy lỗi "No route to host", hãy tìm quy tắc
REJECTđang hoạt động. Nếu bạn thấy hết thời gian chờ (timeout), hãy tìm quy tắcDROP. - Đường phản hồi: Đảm bảo tường lửa của bạn cho phép lưu lượng
ESTABLISHED,RELATED, nếu không máy chủ sẽ không thể phản hồi lại bạn. - Kiểm tra nhật ký: Kiểm tra
/var/log/sysloghoặcjournalctl -u sshtrên máy đích. Nếu dịch vụ thậm chí không chạy, đường dẫn mạng không còn quan trọng nữa. - Không khớp VLAN: Nếu bạn đang kết nối từ một VPN, hãy đảm bảo tường lửa cho phép dải IP cụ thể của VPN gateway, không chỉ mạng LAN cục bộ.