英特爾 AMT（主動管理技術）如何不干擾 TCP/IP 主機堆棧？
我一直在使用的英特爾開發套件包含一個遠端管理功能 （另請參見此處的 Ubuntu 手冊頁），它允許在作業系統掛起時遠端重新啟動。
它能夠在與作業系統共享的 IP 地址上偵听少數埠（具體來說是 16992 和 16993）。（通過監聽 DHCP 請求或發出自己的請求；我不確定，但無論哪種方式，它在此模式下都使用共享 MAC 地址）
我讓它在一個單獨的 IP 地址上執行，因為我擔心一個潛在的案例：AMT 如何防止主機網路堆棧與其發生衝突？
換句話說，英特爾管理軟體現在正在監聽
$$ at least $$兩個 TCP 埠，帶外且作業系統不知道。假設我發起了到遠端主機的 TCP 連接，並且主機堆棧選擇 16992 或 16993 作為本地埠來監聽$$ for packets coming back to the box $$. *從遠端主機返回的數據包不會被“黑洞”並且永遠不會到達作業系統嗎？*或者是否有一些預防措施，比如 Linux 核心中的 Intel 驅動程序知道 TCP 應該避開埠 16992？（似乎不太可能，因為這是一個與作業系統無關的功能。）或者管理介面可以將發送到不屬於已知管理會話的埠 16992 的流量轉發回主機堆棧？
無論哪種方式，我都不願意將它用於網路密集型負載，直到我了解它是如何工作的。我搜尋了英特爾文件，也找不到任何東西。
我想這可以通過啟動大約 30,000 個 TCP 連接來測試，並檢查連接是否有效，即使埠重疊也是如此。但我還沒有機會這樣做。
（腳註：我意識到這個問題類似於基於 Intel vPro 的電腦如何保持 IP 連接？但該問題通常解決連接問題，而不是與與主機堆棧重疊的特定 TCP 埠的連接。）
在將 AMT 配置為偵聽共享 IP 地址後，我執行了上面評論中kasperd提到的測試。（針對我自己的帶有 SSH 伺服器的遠端主機，
example.com當然不是真的）結果如下：正面測試案例（使用AMT未使用的埠）：
$ nc -p 16991 example.com 22 SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4 ^C $否定測試案例（使用 AMT 使用的埠）：
$ nc -p 16992 example.com 22 $（幾分鐘後，否定測試案例超時，返回shell提示符。）
如您所見，返回埠 16992 的數據包在到達主機的 TCP/IP 堆棧之前就被丟棄了。
建議：如果可靠的網路對您很重要，請不要在與您的主機 TCP/IP 堆棧相同的 IP 地址上啟用 AMT！