Phân tích sự cố mạng văn phòng từ đầu đến cuối

“Mạng phòng kế toán bị lỗi” là một yêu cầu khó xử lý nếu chỉ có câu mô tả đó. Một máy không nhận đúng địa chỉ, máy khác mở được website bằng kết nối cũ nhưng truy vấn tên mới thất bại, còn máy thứ ba tới được máy chủ nhưng bị trình duyệt từ chối chứng chỉ. Cùng biểu hiện không dùng được ứng dụng, ba trường hợp cần ba hướng kiểm tra khác nhau.

Bài cuối ghép kiến thức của bộ CCNA thành một quy trình làm việc: xác định phạm vi, chọn phép thử có khả năng phân biệt giả thuyết, thay đổi tối thiểu rồi nghiệm thu từ góc nhìn người dùng. Mọi địa chỉ, thời điểm và kết quả dưới đây là tình huống biên tập. Chúng không phải nhật ký chạy lệnh hay packet capture từ hệ thống thật.

1. Đặt mô hình và tiêu chí thành công trước khi chạy lệnh

Mạng mẫu dùng IPv4, máy Windows 11 có Windows PowerShell và các module NetTCPIP, DnsClient. Switch Cisco IOS/IOS XE có tên cổng theo mẫu Catalyst; người quản trị phải đối chiếu cú pháp với model và release của mình. Máy kế toán thuộc VLAN 20, subnet 10.20.0.0/24, gateway 10.20.0.1. VLAN 30 dùng 10.30.0.0/24. DNS nội bộ là 10.99.0.53, portal là portal.example.test, bản ghi A dự kiến 10.30.30.77.

Đây là lab tên miền riêng, cần tự triển khai zone và dịch vụ; tên này không thể được kỳ vọng phân giải trên Internet. Đường tới portal nội bộ không cần NAT. Không đưa WAN vào giả thuyết khi lưu lượng đích chỉ đi giữa các mạng riêng. Ví dụ chỉ xét IPv4 trực tiếp, không VPN, proxy hoặc DoH; môi trường có các thành phần này cần ghi nhận thêm đường đi thực tế.

Thành công được định nghĩa là máy đúng VLAN nhận cấu hình hợp lệ, phân giải đúng tên và mở phiên HTTPS mới tới portal bằng tên, rồi hoàn thành thao tác nghiệp vụ được phép. Ping thành công hoặc biểu tượng mạng hết dấu cảnh báo chỉ là kết quả trung gian.

Cuộn ngang khi cần, hoặc chạm sơ đồ để mở ảnh gốc.

2. Thu thập phạm vi và giữ lại bằng chứng ban đầu

Hỏi máy nào lỗi, dịch vụ nào lỗi, bắt đầu lúc nào và có thay đổi gì trước đó. Ghi thời gian kèm múi giờ, tên máy, interface đang dùng, người thực hiện và phép thử. Một máy lỗi sau khi chuyển bàn gợi ý nhánh access port; nhiều VLAN cùng lỗi DNS gợi ý thành phần dùng chung. Đây là cách ưu tiên kiểm tra, chưa phải kết luận nguyên nhân.

Chọn một máy hoạt động làm đối chứng khi được phép. So cùng tên đích, loại bản ghi, cổng, thời điểm và phương thức truy cập. Máy đối chứng dùng Wi-Fi khách hoặc VPN khác đường không đủ để kết luận access switch của máy lỗi hỏng. Trình duyệt còn phiên cũ cũng không tương đương một kết nối mới.

Get-NetIPConfiguration
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
arp -a

Các lệnh đọc trên giúp ghi cấu hình, adapter, route và bảng ánh xạ hiện có. Kiểm tra interface index để tránh lấy route của adapter ảo làm đường đi ứng dụng. Bản ghi ARP chỉ thể hiện trạng thái cache tại thời điểm đọc; có MAC không chứng minh HTTPS hoạt động, thiếu MAC trước khi phát sinh lưu lượng cũng chưa chứng minh lỗi.

Không xóa cache, renew DHCP hay reset mạng trước khi lưu tình trạng. Những thao tác ấy có thể làm mất dấu vết hoặc gián đoạn phiên làm việc. Khi cần capture, xin quyền theo quy trình tổ chức, giới hạn interface, bộ lọc và thời gian; file có thể chứa thông tin nội bộ. Bài này không yêu cầu debug toàn bộ thiết bị production.

3. Sự cố A: máy nhận IP hợp lệ nhưng nằm sai mạng

Trong ca A, PC-A vừa chuyển bàn. Kịch bản cho biết máy nhận 10.30.0.120/24, gateway 10.30.0.1 thay vì cấu hình kế toán. Địa chỉ hợp lệ về số học không có nghĩa đúng chính sách. Hỏi vị trí ổ cắm, xác nhận patch panel và cổng switch trước khi sửa pool DHCP của cả mạng.

show interfaces GigabitEthernet1/0/8 status
show interfaces GigabitEthernet1/0/8 switchport
show vlan brief
show mac address-table interface GigabitEthernet1/0/8

Đây là lệnh đọc tham khảo trên switch phù hợp. Đối chiếu operational mode, access VLAN và MAC nguồn của PC với hồ sơ cổng. Kết quả giả định của ca A là access VLAN 30, trong khi hồ sơ vị trí yêu cầu VLAN 20. Với port phone, voice VLAN, 802.1X hoặc dynamic VLAN, cần kiểm tra policy/session riêng; không suy từ một dòng cấu hình tĩnh.

Chỉ sau khi xác nhận sai gán cổng mới lập thay đổi đưa port về VLAN 20 theo thiết kế, giữ bản cấu hình trước để quay lại. Việc đổi VLAN cắt kết nối hiện tại; người dùng có thể cần kết nối lại hoặc renew lease để nhận IP của mạng mới. Không đặt IP tĩnh tùy ý để che lỗi access VLAN, vì cách đó có thể tạo xung đột và bỏ qua quản lý địa chỉ.

Nghiệm thu ca A gồm đúng VLAN vận hành, địa chỉ thuộc VLAN 20, gateway và DNS đúng, rồi truy cập portal bằng phiên mới. Nếu DHCP vẫn không cấp địa chỉ, mở nhánh DORA/relay tại bài DHCP; không coi việc sửa VLAN đã giải quyết mọi nguyên nhân còn lại.

4. Sự cố B: tách phân giải tên khỏi kết nối TCP

Ca B độc lập: PC-B đã có 10.20.0.121/24, gateway đúng. Mục tiêu là so truy vấn DNS cụ thể với thử TCP trực tiếp tới địa chỉ portal dự kiến. Microsoft mô tả Resolve-DnsName cho phép chọn loại bản ghi và DNS server, phù hợp để làm phép thử có điều kiện rõ ràng.

Resolve-DnsName portal.example.test. -Type A -Server 10.99.0.53 -DnsOnly
Test-NetConnection 10.30.30.77 -Port 443 -InformationLevel Detailed

Giả định truy vấn đầu timeout còn phép thử thứ hai có TcpTestSucceeded : True. Hai kết quả thu hẹp hướng điều tra: tại thời điểm đó, kết nối TCP tới IP/cổng này thành lập được, còn giao dịch DNS được chọn chưa hoàn tất. Chúng chưa phân biệt được resolver ngừng dịch vụ, ACL chặn DNS, đường về thiếu hay mất gói.

Tiếp tục đối chiếu từ máy cùng VLAN và VLAN khác, kiểm tra sức khỏe resolver cùng log tương ứng, rồi đọc policy trên đường đi. Trong ca B, giả định hồ sơ thay đổi và policy đã xác minh cho thấy rule DNS từ VLAN 20 bị bỏ sót. Đây mới là bằng chứng cấu hình hỗ trợ nguyên nhân, thay vì lấy timeout làm bằng chứng ACL duy nhất.

Khôi phục rule được phê duyệt cho DNS đúng nguồn/đích và giao thức theo thiết kế; DNS có cả UDP và TCP. Kiểm tra truy vấn mới nhận đúng A, sau đó thử ứng dụng. Không đổi hàng loạt sang DNS công cộng vì tên riêng có thể không tồn tại ở đó, đồng thời việc đổi resolver có thể phá split DNS và chính sách doanh nghiệp.

Nếu thấy NXDOMAIN thay vì timeout, nhánh phân tích đổi sang dữ liệu tên/zone và phản hồi âm. Nếu trả IP khác dự kiến, đối chiếu bản ghi có thẩm quyền, TTL, cache và môi trường triển khai trước khi kết luận sai. Bài DNS giải thích chi tiết các lớp phản hồi này.

Cuộn ngang khi cần, hoặc chạm sơ đồ để mở ảnh gốc.

5. Sự cố C: TCP đạt nhưng ứng dụng vẫn thất bại

Ca C độc lập có IP, DNS và TCP tới portal đúng. Trình duyệt báo tên chứng chỉ không phù hợp. Kết quả TCP True không chứng minh TLS, HTTP, đăng nhập hoặc nghiệp vụ thành công; chức năng của Test-NetConnection dừng ở phép thử kết nối được lựa chọn.

Ghi mã lỗi và tên host trên thanh địa chỉ, thời gian máy, thông tin chứng chỉ được trình duyệt cho phép xem và thời điểm xảy ra. Không hướng dẫn người dùng bỏ kiểm tra chứng chỉ để “xác nhận mạng tốt”. Chủ dịch vụ cần đối chiếu hostname yêu cầu với chứng chỉ được endpoint thực tế trả về và cấu hình binding/reverse proxy. Đây là bước chuyển giao có dữ liệu, không phải quy trách nhiệm theo cảm tính.

Trong ca C, giả định nhóm dịch vụ xác nhận binding dùng chứng chỉ dành cho tên khác sau một lần thay đổi. Sau khi họ sửa đúng endpoint, nghiệm thu lại bằng tên portal, phiên mới và luồng nghiệp vụ. Nếu mở bằng IP, browser có thể thay đổi Host/SNI hoặc gặp lỗi chứng chỉ khác; phép thử ấy không tương đương truy cập bằng tên.

Khi cần xác định phạm vi IP, có thể dùng ping 10.30.30.77 và tracert -d 10.30.30.77 trên Windows. Cisco giải thích ping và traceroute dựa trên các phản hồi tương ứng, cần cả chiều về. Dấu sao không xác định duy nhất nơi rơi lưu lượng ứng dụng; thiết bị có thể hạn chế phản hồi hoặc policy xử lý probe khác dữ liệu TCP.

Nguồn probe cũng quan trọng. Ping từ router có thể dùng địa chỉ khác PC và chịu policy khác. Hãy ghi nguồn, đích, giao thức, cổng và thời điểm của từng phép thử. Không lấy ping router thành công để phủ nhận lỗi người dùng, cũng không lấy ping timeout để kết luận server tắt.

6. Thay đổi có giới hạn, nghiệm thu và chuyển giao

Trước một thay đổi, ghi giả thuyết, bằng chứng, phạm vi ảnh hưởng, người phê duyệt và điều kiện rollback. Một lần chỉ sửa phần cần thiết để kiểm chứng. Nếu đồng thời đổi VLAN, DNS và ACL, việc phục hồi không cho biết sửa nào có tác dụng, còn việc xấu đi khó quay lại chính xác.

Nghiệm thu từ PC đã lỗi và một máy đối chứng bằng phép thử tương đương ban đầu. Lặp lại giao dịch mới, kiểm tra cả thao tác đọc và ghi được phép nếu ứng dụng yêu cầu. Theo dõi khoảng thời gian phù hợp mức độ gián đoạn; một lần tải trang không chứng minh ổn định lâu dài hay không còn mất gói.

Cuộn ngang khi cần, hoặc chạm sơ đồ để mở ảnh gốc.

• Ghi hiện tượng và ảnh hưởng nghiệp vụ, tránh chỉ ghi “mạng lỗi”.
• Đính kèm thời gian, nguồn/đích, interface, giao thức và kết quả đã lọc thông tin nhạy cảm.
• Tách điều đã quan sát khỏi điều còn nghi ngờ; nêu phép thử kế tiếp có thể bác bỏ giả thuyết.
• Lưu thay đổi, cách quay lại, kết quả sau sửa và người xác nhận phục hồi.

7. Tự đánh giá và nguồn đối chiếu

Hãy tự giải thích vì sao ca A cần kiểm tra cổng trước pool, ca B chưa được kết luận ACL chỉ từ timeout, và ca C không nên tiếp tục reset mạng. Nếu trả lời được kèm phép thử bác bỏ, bạn đang dùng kiến thức CCNA để suy luận thay vì nhớ một danh sách lệnh.

Checklist cuối: đúng phạm vi và mô hình; có baseline trước sửa; địa chỉ và policy khớp; kết quả ghi đủ điều kiện; thay đổi được kiểm soát; ứng dụng được nghiệm thu; hồ sơ bàn giao không chứa secret. Với sự cố tái diễn, quay lại log và timeline tại bài vận hành, rồi dùng lộ trình CCNA để bổ sung phần kiến thức còn thiếu.

Nguồn PDF ccna_full234.pdf: trang vật lý 186–189 trình bày ICMP, echo request/reply và khả năng thông điệp không tới nguồn; trang 191–192 nói về unreachable. Bài này chỉ dùng nền tảng đó. Quy trình ba ca, lệnh PowerShell, giới hạn phép thử ứng dụng và hồ sơ bàn giao là phần biên tập bổ sung theo các nguồn chính thức đã liên kết. Không dùng các khuyến nghị IGRP hoặc diễn giải TTL cũ trong PDF làm hướng dẫn hiện hành.