Комплект разработчика Intel, который я использовал, включает функция удаленного управления (также см. Страница руководства Ubuntu здесь), который позволяет удаленную перезагрузку в случае зависания операционной системы.
Он имеет возможность прослушивать несколько портов (16992 и 16993, если быть точным) на IP-адресе, который он использует совместно с операционной системой. (либо отслеживая запросы DHCP, либо выдавая свои собственные; я не уверен, но в любом случае он использует общий MAC-адрес в этом режиме)
У меня он работает на отдельном IP-адресе, потому что меня беспокоит один потенциальный вариант использования: как AMT предотвращает конфликт сетевого стека хоста с ним?
Другими словами, управляющее программное обеспечение Intel теперь прослушивает [как минимум] два порта TCP, вне полосы пропускания и без ведома операционной системы. Предположим, я инициирую TCP-соединение с удаленным хостом, и стек хоста выбирает 16992 или 16993 в качестве локального порта для прослушивания [пакетов, возвращающихся в ящик].
Разве пакеты, возвращаемые с удаленного хоста, не будут «заблокированы» и никогда не достигнут ОС? Или есть какие-то превентивные меры, такие как драйвер Intel в ядре Linux, зная, что TCP должен избегать порта 16992? (кажется маловероятным, поскольку это не зависит от ОС.) Или, может быть, интерфейс управления может пересылать трафик, отправленный на порт 16992, который не принадлежит известному сеансу управления, обратно в стек хоста?
В любом случае, я не хочу использовать это для интенсивных сетевых нагрузок, пока не пойму, как это работает. Я искал Документация Intel и там тоже ничего не нашел.
Я полагаю, это можно проверить, инициировав около 30 000 TCP-соединений и проверив, работает ли соединение, даже если порт перекрывается. Но у меня еще не было возможности сделать это.
(Сноска: я понимаю, что этот вопрос похож на Как компьютер на базе Intel vPro поддерживает IP-соединение?, но этот вопрос касается подключения в целом, а не подключения к конкретным портам TCP, которые перекрываются со стеком хоста.)
После настройки AMT для прослушивания общего IP-адреса я запустил тест, упомянутый касперд в комментариях выше. (против моего собственного удаленного хоста с 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 хоста.
Рекомендация: если для вас важна надежная сеть, не включайте AMT на том же IP-адресе, что и стек TCP / IP вашего хоста!
На форуме Intel есть спорная ветка Сопоставление между IP-адресом хоста и IP-адресом устройства Intel AMT с предложением, что
при работе со статическими IP-адресами необходимо настроить разные IP-адреса для AMT и хоста.
и объяснение:
Когда вы настраиваете машину vPro со статическими IP-адресами, AMT будет использовать MAC-адрес, называемый Mac управляемости, который работает только в режиме статического IP-адреса. Mac-адрес управляемости отличается от MAC-адреса, представленного хостом.
Я подтверждаю, что использование DHCP как с AMT, так и с хостом приводит к проблемам с маршрутизацией. например пинг вводит в заблуждение:
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!)
Разве пакеты, возвращаемые с удаленного хоста, не будут «заблокированы» и никогда не достигнут ОС?
Все пакеты с удаленного хоста с «AMT-портами» никогда не достигают ни одной ОС. Их перехватывает Intel ME / AMT. По умолчанию это порты 16992-16995, 5900 (AMT версии 6+), 623, 664.
Следует отметить, что AMT задумана как клиентская технология OOBM, а не серверная. Поэтому да, может случиться так, что ваш компьютер решит использовать порты AMT, но только в том случае, если вы специально настроили его для этого. Большинство операционных систем поставляются с предварительно сконфигурированными временными портами в диапазоне от 49152 до 65535 в соответствии со спецификацией IANA, некоторые дистрибутивы Linux с 32768 до 61000 и старая Windows с 1025–5000.
Таким образом, с моей точки зрения, использование общего IP-адреса для AMT является экономичным, поскольку его порты не находятся в эфемерном диапазоне (если вы не знаете, что делаете, и не измените этот конкретный параметр) и не должны использоваться в качестве порта прослушивания каким-либо приложением.
Одним из решений может быть установка портов для стека TCP Windows с помощью netsh.
По умолчанию Windows использует порт 49152 >> 65636 (или любой другой верхний предел), поэтому вы можете безопасно использовать AMT. Вы можете установить диапазон портов с помощью netsh. Например, я всегда использую около 1000 портов для компьютеров периметра.
Кроме того, Intel удаляет команды AMT и передает весь остальной трафик по этим портам (на самом деле 16991-16995!) В ОС (если ОС присутствует). Поэтому, если у вас есть приложение, открывающее порт в диапазоне AMT, трафик все равно будет проходить через ОС в приложение, потому что, как я уже сказал, Intel удаляет только команды управления AMT. Маловероятно, что ваше приложение отправляет команды AMT.