Kiểm tra mạng Linux theo từng lớp bằng ip, ping, ss và curl; thực hành loopback và HTTP nội bộ, hiểu giới hạn của DNS, socket và phản hồi ứng dụng.
Một người dùng mở được trang nội bộ nhưng không mở được tên miền công ty. Máy khác ping thành công mà trình duyệt vẫn báo lỗi chứng chỉ. Nếu gom cả hai thành “mất mạng”, chúng ta dễ thay đổi sai thành phần và bỏ mất bằng chứng. Bài này hướng dẫn tách giao diện, địa chỉ, tuyến đường, phân giải tên và ứng dụng khi quan sát Linux.
Bạn sẽ đọc cấu hình bằng ip, tìm socket bằng ss, hiểu giới hạn của ping, rồi kiểm tra một dịch vụ HTTP do mình tạo. Cần biết shell, tiến trình và đường dẫn. Khung tham chiếu là mục 4.4 của 010-160, trang in 325–346, trang PDF 334–355; nội dung được đối chiếu với 014.4 của 010-200. Ngày cập nhật: 23/10/2026.
Lab chạy trên container Ubuntu 26.04.1 LTS ARM64, image có iproute2, iputils-ping, curl và Python 3. Container chạy với --network none, không gắn mạng host; thử nghiệm chỉ dùng loopback. Chúng ta chưa kiểm thử DHCP, DNS bên ngoài, đường truyền Internet, TLS hoặc IPv6 đầu cuối. Các truy vấn dành cho VM được ghi riêng, không nhận là kết quả đã chạy.
Giao diện mạng là điểm hệ thống trao đổi dữ liệu, chẳng hạn Ethernet, Wi-Fi hoặc giao diện ảo. Một máy có thể có nhiều giao diện và nhiều địa chỉ. Tên như eth0, enp1s0 hoặc wlan0 chỉ là ví dụ; hãy đọc danh sách trên đúng máy thay vì sao chép tên từ bài.
Địa chỉ IP phục vụ việc chuyển gói giữa các mạng. Cổng TCP hoặc UDP giúp phân biệt các điểm giao tiếp của ứng dụng trên một địa chỉ. DNS cung cấp những bản ghi tên cần thiết; nó không thay thế định tuyến hay làm cho dịch vụ tự chạy. Với HTTPS, việc xác thực chứng chỉ và trao đổi HTTP còn đặt thêm điều kiện sau bước kết nối.
Ví dụ giả định: trình duyệt cần truy cập một cổng thông tin nội bộ. Nó có thể lấy địa chỉ từ cơ chế phân giải tên, chọn đường tới địa chỉ đích, thiết lập kết nối và trao đổi dữ liệu ứng dụng. Proxy, VPN, bộ nhớ đệm và giao thức trình duyệt lựa chọn có thể làm đường đi thực tế khác ví dụ. Vì thế cần ghi URL, ứng dụng và bối cảnh, không chỉ một địa chỉ IP.
IPv4 dùng địa chỉ 32 bit, thường viết thành bốn nhóm thập phân như 192.168.50.10. Hậu tố /24 biểu diễn độ dài prefix, tương ứng mặt nạ 255.255.255.0 trong ví dụ này. Không suy ra hai địa chỉ cùng mạng chỉ vì chúng có ba nhóm đầu giống nhau khi chưa biết prefix.
Các dải IPv4 riêng thường gặp gồm 10.0.0.0/8, 172.16.0.0/12 và 192.168.0.0/16. Chúng có thể được dùng ở nhiều tổ chức, nên không xác định duy nhất một máy trên Internet công cộng. NAT có thể dịch địa chỉ khi đi qua biên mạng; cơ chế đó không thay thế chính sách firewall hoặc bảo mật ứng dụng.
IPv6 dùng địa chỉ 128 bit, viết theo nhóm thập lục phân. Ví dụ tài liệu 2001:db8:50::10/64 dùng ký hiệu rút gọn :: cho một chuỗi nhóm bằng không; chỉ dùng ký hiệu rút gọn này một lần trong địa chỉ. Prefix không phải lúc nào cũng dài 64 bit cho mọi loại tuyến hoặc mọi tình huống. Bài không hướng dẫn gán địa chỉ tài liệu lên mạng thật.
Loopback IPv4 127.0.0.1 và IPv6 ::1 chỉ về chính môi trường mạng đang sử dụng. Trong container, loopback là của namespace container, không tự trở thành loopback host. Địa chỉ IPv6 link-local chỉ có phạm vi liên kết; khi cần giao tiếp có thể phải chỉ rõ giao diện. Có IPv6 link-local chưa chứng minh có Internet IPv6.
DHCP có thể cấp cấu hình IPv4. Với IPv6, SLAAC theo RFC 4862 và DHCPv6 có vai trò riêng; thông tin router cũng liên quan Router Advertisement. Không áp nguyên mô hình DHCPv4 để suy ra mọi cấu hình IPv6. Ở mức Essentials, hãy nhận diện cách máy nhận cấu hình trước khi đề nghị sửa thủ công.
ipTheo manual ip của iproute2, công cụ này vừa truy vấn vừa thay đổi cấu hình mạng. Bài chỉ dùng các lệnh show:
ip -br link show
ip -br address show
ip -4 route show
ip -6 route show
-br cho dạng tóm tắt; hai lệnh cuối tách bảng định tuyến theo họ địa chỉ. Ghi tên giao diện, trạng thái và địa chỉ có prefix. Một giao diện báo UP chưa chứng minh có tuyến tới server hoặc ứng dụng truy cập được. Loopback có thể được báo trạng thái khác giao diện Ethernet mà vẫn hoạt động bình thường.
Tuyến mặc định là một lựa chọn cho đích không khớp tuyến cụ thể hơn trong bối cảnh định tuyến đang áp dụng. VPN hoặc nhiều bảng có thể làm việc chọn tuyến phức tạp hơn. Trong container không có mạng ngoài, bảng tuyến có thể không có default; đó là điều kiện lab chủ động tạo ra, không phải lỗi cần “sửa”.
Trên máy thật, đổi địa chỉ, flush tuyến hoặc down giao diện có thể làm mất kết nối SSH. Đừng chuyển từ quan sát sang thay đổi chỉ vì hướng dẫn cũ có lệnh ip addr add. ifconfig, route và netstat vẫn có thể xuất hiện trong tài liệu cũ; bài ưu tiên ip và ss, nhưng không tuyên bố công cụ cũ không còn chạy được.
Trong lab riêng đã chuẩn bị công cụ, chạy:
ip -br address show lo
ping -c 2 -W 1 127.0.0.1
getent hosts localhost
Mong đợi nhìn thấy 127.0.0.1, hai phản hồi echo trong lần kiểm tra này và kết quả tên cục bộ trỏ về loopback. -c 2 giới hạn số lần gửi, -W 1 đặt thời gian chờ theo iputils. Nếu hệ thống hạn chế ICMP, ghi nhận lỗi quyền; không cần mở rộng đặc quyền để hoàn thành mọi bước.
getent dùng cơ chế tra cứu tên của hệ thống theo cấu hình NSS. Kết quả localhost không chứng minh đã truy vấn DNS qua Internet. Tệp /etc/hosts có thể cung cấp ánh xạ cục bộ; cache hoặc nguồn tra cứu khác cũng có thể tham gia. Đừng lấy “tìm thấy tên” làm đồng nghĩa với “DNS server ngoài hoạt động”.
Ngay cả ping tới server thật thành công cũng chỉ là bằng chứng phản hồi ICMP ở thời điểm đó. Nó không kiểm tra tài khoản, cổng web, dữ liệu trả về hay chứng chỉ HTTPS. Ngược lại, không có echo reply có thể do chính sách lọc dù dịch vụ web vẫn hoạt động.
Chọn cổng 8080 trong môi trường lab trống. Python http.server phù hợp lab đơn giản, không được khuyến nghị cho production. Server chỉ bind loopback; thư mục phục vụ chỉ chứa fixture. Không chạy từ thư mục có tài liệu công việc hoặc dùng ví dụ này làm web server production.
work=$(mktemp -d)
printf '%s\n' 'LPI local fixture' > "$work/index.html"
python3 -m http.server 8080 --bind 127.0.0.1 \
--directory "$work" > "$work/server.log" 2>&1 &
server=$!
ss -ltn 'sport = :8080'
Server có thể cần một khoảng ngắn để khởi động; nếu chưa thấy socket, chờ rồi truy vấn lại. Theo manual ss, -l chọn socket lắng nghe, -t giới hạn TCP và -n giữ địa chỉ/cổng ở dạng số. Kết quả mong đợi có 127.0.0.1:8080. Socket lắng nghe chưa chứng minh nội dung ứng dụng đúng.
curl --noproxy '*' --connect-timeout 2 --max-time 5 \
-sS http://127.0.0.1:8080/
curl --noproxy '*' --connect-timeout 2 --max-time 5 \
-sS -o "$work/not-found.html" -w '%{http_code}\n' \
http://127.0.0.1:8080/missing
Yêu cầu đầu trả nội dung LPI local fixture; yêu cầu sau trả mã HTTP 404. Trong ví dụ này, 404 cho thấy server đã nhận và xử lý yêu cầu nhưng không tìm thấy tài nguyên, khác với không thiết lập được kết nối. Không mặc định curl trả mã thoát lỗi cho mọi HTTP 4xx; tùy chọn --fail thay đổi cách xử lý này.
Theo manual curl, các tùy chọn timeout giới hạn thời gian thao tác. --noproxy '*' chỉ để lab loopback không đi qua proxy từ môi trường; không dùng nó để bỏ chính sách proxy của tổ chức. Đây là HTTP cục bộ, không phải bằng chứng về mã hóa TLS hoặc xác thực chứng chỉ.
Dọn đúng tiến trình tự tạo sau khi xong:
kill -TERM "$server"
wait "$server"
Nếu server không khởi động được vì cổng bận, đọc server.log; không dừng tiến trình khác để chiếm cổng. PID phải còn thuộc công việc lab vừa tạo. Có thể kiểm tra lại bằng ps như bài tiến trình.
Trên VM dùng systemd-resolved, manual resolvectl cung cấp truy vấn cấu hình DNS đang có hiệu lực:
resolvectl status
Đây là hướng dẫn đối chiếu tài liệu, chưa chạy trong container của bài. Công cụ cần dịch vụ tương ứng; có binary chưa đủ chứng minh dịch vụ hoạt động. Xem phiên bản tại máy vì đường dẫn tài liệu latest có thể mô tả phiên bản khác.
Bạn có thể đọc ls -l /etc/resolv.conf để biết đó có phải liên kết và xem nội dung nếu có quyền. Một địa chỉ resolver loopback có thể là stub nhận truy vấn tại máy, không phải địa chỉ DNS upstream. Tệp cũng có thể do NetworkManager, systemd-resolved hoặc nền tảng container quản lý. Sửa trực tiếp dễ bị ghi đè hoặc làm mất cấu hình theo từng liên kết.
host là công cụ truy vấn DNS thường gặp trong giáo trình; kết quả truy vấn DNS trực tiếp không nhất thiết giống thứ ứng dụng nhận qua toàn bộ cơ chế NSS. Khi kiểm tra tên nội bộ, chỉ dùng máy chủ DNS được tổ chức cho phép. Không gửi tên máy hoặc tên miền riêng ra resolver công cộng để “thử nhanh”.
Khi chuyển ticket, ghi môi trường, thời điểm, URL hoặc đích được phép kiểm tra, dữ kiện từng lớp và điều chưa kiểm chứng. Che dữ liệu nội bộ không cần thiết trước khi chia sẻ. Chỉ đề xuất thay đổi cấu hình khi bằng chứng chỉ ra thành phần cần sửa và đã hiểu tác động.
Bốn giáo trình là khung học; bài và fixture được viết độc lập. Đối chiếu mục tiêu Linux Essentials hiện hành của LPI, manual iproute2 và tài liệu dự án được liên kết tại phần tương ứng. Lab xác nhận loopback IPv4, tra tên cục bộ, socket TCP, nội dung HTTP và 404. Chưa nghiệm thu mạng LAN, Wi-Fi, VPN, DNS ngoài, SLAAC/DHCP hoặc TLS; các phần đó là kiến thức nền và hướng dẫn quan sát có điều kiện.
Thực hành Linux với ticket giả lập: tạo script đếm, kiểm tra lỗi, giới hạn dữ liệu, phục hồi TAR và xác minh báo cáo HTTP loopback bằng so sánh byte.
Hiểu thư mục tạm và tệp đặc biệt Linux; thử mktemp, sticky bit, hard link và symlink, kiểm tra đích sau di chuyển và phân biệt liên kết với backup.
Đọc quyền tệp Linux, owner và group; thử chmod, chown, search thư mục và umask bằng tài khoản không root, phân biệt ghi nội dung với xóa tên tệp.
Tạo người dùng Linux và nhóm trong lab riêng; kiểm tra home, skeleton, nhóm bổ sung, khóa mật khẩu và phạm vi xóa tài khoản trước khi áp dụng thực tế.