Làm thế nào để Intel AMT (Công nghệ quản lý hoạt động) không can thiệp vào ngăn xếp máy chủ TCP / IP?

Bộ công cụ phát triển Intel mà tôi đang sử dụng bao gồm một tính năng quản lý từ xa (cũng xem trang man Ubuntu ở đây ) cho phép khởi động lại từ xa trong trường hợp hệ điều hành bị treo.

Nó có khả năng nghe một số cổng (cụ thể là 16992 và 16993) trên một địa chỉ IP mà nó chia sẻ với hệ điều hành. (bằng cách rình mò các yêu cầu DHCP hoặc phát hành riêng; tôi không chắc, nhưng bằng cách nào đó, nó sử dụng địa chỉ MAC được chia sẻ trong chế độ này)

Tôi có nó chạy trên một địa chỉ IP riêng biệt, vì tôi lo lắng về một trường hợp sử dụng tiềm năng: làm thế nào AMT ngăn chặn ngăn xếp mạng máy chủ xung đột với nó?

Nói cách khác, phần mềm quản lý Intel hiện đang lắng nghe [ít nhất] hai cổng TCP, ngoài băng tần và không có kiến ​​thức của hệ điều hành. Giả sử tôi khởi tạo kết nối TCP đến máy chủ từ xa và ngăn xếp máy chủ chọn 16992 hoặc 16993 làm cổng cục bộ để nghe [cho các gói trở lại hộp].

Các gói trở về từ máy chủ từ xa có bị "bôi đen" và không bao giờ đến được HĐH không? Hoặc có một số biện pháp phòng ngừa, như trình điều khiển Intel trong nhân Linux biết rằng TCP nên tránh cổng 16992? (dường như không thể vì đây là tính năng không biết hệ điều hành.) Hoặc có thể giao diện quản lý có thể chuyển tiếp lưu lượng được gửi đến cổng 16992 không thuộc phiên quản lý đã biết trở lại ngăn xếp máy chủ?

Dù bằng cách nào, tôi miễn cưỡng sử dụng điều này cho các tải nặng mạng cho đến khi tôi hiểu cách thức hoạt động của nó. Tôi đã tìm kiếm tài liệu Intel và không thể tìm thấy bất cứ thứ gì ở đó.

Tôi cho rằng điều này có thể được kiểm tra bằng cách khởi tạo khoảng 30.000 kết nối TCP và kiểm tra xem kết nối có hoạt động ngay cả khi cổng chồng chéo hay không. Nhưng tôi chưa có cơ hội để làm điều đó.

(Chú thích: Tôi nhận ra câu hỏi này tương tự như Làm thế nào để máy tính dựa trên Intel vPro duy trì kết nối IP?, Nhưng câu hỏi đó giải quyết kết nối nói chung, không kết nối với các cổng TCP cụ thể trùng lặp với ngăn xếp máy chủ.)

Sau khi định cấu hình AMT để nghe địa chỉ IP được chia sẻ, tôi đã chạy thử nghiệm được đề cập bởi kasperd trong các nhận xét ở trên. (tất nhiên là chống lại máy chủ từ xa của tôi với máy chủ SSH, thực tế không phải example.comvậy) Đây là kết quả:

Trường hợp thử nghiệm dương tính (sử dụng cổng không được AMT sử dụng):

$ nc -p 16991 example.com 22
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4
^C
$

Trường hợp kiểm tra âm tính (sử dụng cổng được sử dụng bởi AMT):

$ nc -p 16992 example.com 22
$

(Sau vài phút, trường hợp kiểm tra âm tính đã hết thời gian và quay lại dấu nhắc shell.)

Vì vậy, như bạn có thể thấy, các gói trở về cổng 16992 đã bị hủy trước khi chúng đến ngăn xếp TCP / IP của máy chủ.

Khuyến nghị: nếu kết nối mạng đáng tin cậy là quan trọng đối với bạn, không kích hoạt AMT trên cùng địa chỉ IP với ngăn xếp TCP / IP máy chủ của bạn!

Có một chủ đề gây tranh cãi tại diễn đàn Intel Ánh xạ giữa IP máy chủ và IP thiết bị Intel AMT với đề xuất rằng

người ta phải cấu hình các địa chỉ IP khác nhau cho AMT và máy chủ khi hoạt động với IP tĩnh.

và một lời giải thích:

Khi bạn định cấu hình máy vPro với IP tĩnh, AMT sẽ sử dụng địa chỉ mac được gọi là mac có thể quản lý để chỉ phát ở chế độ IP tĩnh. Địa chỉ mac có thể quản lý khác với địa chỉ mac được trình bày bởi máy chủ lưu trữ.

Tôi xác nhận rằng việc sử dụng DHCP với cả AMT và Host dẫn đến các sự cố định tuyến. ví dụ ping đánh lừa:

64 bytes from 192.168.1.11: icmp_seq=18 ttl=64 time=0.559 ms
64 bytes from 192.168.1.11: icmp_seq=18 ttl=255 time=0.614 ms (DUP!)
64 bytes from 192.168.1.11: icmp_seq=19 ttl=64 time=0.579 ms
64 bytes from 192.168.1.11: icmp_seq=19 ttl=255 time=0.630 ms (DUP!)
64 bytes from 192.168.1.11: icmp_seq=20 ttl=64 time=0.553 ms
64 bytes from 192.168.1.11: icmp_seq=20 ttl=255 time=0.602 ms (DUP!)

Các gói trở về từ máy chủ từ xa có bị "bôi đen" và không bao giờ đến được HĐH không?

Tất cả các gói từ máy chủ từ xa có "cổng AMT" không bao giờ đến bất kỳ HĐH nào. Chúng bị chặn bởi Intel ME / AMT. Theo mặc định, chúng là các cổng 16992-16995, 5900 (AMT ver. 6+), 623, 664.

Điều cần lưu ý là, AMT được dự định là công nghệ OOBM của khách hàng chứ không phải máy chủ. Do đó, có thể xảy ra việc máy tính của bạn quyết định sử dụng cổng AMT, nhưng chỉ trong trường hợp bạn định cấu hình cụ thể để làm như vậy. Hầu hết các hệ điều hành đều đi kèm với các cổng phù du được cấu hình sẵn ở phạm vi 49152 đến 65535 theo đề xuất của đặc tả IANA, một số bản phân phối Linux với 32768 đến 61000 và Windows cũ với 1025 Nott5000.

Vì vậy, theo quan điểm của tôi, tiết kiệm để sử dụng IP được chia sẻ cho AMT vì các cổng của nó không nằm trong phạm vi phù du (trừ khi bạn biết bạn làm gì và thay đổi cài đặt cụ thể này) và không nên sử dụng làm cổng nghe bởi bất kỳ ứng dụng nào.

Một giải pháp có thể là thiết lập các cổng cho ngăn xếp Windows TCP bằng cách sử dụng netsh.

Theo mặc định, Windows sử dụng cổng 49152 >> 65636 (hoặc bất kể ưu thế là gì) Vì vậy, bạn rất an toàn khi sử dụng AMT. Bạn có thể đặt phạm vi cổng với netsh. Chẳng hạn, tôi luôn sử dụng khoảng 1000 cổng cho các máy chu vi.

Hơn nữa, Intel loại bỏ các lệnh AMT và chuyển tất cả lưu lượng truy cập khác trên các cổng đó (thực tế là 16991-16995!) Cho HĐH (Nếu có HĐH). Vì vậy, nếu bạn có một ứng dụng mở ra một cổng trong phạm vi AMT, lưu lượng sẽ vẫn truyền qua HĐH tới ứng dụng, vì như tôi đã nói, Intel chỉ loại bỏ các lệnh quản lý AMT. Ứng dụng của bạn không thể gửi các lệnh AMT.