W jaki sposób technologia Intel AMT (Active Management Technology) nie koliduje ze stosem hosta TCP / IP?

Zestaw deweloperski Intel, z którego korzystam, zawiera funkcję zdalnego zarządzania (patrz także strona podręcznika użytkownika Ubuntu tutaj ), która umożliwia zdalne ponowne uruchomienie w przypadku zawieszenia systemu operacyjnego.

Może nasłuchiwać kilku portów (konkretnie 16992 i 16993) pod adresem IP, który dzieli z systemem operacyjnym. (albo węsząc żądania DHCP, albo wydając własne; nie jestem pewien, ale tak czy inaczej używa udostępnionego adresu MAC w tym trybie)

Mam go uruchomiony na osobnym adresie IP, ponieważ martwię się o jeden potencjalny przypadek użycia: w jaki sposób AMT zapobiega konfliktowi stosu sieci hosta?

Innymi słowy, oprogramowanie zarządzające Intel nasłuchuje teraz [co najmniej] dwóch portów TCP, poza pasmem i bez wiedzy systemu operacyjnego. Powiedzmy, że inicjuję połączenie TCP ze zdalnym hostem, a stos hostów wybiera 16992 lub 16993 jako lokalny port do nasłuchiwania [dla pakietów wracających do pudełka].

Czy pakiety wracające ze zdalnego hosta nie zostaną „zakłócone” i nigdy nie osiągną systemu operacyjnego? Czy może istnieje jakiś środek zapobiegawczy, na przykład sterownik Intel w jądrze Linuksa, który wie, że TCP powinien unikać portu 16992? (wydaje się mało prawdopodobne, ponieważ jest to funkcja niezależna od systemu operacyjnego). A może interfejs zarządzania może przekazywać ruch wysyłany do portu 16992, który nie należy do znanej sesji zarządzania, z powrotem do stosu hosta?

Tak czy inaczej, niechętnie używam tego do obciążeń intensywnie obciążających sieć, dopóki nie zrozumiem, jak to działa. Przeszukałem dokumentację Intela i nie znalazłem tam nic.

Przypuszczam, że można to przetestować, inicjując około 30 000 połączeń TCP i sprawdzając, czy połączenie działa, nawet jeśli port się pokrywa. Ale nie miałem jeszcze okazji tego zrobić.

(Przypis: Zdaję sobie sprawę, że to pytanie jest podobne do tego, w jaki sposób komputer z procesorem Intel vPro utrzymuje łączność IP ? , ale to pytanie dotyczy ogólnie łączności, a nie łączności z konkretnymi portami TCP pokrywającymi się ze stosem hosta.)

Po skonfigurowaniu AMT do nasłuchiwania na wspólnym adresie IP przeprowadziłem test wspomniany przez kasperd w powyższych komentarzach. (przeciwko mojemu zdalnemu hostowi z serwerem SSH example.com, oczywiście nie tak ) Oto wynik:

Pozytywny przypadek testowy (za pomocą portu nie używany przez AMT):

$ nc -p 16991 example.com 22
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4
^C
$

Negatywny przypadek testowy (przy użyciu portu używanego przez AMT):

$ nc -p 16992 example.com 22
$

(Po kilku minutach upłynął limit czasu negatywnego testu i wrócił do monitu powłoki).

Jak widać, pakiety wracające do portu 16992 zostały usunięte, zanim dotarły do ​​stosu TCP / IP hosta.

Zalecenie: jeśli niezawodne połączenie sieciowe jest dla Ciebie ważne, nie włączaj AMT na tym samym adresie IP, co stos TCP / IP hosta!

Na forum firmy Intel istnieje kontrowersyjny wątek Mapowanie między adresem IP hosta a adresem IP urządzenia Intel AMT z sugestią

podczas pracy ze statycznymi adresami IP należy skonfigurować różne adresy IP dla AMT i hosta.

i wyjaśnienie:

Gdy skonfigurujesz maszynę vPro ze statycznymi adresami IP, AMT użyje adresu mac zwanego mac zarządzalności, który jest odtwarzany tylko w trybie statycznego adresu IP. Zarządzalny adres mac różni się od adresu mac przedstawionego przez hosta.

Potwierdzam, że używanie DHCP zarówno z AMT, jak i Hostem prowadzi do problemów z routingiem. np. ping mylący:

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!)

Czy pakiety wracające ze zdalnego hosta nie zostaną „zakłócone” i nigdy nie osiągną systemu operacyjnego?

Wszystkie pakiety ze zdalnego hosta z „portami AMT” nigdy nie docierają do żadnego systemu operacyjnego. Są przechwytywane przez Intel ME / AMT. Domyślnie są to porty 16992-16995, 5900 (AMT wer. 6+), 623, 664.

Należy zauważyć, że AMT jest przeznaczone jako technologia klienta OOBM, a nie serwerowa. Dlatego tak, może się zdarzyć, że Twój komputer zdecyduje się na użycie portów AMT, ale tylko w przypadku, gdy specjalnie to skonfigurowałeś. Większość systemów operacyjnych ma wstępnie skonfigurowane efemeryczne porty w zakresie od 49152 do 65535, jak sugeruje specyfikacja IANA, niektóre dystrybucje Linuksa z 32768 do 61000 i stare Windows z 1025–5000.

Z mojego punktu widzenia oszczędzam więc na korzystaniu ze współdzielonego adresu IP dla AMT, ponieważ jego porty nie znajdują się w efemerycznym zakresie (chyba że wiesz, co robisz i zmienisz to ustawienie) i nie powinny być używane jako port nasłuchujący przez żadną aplikację.

Jednym z rozwiązań może być ustawienie portów dla stosu TCP systemu Windows za pomocą netsh.

Domyślnie system Windows używa portu 49152 >> 65636 (lub cokolwiek to jest górna granica), więc korzystanie z AMT jest bardzo bezpieczne. Możesz ustawić zakres portów za pomocą netsh. Na przykład zawsze używam około 1000 portów dla maszyn obwodowych.

Co więcej, Intel usuwa polecenia AMT i przekazuje cały pozostały ruch na tych portach (właściwie 16991-16995!) Do systemu operacyjnego (jeśli system operacyjny jest obecny). Więc jeśli miałbyś aplikację, która otworzyła port w zakresie AMT, ruch nadal będzie przechodził przez system operacyjny do aplikacji, ponieważ, jak powiedziałem, Intel jedynie usuwa polecenia zarządzania AMT. Jest mało prawdopodobne, że Twoja aplikacja wysyła polecenia AMT.