Hệ điều hành · 19/09/2026

Chẩn đoán lỗi mạng Linux từ A-Z với ip, ss, dig, curl và tcpdump

“Không vào được server” có thể là hàng chục lỗi khác nhau: interface down, sai IP, thiếu default route, DNS trả nhầm địa chỉ, service chỉ listen localhost, firewall drop packet, TLS sai SNI hoặc ứng dụng treo phía sau reverse proxy. Chạy ngẫu nhiên nhiều lệnh thường tạo thêm nhiễu.

“Không vào được server” có thể là hàng chục lỗi khác nhau: interface down, sai IP, thiếu default route, DNS trả nhầm địa chỉ, service chỉ listen localhost, firewall drop packet, TLS sai SNI hoặc ứng dụng treo phía sau reverse proxy. Chạy ngẫu nhiên nhiều lệnh thường tạo thêm nhiễu.

Cách hiệu quả là chẩn đoán từ lớp thấp lên cao, kiểm tra từng giả thuyết và so sánh từ cả phía client lẫn server. Bài viết dùng các công cụ phổ biến trên Linux: ip, ss, ping, dig, curl, openssl, traceroute và tcpdump.

Trước khi sửa: xác định phạm vi sự cố

Ghi lại bốn thông tin: ai bị ảnh hưởng, dịch vụ nào, bắt đầu lúc nào và thay đổi gì vừa diễn ra. Sau đó kiểm tra:

Một client hay mọi client?
Một hostname/port hay toàn bộ Internet?
IPv4, IPv6 hay cả hai?
Host vật lý, VM, container hay Kubernetes pod?
Chỉ từ mạng ngoài hay ngay cả localhost?

Không restart mọi thứ ngay. Restart có thể xóa trạng thái, log và connection hữu ích. Chụp lại output, timestamp và cấu hình trước khi thay đổi.

1. Kiểm tra interface và physical link

ip -br link
ip -br address
ip -s link show dev eth0

UP cho biết interface được bật về mặt quản trị; LOWER_UP cho biết kernel thấy carrier/link. Nếu thiếu LOWER_UP, kiểm tra cáp, switch port, virtual NIC, hypervisor hoặc Wi-Fi association.

ip -s link hiển thị packet, error, drop và overrun. Counter error/drop tăng nhanh có thể chỉ ra duplex, driver, MTU, buffer hoặc congestion. So sánh hai lần cách nhau vài giây thay vì chỉ nhìn số tuyệt đối.

sudo ethtool eth0
sudo ethtool -S eth0

Với server vật lý, ethtool giúp xem link detected, speed, duplex và driver statistics. Trên VM/container, một số trường có thể không có ý nghĩa như phần cứng thật.

2. Kiểm tra địa chỉ IP

ip address show
ip -4 address show dev eth0
ip -6 address show dev eth0

Xác nhận IP, prefix length, interface và trạng thái tentative/deprecated. Sai prefix có thể khiến host tưởng một địa chỉ remote nằm cùng subnet và ARP sai thay vì gửi qua gateway.

Nếu dùng DHCP:

networkctl status eth0
journalctl -u systemd-networkd --since '-15 min'
nmcli device show eth0

Chọn lệnh phù hợp network manager của hệ thống. Ubuntu Server thường quản lý cấu hình bền vững qua Netplan, nhưng backend có thể là systemd-networkd hoặc NetworkManager.

3. Kiểm tra route mà kernel thực sự chọn

ip route show
ip -6 route show
ip route get 1.1.1.1
ip route get 203.0.113.50 from 192.0.2.10

ip route get hữu ích hơn chỉ nhìn bảng route vì nó cho biết interface, gateway và source IP kernel sẽ dùng cho một destination cụ thể. Trên host nhiều NIC, policy routing có thể làm traffic đi khác dự kiến:

ip rule show
ip route show table all

Kiểm tra route trùng nhau, metric, default gateway và source-based rule. Asymmetric routing có thể khiến request vào một interface nhưng response ra interface khác và bị firewall/upstream drop.

4. Kiểm tra neighbor/ARP và gateway

ip neigh show
ping -c 3 192.0.2.1
arping -I eth0 -c 3 192.0.2.1

Trạng thái neighbor FAILED hoặc INCOMPLETE nghĩa host không phân giải được MAC của địa chỉ cùng link. Nguyên nhân có thể là sai VLAN, prefix, gateway, security group ở hypervisor hoặc thiết bị không cùng broadcast domain.

Ping bị chặn không chứng minh host down. ICMP là một tín hiệu; hãy tiếp tục thử đúng TCP port. Nhưng nếu ngay cả gateway cùng subnet không có ARP reply, lỗi nằm thấp hơn DNS/TLS.

5. Tách lỗi mạng và lỗi DNS

Thử kết nối bằng IP và hostname. Nếu IP hoạt động còn hostname không, tập trung vào resolver/DNS:

resolvectl status
resolvectl query api.example.com
dig api.example.com A
dig api.example.com AAAA
dig @1.1.1.1 api.example.com A
getent ahosts api.example.com

dig hỏi DNS trực tiếp; getent đi qua Name Service Switch giống nhiều ứng dụng, nên còn phản ánh /etc/hosts, mDNS hoặc resolver khác. So sánh hai kết quả khi ứng dụng và dig không giống nhau.

Kiểm tra A và AAAA. Một record IPv6 sai có thể làm client ưu tiên đường không hoạt động. Dùng curl -4 và curl -6 để cô lập:

curl -4 -v https://api.example.com/health
curl -6 -v https://api.example.com/health

Không sửa trực tiếp /etc/resolv.conf trên hệ thống mà file này do systemd-resolved/NetworkManager sinh ra; thay đổi sẽ bị ghi đè. Sửa Netplan hoặc network manager đúng chỗ.

6. Dịch vụ có listen đúng địa chỉ không?

sudo ss -lntup
sudo ss -lntp 'sport = :443'
sudo ss -lnup 'sport = :53'

Phân biệt:

127.0.0.1:8080: chỉ truy cập từ local namespace.
0.0.0.0:8080: listen mọi địa chỉ IPv4.
[::]:8080: listen IPv6; hành vi dual-stack phụ thuộc cấu hình.

Nếu không có socket listen, kiểm tra service và log:

systemctl status nginx --no-pager
journalctl -u nginx --since '-15 min' --no-pager

Service “active” chưa chắc listen port mong muốn; process có thể chạy nhưng bind sai IP, cấu hình upstream lỗi hoặc child worker chết.

7. Hiểu connection refused, timeout và reset

Connection refused: packet đến host và nhận TCP RST; thường không có listener hoặc firewall reject.
Timeout: không nhận phản hồi; có thể route, firewall drop, security group, NAT hoặc host down.
Connection reset: kết nối được tạo rồi một bên đóng cưỡng bức; xem application/proxy/TLS log.
No route to host: kernel không có route hoặc nhận ICMP unreachable; thông báo đôi khi cũng đến từ firewall reject.

nc -vz -w 3 api.example.com 443
curl -v --connect-timeout 3 https://api.example.com/health

curl -v cho biết DNS, IP được chọn, thời gian connect, TLS và HTTP. Không dùng -k như cách “sửa” TLS; nó chỉ bỏ verify và che giấu lỗi chứng chỉ.

8. Kiểm tra firewall ở mọi lớp

sudo ufw status verbose
sudo nft list ruleset
sudo iptables-save

Hệ thống có thể dùng nftables trong khi công cụ compatibility vẫn hiển thị iptables. Ngoài host còn có cloud security group, network ACL, load balancer, firewall vật lý và policy Kubernetes.

Không flush firewall từ xa trên production. Thêm rule có scope nhỏ, time-box nếu có thể, và giữ session SSH dự phòng. Bật log có chọn lọc vì log mọi packet có thể gây I/O lớn:

sudo ufw logging medium
journalctl -k --since '-10 min' | grep -i 'UFW'

9. Kiểm tra HTTP và TLS đúng hostname

curl -v https://api.example.com/health
curl --resolve api.example.com:443:203.0.113.20 \
  https://api.example.com/health

openssl s_client \
  -connect 203.0.113.20:443 \
  -servername api.example.com \
  -showcerts </dev/null

--resolve ép IP nhưng giữ hostname/SNI/Host header, rất hữu ích để test origin trước khi đổi DNS. Gọi trực tiếp https://IP có thể chọn sai virtual host và certificate.

Kiểm tra certificate chain, SAN, ngày hết hạn, SNI và redirect loop. Nếu reverse proxy trả 502/504, mạng client→proxy có thể hoàn toàn tốt; tiếp tục kiểm tra proxy→upstream bằng IP/port từ chính namespace proxy.

10. Đo đường đi và packet loss đúng cách

tracepath api.example.com
traceroute -T -p 443 api.example.com
mtr -rwzc 50 api.example.com

Router giữa đường có thể không trả ICMP nhưng vẫn forward traffic, nên dấu * không tự động là lỗi. Packet loss ở hop trung gian chỉ đáng lo nếu tiếp tục xuất hiện ở hop sau/destination. Ưu tiên TCP traceroute tới port thật khi ICMP bị lọc.

So sánh từ nhiều source. Một đường lỗi từ ISP A không chứng minh server lỗi toàn cục.

11. MTU và Path MTU Discovery

Dấu hiệu MTU mismatch: ping nhỏ được nhưng HTTPS/upload lớn treo, đặc biệt qua VPN, tunnel hoặc cloud overlay.

ip link show dev eth0
tracepath api.example.com
ping -M do -s 1472 -c 3 api.example.com

1472 byte + 28 byte IPv4 ICMP header tương ứng MTU 1500; với IPv6/header/tunnel con số khác. Giảm payload để tìm ngưỡng. Đừng đổi MTU vội nếu chưa xác nhận cả interface, tunnel và thiết bị trung gian. Firewall chặn ICMP “fragmentation needed” có thể làm PMTUD thất bại.

12. tcpdump: xem packet có thực sự đi qua đâu

sudo tcpdump -ni any host 203.0.113.20 and port 443
sudo tcpdump -ni eth0 'tcp port 443 and (tcp[tcpflags] & tcp-syn != 0)'
sudo tcpdump -ni any port 53

Đọc handshake:

Chỉ thấy SYN đi, không có SYN-ACK: lỗi trên đường, firewall drop hoặc server không trả.
Thấy SYN rồi RST: port bị từ chối/no listener.
Không thấy SYN rời host: DNS, route, local firewall hoặc application chưa gửi.
Server thấy SYN và gửi SYN-ACK nhưng client không thấy: đường về/asymmetric routing/upstream firewall.

Lưu capture ngắn để phân tích:

sudo timeout 30 tcpdump -ni any -s 0 \
  -w /tmp/network-issue.pcap \
  'host 203.0.113.20 and port 443'

PCAP có thể chứa credential, cookie và dữ liệu người dùng. Giới hạn filter/duration, bảo vệ file và xóa an toàn sau điều tra.

13. Container và network namespace

Kiểm tra từ host không đủ nếu ứng dụng chạy trong container/pod. Mỗi namespace có interface, route, DNS và firewall riêng:

docker exec -it app sh
ip address
ip route
cat /etc/resolv.conf
getent hosts database
nc -vz database 5432

Với Docker, 127.0.0.1 trong container là chính container, không phải host. Dùng service name trên network Compose. Kiểm tra network membership, published port và policy/NAT:

docker network inspect app_default
docker port app
sudo nsenter -t PID -n ss -lntp

Trong Kubernetes, kiểm tra pod DNS, Service selector/endpoints, NetworkPolicy và test từ debug pod cùng namespace.

14. Connection tracking và cạn port

Traffic cao có thể gặp conntrack full, ephemeral port exhaustion hoặc quá nhiều socket:

ss -s
ss -ant state time-wait | wc -l
cat /proc/sys/net/ipv4/ip_local_port_range
sudo conntrack -S
dmesg | grep -i conntrack

Không “sửa” bằng cách giảm TIME_WAIT hoặc tăng mọi sysctl theo bài blog. Tìm nguồn connection churn, thiếu keep-alive, NAT bottleneck hoặc connection pool sai trước; sau đó mới capacity-plan kernel limits.

15. Thay đổi cấu hình mạng an toàn từ xa

Sai Netplan có thể cắt chính SSH session. Trên Ubuntu, ưu tiên:

sudo netplan generate
sudo netplan try

netplan try yêu cầu xác nhận và có thể rollback khi mất kết nối. Tuy vậy vẫn cần console/out-of-band access cho server quan trọng. Backup file cấu hình, kiểm tra YAML và thay đổi từng phần nhỏ.

Playbook 10 phút

ip -br link và ip -br addr: link/IP đúng chưa?
ip route get DEST: route/source/interface nào được chọn?
ip neigh và ping gateway: cùng link có hoạt động?
dig + getent: DNS và resolver có đồng ý?
ss -lntup: service có listen đúng IP/port?
nc/curl -v: refused, timeout, TLS hay HTTP?
Kiểm tra host/cloud/container firewall.
curl --resolve: tách DNS khỏi HTTPS/SNI.
tcpdump ở client và server: packet dừng ở đâu?
Chỉ sửa sau khi có giả thuyết và cách rollback.

Kết luận

Chẩn đoán mạng Linux hiệu quả là quá trình loại trừ có thứ tự: link, IP, route, neighbor, DNS, socket, firewall, transport, TLS rồi ứng dụng. Mỗi công cụ trả lời một câu hỏi khác nhau; không có lệnh duy nhất chứng minh “mạng tốt”. Khi kiểm tra từ đúng namespace, quan sát cả hai chiều và lưu bằng chứng trước khi sửa, những sự cố tưởng ngẫu nhiên thường trở thành một điểm đứt rõ ràng.