Intel AMT (Active Management Technology)如何不干扰TCP/IP主机栈？

Question

我一直在使用的Intel工具包包括一个远程管理功能 (参见Ubuntu手册页)，它允许在操作系统挂起时远程重新启动。

它能够监听与操作系统共享的IP地址上的几个端口(具体而言，是16992和16993 )。(通过窥探DHCP请求或发出它自己的请求；我不确定，但无论是哪种方式，它都在这种模式下使用共享的MAC地址)

我让它在一个单独的IP地址上运行，因为我担心一个潜在的用例: AMT如何防止主机网络堆栈与它发生冲突？

换句话说，英特尔管理软件现在正在监听至少的两个TCP端口，它们是带外的，而且不需要操作系统的知识。假设我启动到远程主机的TCP连接，主机堆栈选择16992或16993作为本地端口来侦听对于返回到盒子的数据包。

从远程主机返回的数据包不会被“黑洞”，永远不会到达操作系统吗？还是有一些预防措施，比如Linux内核中的英特尔驱动程序，知道TCP应该避免端口16992？(这似乎不太可能，因为这是一个与操作系统无关的特性。)或者管理接口可以将发送到不属于已知管理会话的端口16992的流量转发回主机堆栈？

无论哪种方式，我都不愿意将它用于网络密集型负载，直到我了解了它是如何工作的。我搜索了英特尔文档，在那里也找不到任何东西。

我认为可以通过启动大约30,000个TCP连接来测试这一点，并检查即使端口重叠，连接是否有效。但我还没机会这么做。

(脚注:我意识到这个问题类似于基于英特尔vPro的计算机如何保持IP连接？，但这个问题一般涉及连接性，而不是与主机堆栈重叠的特定TCP端口的连接。)

Answer 1

英特尔论坛( Intel 主机IP与Intel AMT设备IP之间的映射 )上有一条有争议的帖子，建议

在使用静态IP操作时，必须为AMT和主机配置不同的IP地址。

还有一个解释：

当您用静态IP配置vPro机器时，AMT将使用称为可管理性mac的mac地址，该地址只在静态IP模式下使用。可管理性mac地址与主机提供的mac地址不同。

我确认在AMT和Host中使用DHCP会导致路由问题。例如，ping误导：

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!)

Answer 2

从远程主机返回的数据包不会被“黑洞”，永远不会到达操作系统吗？

来自远程主机的所有带有“AMT-端口”的数据包都不会到达任何操作系统。他们被英特尔ME/AMT截获。默认情况下，它们是端口16992-16995,5900 (AMT )。( 6+)，623664。

Answer 3

应该注意的是，AMT是作为客户端OOBM技术而不是服务器技术。因此，可能会发生计算机决定使用AMT端口的情况，但前提是您专门将其配置为AMT端口。大多数OSes都有预先配置好的临时端口，如IANA规范所建议的，在49152到65535之间，有些Linux发行版有32768到61000，旧版本有1025-5000。

因此，从我的角度来看，为AMT使用共享IP是保存的，因为它的端口不是在短暂的范围内(除非您知道要做什么，并更改这个特定的设置)，并且不应该被任何应用程序用作侦听端口。