Xử lý lỗi kịch bản điều khiển từ xa bằng Network Monitor 3.0

Một phần của tài liệu Giáo trình quản trị hệ thống mail server và web server (nghề quản trị mạng máy tính) (Trang 54 - 63)

2. Nguyên tắc hoạt động của WMI

3.4. Xử lý lỗi kịch bản điều khiển từ xa bằng Network Monitor 3.0

Microsoft gần đây đã phát hành một phiên bản Network Monitor mới, công cụ này là một phần của Microsoft Systems Management Server. Network Monitor 3.0 có vài cải tiến so với phiên bản trƣớc, cụ thể là:

 Cải thiện giao diện ngƣời dùng hiển thị các khung khi chúng đang hoạt động theo thời gian thực.

 Nhiều phiên capture đồng thời và capture đồng thời trên nhiều adapter mạng.  Khả năng hiển thị “cuộc đàm thoại” mạng, nghĩa là các session protocol cụ thể.  Hỗ trợ cho Vista, Windows XP và Windows Server 2003 (cả 32 bit và 64 bit).  Panel lọc mới cho phép bạn sử dụng các bộ lọc chỉ định.

Chúng tôi đang sử dụng NM3 để bắt dấu vết từ máy tính trên đó đang chạy kịch bản ChangeIPAddress.vbs. Dƣới đây là phần thiết lập để kiểm tra:

Máy trạmquản trị viên

Tên: test124.test.com

Địa chỉ IP: 172.16.11.124 (tĩnh)

Máy đích

Tên: test125.test.com

Địa chỉ IP: 172.16.11.125 (tĩnh)

Bộ điềukhiểnmiền

Tên: dc181.test.com Địa chỉ IP: 172.16.11.181

Tuy nhiên trƣớc khi chạy ChangeIPAddress.vbs trên test124 để thay đổi địa chỉ IP của test125, hãy quan sát NM3 một chút.

49

Khi bạn khởi chạy NM3, nó sẽ có giao diện nhƣ hình 1:

Hình 1: Cửa sổ Network Monitor 3.0 khi đƣợc mở

Trƣớc khi tiếp tục, hãy chọn hộp kiểm Enable Conversations để chúng ta có thể quan sát đƣợc kiểu session protocol xuất hiện trong suốt quá trình dò theo.

Bây giờ kích chuột vào tab New Capture. Điều này cho phép mở đƣợc một tab mới với tên Capture1 có thể sử dụng để tạo dấu vết mạng.

50

Hình 2: Mở một tab capture mới

Hãy kiểm tra NM3 một cách đơn giản. Kích chuột vào nút Play để bắt đầu một capture, sau đó từ máy tính test124 mở một cửa sổ lệnh và nhập vào ping

172.16.11.125 nghĩa là chúng ta đang ping từ test125 đến test124. Kết quả đƣợc cho nhƣ hình 3 dƣới đây:

51

Hình 3: Vết tích của ping 172.16.11.125

Đây là những gì chúng ta mong đợi: hai gói ARP (một yêu cầu ARP và theo sau là một đáp ứng ARP) và một loạt các gói ICMP (các thông điệp Echo Request đƣợc cho sau bởi các thông điệp Echo Reply). Nếu bạn biết kết nối mạng TCP/IP cơ bản thì điều này hoàn toàn dễ dàng có thể hiểu đƣợc.

Hãy quan sát tình huống “đàm thoại” đã xảy ra trong hình 4. Mở nút My Traffic để hiển thị điều đó:

52

Hình 4: Các “cuộc đàm thoại”

Lƣu ý rằng có hai cuộc “đàm thoại” đã xuất hiện: ARP và IPv4 (ICMP).

53

Hình 5: Việc kiểm tra một gói

Chúng ta đã đƣợc giới thiệu sơ bộ về NM3, bây giờ hãy sử dụng nó để xử lý một số lỗi xảy ra.

Lầnvết

Chúng tôi bắt đầu bằng việc khởi động lại cả hai máy trạm và xóa bộ nhớ cache (ARP, NDS,…), sau đó mở cửa sổ lệnh trên máy tính test124, đánh ChangeIPAddress.vbs 172.16.11.144 để thay đổi địa chỉ IP của máy tính test125 từ 172.16.11.125 thành 172.16.11.144. Hình 6 dƣới đây là những kết quả thu đƣợc:

54

Hình 6: Các kết quả thu đƣợc khi chạy ChangeIPAddress.vbs 172.16.11.144 Hình 6 là tổng quan những gì đã xảy ra. Giữ lại 90 giây muộn nhất và đã có 274 khung đƣợc giữ. Thông báo lỗi xuất hiện ở xung quanh khung 241 và cửa sổ lệnh trả về tại khung 274. Có rất nhiều lƣu lƣợng để chúng ta có thể phân tích! Hãy nhìn vào hình 6 ở trên, chúng ta có thể bắt đầu phân tích nó:

 Các khung 3-4 hiển thị tên TEST125 đang tồn tại dƣới địa chỉ IP là 172.16.11.125 bằng DNS.

 Các khung 5-6 hiển thị địa chỉ IP 172.16.11.125 đang tồn tại bên trong địa chỉ MAC bằng ARP.

 Các khung 7-9 thể hiện thủ tục „bắt tay‟ TCP (SYN, SYN/ACK, ACK) xuất hiện giữa hai máy tính test124 và test125.

55

 Các khung 10-11 thể hiện ràng buộc RPC đang tồn tại đƣợc thành lập giữa hai máy tính.

 Các khung 12-13 thể hiện DCOM đang tồn tại đƣợc sử dụng trên RCP (WMI sử dụng DCOM để „bắt tay‟ các cuộc gọi từ xa).

Quan sát sẽ không thể thấy đƣợc tất cả 274 khung trong hình vẽ, vì vậy chúng tôi đã copy thông tin về tất cả khung vào một file văn bản. Bạn có thể kích chuột vào đây để xem trang thông tin về tất cả các khung khi chạy ChangeIPAddress.vbs.

Khi xử lý sự cố thông thƣờng bạn phải bắt đầu với những gì bạn biết chứ không phải là những gì không hiểu. Với lƣu ý đó chúng tôi hiểu rằng kịch bản khác

(ChangeGateway.vbs) mà chúng tôi đã phát triển trong bài viết trƣớc đã làm việc mà không tạo ra bất kỳ một thông báo lỗi nào. Vì vậy trƣớc khi xem xét kỹ trong file ChangeIPAddress.txt, hãy khởi động lại các máy trạm của bạn và thực hiện một

capture khác, khi đó nó sẽ thể hiện kết quả chạy lệnh ChangeGateway.vbs 172.16.11.2 1 trên test124 để thay đổi cổng mặc định của test125 từ 172.16.11.1 thành 172.16.11.2 (chỉ ra tham số đo bằng 1). Đây là những gì lần capture thứ hai thể hiện (hình 7):

56

Lúc này chỉ có 217 khung để phân tích (!) và bạn có thể vào đây để xem tóm tắt toàn bộ các khung.

Phân tích của capture cho ChangeGateway.vbs

Bây giờ chúng ta hãy thử và phân tích lần capture thứ hai này (làm việc mà không phát sinh lỗi) bằng cách chia file tóm tắt các khung thành từng đoạn, đây là một trong số các đoạn đó:

Chỉ là NM3 header – bỏ qua

Có rất nhiều RPC/DCOM ở đây. Nó có vẻ bí ẩn nhƣng nếu nhìn kỹ chúng bạn sẽ thấy một số WMI đang có nhƣ là WMI-IWbemLoginClientID, WMI-IWbemLevel1Login, WMI-IWbemServices, WMI-IWbemFetchSmartEnum,…. Tìm kiếm trên MSDN cho chúng ta thấy nhiều thông tin hơn về những gì xảy ra. Ví dụ, trang này cho chúng ta biết rằng “ Giao diện IwbemServices đƣợc sử dụng cho các máy khách và các nhà cung cấp để có thể truy cập vào các dịch vụ WMI” vì vậy nó giống nhƣ các giao diện WMI đang tồn tại đƣợc gọi trên máy tính điều khiển xa (sử dụng DCOM) bởi máy trạm chủ đang chạy kịch bản từ nó. Một số giao diện không thực sự gây khó hiểu đối với ngƣời đọc.

Những thứ gây khó hiểu cho ngƣời đọc đầu tiên đó là các cụm TCP với các gói RPC “Continued Response” dƣờng nhƣ chỉ thị các kết nối đƣợc thực hiện trƣớc đó đang đƣợc sử dụng vào nhiều mục đích khác. Chúng tôi sẽ bỏ qua một số khung trong phần tiếp theo này.

Chúng ta có một cụm DCOM theo sau là các kết thúc kết nối TCP bằng FIN/ACK, vì vậy theo dự đoán kịch bản có thể đã thực hiện đƣợc công việc của nó và đang quét dọn làm sạch.

Ở đây có một số DNS và LDAP xuất hiện giữa test124 và bộ điều khiển miền. Không rõ tại sao nó lại xảy ra, nhƣng chúng tôi sẽ bỏ qua một số khung đó khi chúng xuất hiện quá nhiều:

57

Một phần của tài liệu Giáo trình quản trị hệ thống mail server và web server (nghề quản trị mạng máy tính) (Trang 54 - 63)