Як Intel AMT (Active Management Technology) не заважає стеку TCP/IP?

Комплект Intel dev, який я використовую, включає функція віддаленого керування (також див. = "nofollow noreferrer"> Сторінка Ubuntu man тут ), яка дозволяє віддалені перезавантаження у випадку зависання операційної системи.

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

I have it running on a separate IP address, because I'm worried about one potential use case: how does AMT prevent the host network stack from conflicting with it?

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

Won't packets returning from the remote host get "blackholed" and never reach the OS? Or is there some preventative measure, like an Intel driver in the Linux kernel knowing that TCP should avoid port 16992? (seems unlikely since this is an OS-agnostic feature.) Or maybe the management interface can forward traffic sent to port 16992 that doesn't belong to a known management session back to the host stack?

У будь-якому випадку, я не хочу використовувати це для мережевих навантажень, поки не зрозумію, як це працює. Я виконав пошук в документації Intel і там нічого не міг знайти.

Я вважаю, що це можна було б перевірити, ініціювавши близько 30000 TCP-з'єднань, і перевіривши, чи працює з'єднання, навіть якщо порт перекривається. Але я ще не мав можливості зробити це.

(Примітка: я розумію, що це питання схоже на Як Комп'ютер на базі Intel vPro підтримує підключення до ІР? , але ці питання стосуються підключення взагалі, а не підключення до конкретних портів TCP, які накладаються на стек хоста.)

14
Я помітив, що хтось голосував, щоб закрити це як не тему. У цьому випадку я хотів би запитати: як це не має відношення до професійних адміністраторів серверів? Якщо ви збираєтеся ввімкнути технологію керування поза діапазоном, чи не хочете ви знати, чи вплине це на комунікацію в мережі?
додано Автор John Greenan, джерело
@kasperd спасибі; Я не знав, що ти можеш легко це зробити. Я пішов вперед і провів тест. Не добре виглядати для AMT ...
додано Автор John Greenan, джерело
Хороше питання. Я маю на увазі, що правильна реалізація такої функції повинна використовувати свій власний стек IP на інший MAC-адресу, щоб повністю уникнути можливих конфліктів. Вам не потрібно 30000 TCP-з'єднань для перевірки конфліктів. Замість цього ви можете спробувати щось на зразок nc -p 16992 example.com 22 і подивитися, що відбувається.
додано Автор kasperd, джерело
Я припускаю, що він дивиться на весь трафік на цих портах, і якщо його не те, що він визнає, передає його до OS. Але це цілком спекуляція.
додано Автор Grant, джерело

5 Відповіді

Після налаштування 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 хоста!

8
додано

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

By default, Windows uses port 49152 >> 65636 (or whatever the upperlimit is) So you're very safe to use AMT. You can set the port range with netsh. For instance, I always use about 1000 ports for perimeter machines.

Крім того, Intel видаляє команди AMT і передає весь інший трафік на ці порти (насправді! 16991-16995!) До ОС (якщо наявна ОС). Отже, якщо у вас буде програма, яка відкривала порт в діапазоні AMT, трафік все одно буде проходити через ОС до програми, тому що, як я вже сказав, Intel лише смуги команд управління AMT. Навряд чи ваша програма надсилає команди AMT.

2
додано
Ця відповідь передбачає (1), що ви використовуєте Windows, і (2) ви не використовуєте жодного програмного забезпечення, яке може спробувати використовувати AMT-перекриваються порти з інших причин. (Ви можете мати, наприклад, VoIP-додаток, що використовує випадкові UDP-порти). Він також заявляє про те, як Intel "видаляє" команди AMT, що явно було неправдивим у моїй відповіді. Чи можете ви надати посилання на вашу заяву? Я не здивуюся, якщо Intel розглядає це як помилку і виправляє її один день, але в той час, коли я розмістив свою відповідь, вони явно не мали.
додано Автор John Greenan, джерело

Чи не повернуться пакети з віддаленого вузла до "blackholed" і ніколи не досягають ОС?

Всі пакети від віддаленого вузла з "AMT-портами" ніколи не досягають жодної ОС. Їх перехоплює Intel ME/AMT. Типово, це порти 16992-16995, 5900 (AMT вер. 6+), 623, 664.

1
додано

На форумі Intel існує суперечливий потік Перетворення між IP-адресою хоста та IP-пристроєм Intel AMT з пропозицією, що

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

і пояснення:

Коли ви налаштовуєте машину vPro зі статичними IP-адресами, AMT використовуватиме   mac address називається керованістю 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!)
0
додано

Слід зазначити, що AMT призначена як клієнтська технологія OOBM, а не серверна. Тому так, може статися так, що ваш комп'ютер вирішить використовувати AMT-порти, але тільки в тому випадку, якщо ви спеціально налаштували його для цього. Більшість операційних систем постачаються з попередньо сконфігурованими ефемерними портами в діапазоні від 49152 до 65535, як це передбачено специфікацією IANA, деякі дистрибутиви Linux з 32768 до 61000 і старі Windows з 1025-5000.

Так що з моєї точки зору це зберегти використовувати спільний IP для AMT, оскільки його порти не в ефемерний діапазон (якщо ви не знаєте, що ви робите, і змінити цю конкретну установку) і не повинні використовуватися як порт для прослуховування будь-якої програми.

0
додано