Как Intel AMT (технология активного управления) не мешает стеку хоста TCP / IP?

Набор разработчика 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-адреса я запустил тест, упомянутый 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 хоста.

Рекомендация: если для вас важна надежная сеть, не включайте AMT на том же IP-адресе, что и стек TCP / IP вашего хоста!

На форуме Intel есть спорная тема Сопоставление между IP-адресом хоста и IP-устройством Intel AMT с предположением, что

необходимо настроить разные IP-адреса для AMT и хоста при работе со статическими IP-адресами.

и объяснение:

Когда вы конфигурируете компьютер vPro со статическими IP-адресами, AMT будет использовать mac-адрес, называемый управляемостью mac, который воспроизводится только в режиме статического IP-адреса. Управляемость mac-адреса отличается от mac-адреса, представленного хостом.

Я подтверждаю, что использование DHCP как с AMT, так и с Host ведет к проблемам с маршрутизацией. например, пинг вводит в заблуждение:

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, поскольку его порты не находятся в эфемерном диапазоне (если вы не знаете, что делаете, и не меняете этот конкретный параметр) и не должны использоваться в качестве прослушивающего порта каким-либо приложением.

Одним из решений может быть установка портов для стека Windows TCP с помощью netsh.

По умолчанию Windows использует порт 49152 >> 65636 (или любой другой верхний предел), поэтому вы можете безопасно использовать AMT. Вы можете установить диапазон портов с помощью netsh. Например, я всегда использую около 1000 портов для машин периметра.

Кроме того, Intel снимает команды AMT и передает весь остальной трафик с этих портов (на самом деле 16991-16995!) В ОС (если ОС присутствует). Поэтому, если у вас будет приложение, открывающее порт в диапазоне AMT, трафик все равно будет проходить через ОС к приложению, потому что, как я уже сказал, Intel отбирает только команды управления AMT. Маловероятно, что ваше приложение отправляет команды AMT.