Khắc phục sự cố các vấn đề kết nối trong mạng (Phần II)

Khắc phục sự cố các vấn đề kết nối trong mạng (Phần 3)

Trong phần trước của loạt bài này, chúng tôi đã giới thiệu cho các bạn cách phân biệt địa chỉ IP nào hệ thống của bạn đang sử dụng với tư cách là địa chỉ chính. Bước tiếp theo trong quá trình là thẩm định cấu hình địa chỉ IP có làm việc chính xác và không xuất hiện vấn đề nào đối với ngăn xếp giao thức TCP/IP hay không.
Bài test đầu tiên mà bạn cần thực hiện là ping một địa chỉ host nội bộ. Ở đây có một số cách khác nhau để có thể thực hiện nhiệm vụ này. Cách thứ nhất là nhập lệnh dưới đây:
PING LOCALHOST
Khi nhập vào lệnh này, Windows sẽ ping đến địa chỉ 127.0.0.1. Không quan tâm đến địa chỉ IP của máy bạn, Windows luôn sử dụng địa chỉ 127.0.0.1 như một địa chỉ host nội bộ. Chính vì vậy, giải pháp khác thay thế cho lệnh trên là nhập vào lệnh dưới đây:
Ping 127.0.0.1
Sau khi nhập vào lệnh này, bạn sẽ thấy một quá trình ping thành công giống như các lệnh ping khác. Hãy xem ví dụ thể hiện trong hình A.

Hình A: Bạn sẽ nhận được một ping thành công khi thực hiện ping địa chỉ host nội bộ
Việc ping địa chỉ host nội bộ không có tác dụng gì trong việc chuẩn đoán các vấn đề truyền thông với host ở xa. Mặc dù vậy nó lại cho phép bạn xác nhận rằng ngăn xếp TCP/IP nội bộ của bạn đang thực hiện đúng chức năng. Nếu bạn ping địa chỉ host nội bộ và nhận được một thông báo lỗi cho biết không xác nhận được đích thì trường hợp này TCP/IP đã bị cấu hình sai hoặc một phần nào đó của ngăn xếp TCP/IP nội bộ bị hỏng.
Ping Gateway mặc định
Trong phần trước của loạt bài này, chúng tôi đã đề cập rằng, có một số khía cạnh khác nhau đối với việc cấu hình TCP/IP và trang bị một chút kiến thức khắc phục sự cố. Bên cạnh đó là một số thông tin hoặc địa chỉ IP của Gateway mặc định và của máy chủ DNS chính.
Giả dụ rằng các host mà bạn muốn truyền thông nằm trên một mạng từ xa, hoặc trên một đoạn mạng khác của công ty bạn thì điều tiếp theo mà bạn cần thực hiện là ping Gateway mặc định. Bạn có thể thực hiện thao tác này bằng cách gắn thêm địa chỉ IP của cổng mặc định vào lệnh ping. Cho ví dụ, quan sát trong hình B bạn sẽ thấy rằng cấu hình TCP/IP liệt kê địa chỉ Gateway mặc định là 147.100.100.100. Chúng tôi đã ping đến địa chỉ này. Thao tác này đã thẩm định rằng máy nội bộ có thể truyền thông với Gateway mặc định. Nó cũng cho bạn biết rằng sự truyền thông trên mạng nội bộ hiện đang làm việc như dự định, chí ít cũng ở mức địa chỉ IP.

Hình B: Ping gateway mặc định đã thẩm định được rằng các gói IP có thể đến được
cổng mặc định của mạng.
Ping DNS Server
Cho đến đây, chúng ta đã xác minh được rằng truyền thông ở mức địa chỉ IP hiện đang làm việc giữa máy tính nội bộ và Gateway mặc định. Mặc dù vậy điều này vẫn không bảo đảm rằng các hostname hiện đang thể hiện các địa chỉ IP. Trong phần thứ nhất của loạt bài này, chúng tôi đã giới thiệu cho các bạn về cách sử dụng tên miền đầy đủ của host đích kết hợp với lệnh ping để thẩm định rằng máy chủ DNS hiện đang thực hiện công việc của nó. Tuy nhiên ở đây còn có một số cách khác dễ dàng test DNS.
Một thứ bạn có thể thực hiện ở đây là ping đến địa chỉ IP của máy chủ DNS, xem thể hiện trong hình C. Tuy thao tác này không bảo đảm DNS hiện có làm việc đúng cách hay không nhưng nó cũng thẩm định được rằng máy tính nội bộ có thể truyền thông với máy chủ DNS.

Hình C: Bạn cần thẩm định rằng host có thể truyền thông với máy chủ DNS
Một vấn đề khác nữa bạn có thể thực hiện là sử dụng lệnh Nslookup để thẩm định rằng DNS đang làm việc đúng cách. Để thực hiện theo thao tác này, bạn chỉ cần nhập vào lệnh Nslookup, sau đó là tên miền đầy đủ của host từ xa. Lệnh Nslookup có thể phân tích tên miền hoàn chỉnh thành địa chỉ IP, xem thể hiện trong hình D.

Hình D: Lệnh Nslookup thông báo cho bạn biết DNS server
có thể phân giải hostname hay không.
Hình trên có thể khiến bạn một chút bối rối lúc đầu nếu bạn không quen làm việc với Nslookup. Ban đầu, màn hình này sẽ xuất hiện một báo cáo lỗi. Nếu quan sát kỹ hơn bạn sẽ thấy phần thông đầu tiên được trả về nói đến máy chủ DNS nội bộ. Điều này là vì địa chỉ IP được tham chiếu tương xứng với địa chỉ IP của máy chủ DNS. Mặc dù vậy, phần bên dưới các thông tin trả về lại cung cấp cho bạn địa chỉ IP của host mà bạn yêu cầu. Miễn là địa chỉ IP này được liệt kê thì truy vấn DNS của bạn đã thành công.
Nếu quá trình phân giải tên miền thất bại, khi đó có một vấn đề về DNS. Vấn đề thực có thể là một trong số các vấn đề đối với máy chủ DNS. Cho ví dụ, các máy chủ DNS đang chuyển tiếp địa chỉ có thể sai, hoặc máy chủ DNS có thể không truy cập được Internet (mức truy cập cần liên lạc với máy chủ DNS mức cao hơn). Cũng có thể dịch vụ DNS của máy chủ DNS có thể bị ngưng. Các kiểu vấn đề này cũng có thể ảnh hưởng đến các máy khách khác vì nhiều máy khách thường phụ thuộc vào một máy chủ DNS nào đó.
Nếu sự phân giải tên miền DNS thành công thì bạn cần phải thẩm định địa chỉ IP được trả về trong suốt quá trình phân tích. Bạn có thể thực hiện điều này bằng cách so sánh địa chỉ IP được trả về với địa chỉ IP thực mà host từ xa đang sử dụng. Các địa chỉ IP này cần phải tương xứng với nhau, tuy nhiên có một số điều kiện có thể gây ra sự sai lệnh, khi đó kết quả truyền thông sẽ bị thất bại.
Nếu bạn bắt gặp một sự sai lệnh về địa chỉ IP thì điều đó có thể là kết quả của tình trạng bị malware xâm nhập vào máy khách, hoặc có thể là kết quả của sự tiêm nhiễm của DNS. Sự tiêm nhiễm DNS là một quá trình trong đó DNS cache sẽ được phổ biến các địa chỉ IP sai hoặc không hợp lệ.
Nếu bạn bắt gặp vấn đề như vậy, chúng tôi khuyên bạn nên quét malware trên máy khách. Bên cạnh đó bạn cũng có thể quét luôn cả spyware và virus vì chúng cũng có thể gây ra vấn đề kiểu như vậy. Khi máy khách hoàn toàn sạch sẽ, hãy làm sạch DNS cache. Bạn có thể làm sạch DNS cache bằng cách nhập vào lệnh dưới đây:
IPCONFIG /FLUSHDNS
Bạn có thể xem ví dụ về lệnh này trong hình E.
Có một lưu ý quan trọng các bạn cần lưu ý ở đây là DNS cache có thể chứa các địa chỉ IP không đúng nhưng nó không có nghĩa rằng DNS bị nhiễm độc. Đôi khi các host được gán các địa chỉ IP mới, điều này làm cho DNS cache đôi khi chưa biết về những thay đổi đó.

Hình E: Nếu bạn nghi ngờ DNS cache chứa các thông tin sai, hãy thực hiện các biện pháp quét và làm sạch Internet
Kết luận
Trong phần này, chúng tôi đã giới thiệu cho các bạn cách thẩm định ngăn xếp giao thức TCP/IP nội bộ có làm việc đúng hay không. Tiếp đó là giải thích về cách test khả năng của host nội bộ về khả năng liên lạc với máy chủ DNS và máy chủ gateway mặc định và cách test Hostname. Trong phần tiếp theo của loạt này, chúng tôi sẽ giới thiệu cho các bạn về một số vấn đề hay gặp trong sử dụng lệnh Ping, cụ thể là sẽ thảo luận về các vấn đề định tuyến.




Khắc phục sự cố các vấn đề kết nối trong mạng (Phần 4)

Cho tới đây trong loạt bài này, chúng tôi đã giới thiệu cho các kiểu thao tác để bạn có thể thực hiện đối với lệnh ping để chuẩn đoán các vấn đề kết nối mạng. Trong phần này, chúng tôi sẽ tiếp tục giới thiệu bằng một số biến thể khác của kỹ thuật này.
Mất gói dữ liệu
Khi chúng ta đã sử dụng lệnh ping, cho dù lệnh có có được thực hiện thành công hoặc bị thất bại thì điều đó thực sự vẫn không đáng kể gì. Bạn có thể nhớ lại lệnh ping được thiết kế để trả về bốn đáp trả khác nhau. Đôi khi một hoặc nhiều trong số các đáp trả đó có thể thất bại, còn một số khác có thể thành công. Điều này xảy ra có nghĩa rằng hệ thống đang có hiện tượng bị mất gói dữ liệu.
Trong trường hợp như vậy, host nội bộ và host từ xa hoặc cả hai đều hoạt động tốt, nhưng có thể xuất hiện một số điều kiện khác gây ra hiện tượng mất mát các gói tin trong khi truyền tải. Tuy giao thức TCP/IP được thiết kế để nó có thể thử lại (retry) một gói dữ liệu đã bị mất trong quá trình truyền tải này, tuy nhiên việc mất gói dữ liệu sẽ làm giảm hiệu suất của hệ thống. Một kết nối chậm lúc này sẽ hiệu quả hơn đối với một kết nối tốc độ cao xuất hiện hiện tượng mất gói dữ liệu.
Một thứ khó khăn đối với vấn đề mất gói dữ liệu là việc tìm lần lại được dấu vết của nó. Bạn có thể biết hiện tượng mất gói dữ liệu xảy ra nếu một số đáp trả cho lệnh ping thất bại, nhưng các gói ICMP đã được sử dụng bởi lệnh ping này là quá nhỏ để có thể trả về điều kiện mạng đang tồn tại gây ra hiện tượng mất mát trong các tình huống thực tế.
Nếu bạn nghi ngờ hiện tượng mất gói dữ liệu có thể xảy ra nhưng khi ping lại không trả về bất cứ một lỗi nào, khi đó bạn có thể tăng kích thước của các gói ICMP lên. Các gói lớn hơn thường dễ dấn đến hiện tượng thất bại nếu mạng có vấn đề nào đó đang tồn tại. Bạn có thể đặt kích thước gói lớn hơn trong lệnh ping bằng các sử dụng tiếp lệnh –L.
Việc sử dụng tiếp lệnh này khá đơn giản. Tất cả những gì chúng ta cần phải thực hiện là nhập vào lệnh ping và theo sau là địa chỉ mà bạn muốn ping tới, tiếp đó là tiếp lệnh –L và số byte mà bạn muốn gửi. Cho ví dụ, giả dụ rằng mạng của bạn đang có hiệu suất cực kỳ kém khi kết nối đến một host nào đó. Bạn có thể nghi ngờ lúc này hiện tượng mất gói dữ liệu có thể xảy ra, nhưng khi ping lại cho các kết quả thành công mỹ mãn. Hãy thực hiện lệnh ping với kích thước của gói dữ liệu là 1024 byte như dưới đây:
Ping 192.168.1.1 –L 1024
Bạn có thể thấy được ví dụ thực về cách làm việc của lệnh này trong hình A.
Hình A: Gắn lệnh –L vào lệnh ping sẽ cho phép bạn tăng kích thước của gói ICMP
Thời gian sống
Khái niệm tiếp theo mà chúng tôi muốn giới thiệu cho các bạn cũng liên quan đến lệnh ping là thời gian sống (Time To Live, được viết tắt là TTL). Nếu quan sát vào hình A, bạn sẽ thấy ở cuối mỗi một reply trong hình có TTL=64.
Có thể bạn đã biết, Internet gồm có một số lượng lớn các tuyến được kết nối với nhau. Mỗi tuyến được kết nối ít nhất với hai tuyến khác. Ý tưởng ẩn đằng sau kiến trúc này là nếu liên kết có bị "fail" thì vẫn còn ít nhất một đường dẫn khác dẫn đến đích. Vấn đề với kiểu kiến trúc này là khi cứ liên kết nào thất bại thì hiện tượng các gói dữ liệu truyền tải theo các đường vòng vô tận sẽ xuất hiện, và các đường vòng này sẽ vẫn tồn tại trong mạng mà không đến được đích cuối cùng của nó.
Đây chính là vấn đề mà các chuyên gia thiết kế đã đưa vào giá trị TTL. Bạn có thể cho là giá tị TTL như một cơ chế hủy các gói tin. Giá trị này được thiết lập bạn đầu khá cao, mặc dù vậy số này có thể thay đổi phụ thuộc vào hệ điều hành mà bạn đang sử dụng. Mỗi lần gói dữ liệu truyền tải qua một router, gói sẽ được nhắc nhở phải thực hiện một bước nhảy . Mỗi khi bước nhảy xuất hiện, giá trị TTL được giảm đi một. Nếu giá trị TTL bằng không thì gói khi đó sẽ bị hủy hoàn toàn. Điều này giúp tránh được hiện tượng gói dữ liệu không đi đến đích mà cứ luẩn quẩn lưu mãi trên mạng.
Kiểm tra tuyến
Một lý do khác tại sao giá trị TTL lại hữu dụng đến vậy là vì công cụ khắc phục sự cố có tên tracert hoạt động dựa trên nó. Việc sử dụng lệnh ping khá tốt cho việc khắc phục sự cố các mạng nhỏ trong đó có các host từ xa gần các host đang gửi dữ liệu, tuy nhiên khi nói đến Internet hoặc đến mạng diện rộng thì host từ xa có thể là cách đến hàng nghìn dặm. Thêm vào đó các gói ICMP được tạo bởi lệnh ping có thể truyền tải qua rất nhiều router để tới được host từ xa. Chính vì vậy đôi khi bạn sẽ gặp tình huống trong đó host nội bộ và host từ xa hoặc cả hai đều tốt nhưng một trong các router ở đâu đó lại có vấn đề. Để khắc phục vấn đề đó bạn có thể sử dụng lệnh tracert để chuẩn đoán vấn đề của bạn là gì.
Lệnh tracert hoạt động dựa trên lệnh ping. Ý tưởng cơ bản đằng sau lệnh này là gửi đi một gói ICMP đến host từ xa, nhưng với giá trị TTL đã được thiết lập bằng một số nào đó. Điều này làm cho router đầu tiên mà nó gặp phải sẽ gửi trở lại một TTL đã hết hạn trong trong thông báo truyền tải. Thông báo này gồm có các thông tin như nhận dạng router sinh ra thông báo. Xác minh router được minh chứng, sau đó gói ICMP được gửi lại lần nữa nhưng lúc này với một giá trị TTL khác. Lúc này, gói ICMP đến được router thứ hai trước khi giá trị TTL hết hạn. Quá trình này được lặp đi lặp lại, việc tăng giá trị TTL được thực hiện như vậy cho tới khi đến được host đích. Điều này cho phép bạn có thể biết được các thông tin về các router giữa host nội bộ và host từ xa. Đôi khi bạn còn có thể sử dụng thông tin này để lần các vấn đề của router có ảnh hưởng đến luồng lưu lượng.
Việc sử dụng lệnh tracert cũng giống như sử dụng lệnh ping. Để thực hiện điều đó, bạn chỉ cần nhập vào lệnh tracert, sau đó là địa chỉ IP hoặc tên miền hoàn chỉnh của host từ xa. Hình B thể hiện một trường hợp sử dụng lệnh tracert.
Hình B: Lệnh tracert có thể được sử dụng để giải quyết các vấn đề về luồng lưu lượng
Có hai vấn đề bạn cần lưu ý ở đây trong khi sử dụng lệnh tracert này là: trước tiên là một số host có thể sử dụng tường lửa để khóa các gói ICMP. Vào trường hợp này, bạn sẽ thấy một loạt các dấu hoa thị chỉ thị rằng việc lần tuyến là không thể thực hiện với host vì không thể lấy được thông tin từ host đó.
Một vấn đề khác nằm ở bản thân các host, mỗi router đều được gán một địa chỉ IP. Không quan tâm đến chúng được sử dụng cho các host hay cho router hay không, các địa chỉ IP được cấu trúc theo cách để cho phép chúng phản ánh được vị trí địa lý. Trong thực tế, đôi khi các thông tin về địa lý này hoặc thậm chí các chỉ dẫn về tuyến lại được cung cấp bên trong tracert. Nếu bạn muốn có thêm nhiều thông tin, hãy thử dùng các công cụ của các hãng phần mềm thứ ba, các công cụ có thể theo dõi bằng kiểu đồ thị lệnh tracert dựa trên các thông tin địa lý. Bạn có thể xem ví dụ về một công cụ như vậy trong hình C.
Hình C: Bạn có thể thực hiện một tracert ảo để xác định bị trí địa lý của host
Kết luận
Trong phần này, chúng tôi đã giới thiệu cho các bạn về cách tăng số lượng byte trong khi sử dụng lệnh ping nhằm lần ra dấu vết của hiện tượng mất gói dữ liệu. Tiếp đó là giới thiệu về lệnh tracert. Trong phần tiếp theo của loạt bài này, chúng tôi sẽ tiếp tục thảo luận bằng cách giới thiệu cách thông dịch các kết quả được cho bởi lệnh tracert.