1. Trang chủ
  2. » Công Nghệ Thông Tin

Tài liệu Quản trị mạng Windows bằng Script - Phần 8: Xử lý lỗi kịch bản điều khiển từ xa bằng Network Monitor 3.0 pptx

41 528 1

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 41
Dung lượng 3,35 MB

Nội dung

Quản trị mạng Windows bằng Script - Phần 8: Xử lỗi kịch bản điều khiển từ xa bằng Network Monitor 3.0 Trong phần 7, chúng ta đã bắt đầu xử sự cố lỗi xuất hiện khi cố gắng thay đổi từ xa địa chỉ IP trên máy tính XP bằng kịch bản ChangeIPAddress.vbs được phát triển từ trước. Lỗi đó là: SWbemObjectEx: The remote procedure call failed Trong phần trước chúng tôi đã đề cập rằng chúng tôi đã liên hệ với một số chuyên gia có uy tín trong việc xử lỗi này, và câu trả lời tốt nhất nhận được đó là hotfix có thể làm hỏng chức năng WMI và kết quả là kịch bản này đã làm việc nhưng kèm với nó có một lỗi. Một độc giả đã liên hệ với tôi với lời nhận xét dưới đây: Theo tôi đây không phải lỗi trong hotfix. Hãy chú ý rằng bạn đang thay đổi địa chỉ IP của XP2. Thủ tục gọi từ xa đã thất bại vì nó mất kết nối với XP2 trên địa chỉ gốc(172.16.11.43). Sau đó nó phụ thuộc vào thời gian (khoảng 1 phút) để tìm kiếm cho XP2 địa chỉ IP mới (172.16.11.65) trước khi bỏ địa chỉ cũ. Hãy hình dung bạn chỉ thâm nhập vào một máy chủ như quản trị viên và thay đổi địa chỉ IP của máy chủ. Bạn sẽ mất kết nối? Nó sẽ treo trong chốc lát. Nhưng việc thay đổi cổng mặc định trên máy chủ sẽ không ngắt kết nối đang tồn tại (thừa nhận bạn thực hiện điều này từ cùng một subnet). Nếu cố gắng thay đổi thiết lập cổng mặc định từ một vị tríxa thì bạn phải chịu bị giữ chậm. Vậy làm thế nào để chúng ta có thể kiểm tra lời giải thích này? Sử dụ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ạm quả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ều khiển miề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. 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. 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: 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 đó: 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). Bây giờ chúng ta hãy chọn gói ARP Request và quan sát bên trong nó (hình 5): 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ử một số lỗi xảy ra. Lần vế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: 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. [...]... Query for download.windowsupdate.com of type Host Addr on class Internet 216 9.281250 {ARP:4} 172.16.11.181 172.16.11.1 ARP ARP: Request, 172.16.11.181 asks for 172.16.11.1 Tại điểm này, kịch bản đã sẵn sàng kết thúc vì vậy chúng tôi đã kết thúc capture Phân tích của Capture cho ChangeIPAddress.vbs Bây giờ chúng ta đã có một chút ý tưởng về những gì một capture của kịch bản điều khiển từ xa thành công trông... UUID{0000014 3-0 0000000-C00 0-0 00000000046} DCOM-IRemUnknown2 Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0 34 1.937500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Bind Ack: Call=0x1 Assoc Grp=0x333D Xmit=0x16D0 Recv=0x16D0 35 1.937500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{00000143000 0-0 000-C00 0-0 00000000046} DCOM-IRemUnknown2... 2s Bây giờ chúng ta hãy nhìn vào capture cho ChangeIPAddress.vbs (kịch bản đã phát sinh lỗi RPC khi chạy nó từ xa) và xem nó khác như thế nào với các kịch bản trên 1 0.000000 NetmonFilter NetmonFilter: Updated Capture Filter: None 2 0.000000 NetworkInfo NetworkInfo: Network info for TEST124, Network Adapter Count = 1 Đó là Netmon 3 0.000000 {DNS:3, UDP:2, IPv4:1} test124.test.local dc181.test.local... UUID{0000014 3-0 0000000-C00 0-0 00000000046} DCOM-IRemUnknown2 Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0 32 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Bind Ack: Call=0x1 Assoc Grp=0x333E Xmit=0x16D0 Recv=0x16D0 33 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{00000143000 0-0 000-C00 0-0 00000000046} DCOM-IRemUnknown2... 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  Các khung 1 0-1 1 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 1 2-1 3 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) ... 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 đó: 1 0.000000 NetmonFilter NetmonFilter: Updated Capture Filter: None 2 0.000000 NetworkInfo NetworkInfo: Network info for TEST124, Network Adapter Count = 1 Chỉ là NM3 header – bỏ qua 3 0.000000 {DNS:3, UDP:2, IPv4:1} 172.16.11.124... IPv4:1} dc181.test.local 172.16.11.124 DNS DNS: QueryId = 0xEB6E, QUERY (Standard query), Response - Success 7 1.906250 {ARP:7} 172.16.11.124 172.16.11.125 ARP ARP: Request, 172.16.11.124 asks for 172.16.11.125 8 1.906250 {ARP:7} 172.16.11.125 172.16.11.124 ARP ARP: Response, 172.16.11.125 at 0 0-1 1-D8-E3-EC-84 Tên và địa chỉ (DNS và ARP) 9 1.906250 {TCP:9, IPv4:8} 172.16.11.124 test125.test.local TCP... 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ử 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... (scale factor 0) = 65535 Ở đâ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: 179 2.546875 {MSRPC:19, TCP:18, IPv4:1} 172.16.11.124 dc181.test.local MSRPC MSRPC: c/o Bind: UUID{E1AF830 8-5 D1F11C 9-9 1A 4-0 8002B14A0FA} Endpoint Mapper Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0 180... Success 5 0.015625 {ARP:4} 172.16.11.124 172.16.11.125 ARP ARP: Request, 172.16.11.124 asks for 172.16.11.125 6 0.015625 {ARP:4} 172.16.11.125 172.16.11.124 ARP ARP: Response, 172.16.11.125 at 0 0-1 1-D8-E3-EC-84 7 0.015625 {TCP:6, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=.S , SrcPort=1063, DstPort=DCE endpoint resolution(135), Len=0, Seq=539163285, Ack=0, Win=65535 (scale factor 0) . {MSRPC: 13, TCP:11, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Bind: UUID {00 000 1A 0- 0 00 0- 00 0 0- C 00 0 -0 000 000 000 46} DCOM-IRemoteSCMActivator Call=0x2. 33 1. 937 500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Bind: UUID {00 000 14 3- 0 00 0- 00 0 0- C 00 0 -0 000 000 000 46} DCOM-IRemUnknown2

Ngày đăng: 21/01/2014, 03:20

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w