Як Intel AMT (Active Management Technology) не перешкоджає хосту стека TCP / IP?

Набір Intel Dev, який я використовую, включає функцію віддаленого управління (також дивіться сторінку Man Ubuntu тут ), яка дозволяє віддалено перезавантажуватись у випадку, якщо операційна система зависає.

Він має можливість прослуховувати декілька портів (16992 та 16993, щоб бути конкретними) на IP-адресу, якою він ділиться з операційною системою. (або запитуючи DHCP-запити, або видаючи власні; я не впевнений, але в будь-якому випадку він використовує спільну MAC-адресу в цьому режимі)

У мене він працює за окремою IP-адресою, тому що мене турбує один можливий випадок використання: як AMT запобігає конфлікту з ним вузлової мережі?

Іншими словами, тепер програмне забезпечення управління Intel прослуховує [принаймні] два порти TCP, поза межами діапазону та без відома операційної системи. Скажімо, я ініціюю TCP-з'єднання з віддаленим хостом, і стек хостів вибирає 16992 або 16993 як локальний порт для прослуховування [для пакетів, що повертаються до вікна].

Невже пакети, що повертаються з віддаленого хоста, не потрапляють у чорний список і ніколи не дістаються ОС? Або є якийсь запобіжний захід, наприклад, драйвер Intel в ядрі Linux, знаючи, що TCP повинен уникати порту 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 Device з пропозицією, що

треба налаштувати різні IP-адреси для AMT та хоста під час роботи зі статичними IP-адресами.

та пояснення:

Коли ви налаштовуєте vPro-апарат із статичними IP-адресами, AMT буде використовувати мак-адресу, яку називають керованою мак, яка відтворюється лише в статичному режимі IP. Управління мак-адресою відрізняється від адреси 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.