web-dev-qa-db-ja.com

インテルAMT（アクティブマネジメントテクノロジー）はどのようにしてTCP / IPホストスタックを妨害しないのですか？

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

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

1つの潜在的な使用例が心配なので、別のIPアドレスで実行しています：AMTはホストネットワークスタックとの競合をどのように防ぐのですか？

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

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

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

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

（脚注：この質問は Intel vProベースのコンピューターはどのようにIP接続を維持するのですか？ に類似していることを理解していますが、その質問は特定のTCPポートへの接続ではなく、一般的な接続を扱いますホストスタックと重複しています。）

networkingtcpamt
16
mpontillo

共有IPアドレスでリッスンするようにAMTを構成した後、上記のコメントで 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
$

（数分後、否定的なテストケースはタイムアウトになり、シェルプロンプトに戻りました。）

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

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

9
mpontillo

Intelフォーラムには議論の余地のあるスレッドがあります ホストIPとIntel AMTデバイスIPの間のマッピング

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

そして説明：

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

AMTとホストの両方で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!)
2
BBQ

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

したがって、私の見解では、AMTのポートが一時的な範囲ではなく（何をすべきかを知り、この特定の設定を変更しない限り）、どのアプリケーションでもリスニングポートとして使用しないでください。

1
Lukáš Kučera

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

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

1
Roman Sevko