Intel AMT（Active Management Technology）はどのようにTCP / IPホストスタックに干渉しませんか？

私が使用しているIntel開発キットには、オペレーティングシステムがハングした場合にリモートで再起動できるリモート管理機能 （こちらのUbuntuのマニュアルページも参照）が含まれています。

オペレーティングシステムと共有するIPアドレスで、少数のポート（具体的には16992および16993）をリッスンする機能があります。（DHCP要求をスヌーピングするか、独自に発行することにより、どちらかはわかりませんが、どちらの方法でもこのモードで共有MACアドレスを使用します）

別のIPアドレスで実行しているのは、潜在的なユースケースの1つが心配だからです。AMTは、ホストネットワークスタックとの競合をどのように防止するのでしょうか。

言い換えれば、Intel管理ソフトウェアは現在、少なくとも2つのTCPポートを帯域外で、オペレーティングシステムの知識なしでリッスンしています。リモートホストへのTCP接続を開始し、ホストスタックがローカルボックスとして16992または16993を選択して[ボックスに戻ってくるパケットを]リッスンするとします。

リモートホストから返されたパケットは「ブラックホール」になり、OSに到達しませんか？または、LinuxカーネルのIntelドライバーがTCPがポート16992を回避する必要があることを認識しているなど、予防策はありますか？（これはOSに依存しない機能なので、ありそうにないようです。）または、管理インターフェイスは、既知の管理セッションに属さないポート16992に送信されたトラフィックをホストスタックに転送できますか？

いずれにせよ、これがどのように機能するかを理解するまでは、ネットワーク集中型の負荷にこれを使用することに消極的です。Intelのドキュメントを検索しましたが、何も見つかりませんでした。

約30,000個のTCP接続を開始し、ポートが重複しても接続が機能するかどうかを確認することで、これをテストできると思います。しかし、私はまだそうする機会がありませんでした。

（脚注：私はこの質問がに似て実現する？どのようにインテル®vPro™ベースのコンピュータは、IP接続を維持しないが、ホストスタックとの重複という一般的な質問のアドレスは、接続ではなく、特定のTCPポートに接続することを。）

共有IPアドレスでリッスンするようにAMTを構成した後、上記のコメントでkasperdが言及したテストを実行しました。（example.comもちろん、実際にではなく、SSHサーバーを備えた自分のリモートホストに対して）結果は次のとおりです。

ポジティブテストケース（ポートを使用 AMTで使用されていないを使用）：

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

負のテストケース（AMTが使用するポートを使用）：

$ nc -p 16992 example.com 22
$

（数分後、ネガティブテストケースはタイムアウトし、シェルプロンプトに戻りました。）

ご覧のとおり、ポート16992に戻ってくるパケットは、ホストのTCP / IPスタックに到達する前にドロップされました。

推奨事項：信頼性の高いネットワークが重要な場合は、ホストTCP / IPスタックと同じIPアドレスでAMTを有効にしないでください！

Intelフォーラムで議論の余地のあるスレッドがあります。ホストIPとIntel AMTデバイスIPの間のマッピング の提案では、ということ

静的IPで動作する場合、AMTとホストに異なるIPアドレスを設定する必要があります。

および説明：

vProマシンを静的IPで構成すると、AMTは管理IPと呼ばれるMACアドレスを使用します。これは静的IPモードでのみ再生されます。管理容易性MACアドレスは、ホストが提示するMACアドレスとは異なります。

DHCPをAMTとホストの両方で使用すると、ルーティングの問題が発生することを確認します。例：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!)

リモートホストから返されるパケットは「ブラックホール」になり、OSに到達しませんか？

「AMTポート」を持つリモートホストからのすべてのパケットは、OSに到達しません。Intel ME / AMTによって傍受されます。デフォルトでは、ポートは16992-16995、5900（AMTバージョン6 +）、623、664です。

注意すべきは、AMTはサーバーOOBMテクノロジーではなく、クライアントOOBMテクノロジーとして意図されているということです。したがって、はい、コンピューターがAMTポートを使用することを決定することがありますが、そのように特別に構成した場合のみです。ほとんどのOSには、IANA仕様、32768〜61000の一部のLinuxディストリビューション、および1025〜5000の古いWindowsで示唆されているように、49152〜65535の範囲で事前設定された一時ポートが付属します。

そのため、ポートは一時的な範囲内にないため（あなたが何をするかを知らず、この特定の設定を変更しない限り）、アプリケーションによってリスニングポートとして使用されるべきではないため、私の観点からは、AMTに共有IPを使用することは節約されます。

1つの解決策は、を使用してWindows TCPスタックのポートを設定することnetshです。

デフォルトでは、Windowsはポート49152 >> 65636（または上限値）を使用するため、AMTを使用しても非常に安全です。ポート範囲はで設定できnetshます。たとえば、境界マシンには常に約1000個のポートを使用します。

さらに、IntelはAMTコマンドを取り除き、それらのポート上の他のすべてのトラフィック（実際には16991-16995！）をOS（OSが存在する場合）に渡します。したがって、AMT範囲のポートを開くアプリケーションがある場合、トラフィックはOSを介してアプリケーションに渡されます。これは、前述したように、IntelはAMT管理コマンドを削除するだけだからです。アプリケーションがAMTコマンドを送信している可能性はほとんどありません。