17 votos

¿Cómo hace Intel AMT (Active Management Technology) para no interferir con la pila de host TCP/IP?

El kit de desarrollo de Intel que he estado utilizando incluye un gestión remota (véase también el Página man de Ubuntu aquí ) que permite el reinicio remoto en caso de que el sistema operativo se cuelgue.

Tiene la capacidad de escuchar un puñado de puertos (16992 y 16993, para ser específicos) en una dirección IP que comparte con el sistema operativo. (ya sea por snooping DHCP peticiones o la emisión de su propia; No estoy seguro, pero de cualquier manera se utiliza una dirección MAC compartida en este modo)

Lo tengo funcionando en una dirección IP separada, porque me preocupa un posible caso de uso: ¿cómo evita AMT que la pila de red del host entre en conflicto con ella?

En otras palabras, el software de gestión de Intel está ahora escuchando [al menos] dos puertos TCP, fuera de banda y sin el conocimiento del sistema operativo. Digamos que inicio una conexión TCP a un host remoto, y la pila del host elige 16992 o 16993 como puerto local de escucha [para los paquetes que vuelven a la caja].

¿No se "bloquearán" los paquetes que vuelven del host remoto y nunca llegarán al sistema operativo? ¿O existe alguna medida preventiva, como un controlador Intel en el kernel Linux que sepa que TCP debe evitar el puerto 16992? (parece poco probable, ya que se trata de una característica agnóstica del sistema operativo.) ¿O tal vez la interfaz de gestión puede reenviar el tráfico enviado al puerto 16992 que no pertenece a una sesión de gestión conocida de vuelta a la pila del host?

De cualquier manera, soy reacio a usar esto para cargas intensivas de red hasta que entienda cómo funciona. He buscado en el Documentación de Intel y tampoco pude encontrar nada allí.

Supongo que esto podría probarse iniciando unas 30.000 conexiones TCP, y comprobando si la conectividad funciona aunque se solapen los puertos. Pero aún no he tenido ocasión de hacerlo.

(Nota: Me doy cuenta de que esta pregunta es similar a ¿Cómo mantiene la conectividad IP un ordenador basado en Intel vPro? pero esas preguntas se refieren a la conectividad en general, no a la conectividad con los puertos TCP específicos que se solapan con la pila del host).

8 votos

He visto que alguien ha votado para cerrar esto como off-topic. En ese caso, me gustaría preguntar: ¿cómo es esto no relevantes para los administradores profesionales de servidores? Si vas a habilitar una tecnología de gestión fuera de banda, ¿no te gustaría saber si afectará a las comunicaciones de tu red?

0 votos

Mi suposición sería que mira todo el tráfico en esos puertos, y si no es algo que reconoce lo pasa al sistema operativo. Pero eso es pura especulación.

2 votos

Buena pregunta. Estoy pensando que una implementación adecuada de tal característica tendría que utilizar su propia pila IP en una dirección MAC diferente para evitar completamente posibles conflictos. No necesitas 30000 conexiones TCP para comprobar si hay conflictos. En su lugar, podrías probar algo como nc -p 16992 example.com 22 y ver qué pasa.

10voto

Mike Puntos 637

Después de configurar AMT para escuchar en una dirección IP compartida, ejecuté la prueba mencionada por kasperd en los comentarios anteriores. (contra mi propio host remoto con un servidor SSH, no realmente example.com Aquí está el resultado:

Caso de prueba positivo (utilizando un puerto no utilizado por AMT):

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

Caso de prueba negativo (utilizando un puerto usado por AMT):

$ nc -p 16992 example.com 22
$

(Después de unos minutos, el caso de prueba negativo expiró y volvió a la indicación Shell).

Así que, como puedes ver, los paquetes que volvían al puerto 16992 eran descartados antes de llegar a la pila TCP/IP del host.

Recomendación: si la fiabilidad de la red es importante para usted, no active AMT en la misma dirección IP que la pila TCP/IP de su host.

2voto

Idontknow Puntos 17

Hay un hilo de controversia en el foro de Intel Asignación entre la IP del host y la IP del dispositivo Intel AMT con la sugerencia de que

hay que configurar direcciones IP diferentes para AMT funcionando con IPs estáticas.

y una explicación:

Cuando configure la máquina vPro con IPs estáticas, AMT utilizará la función dirección mac llamada manageability mac que entra en juego sólo en modo de IP estática. La dirección mac de manejabilidad es diferente de la dirección mac presentada por el host.

Confirmo que el uso de DHCP con AMT y Host conduce a problemas de enrutamiento. p.ej. ping mislead:

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

1voto

Roman Sevko Puntos 21

¿No se "bloquearán" los paquetes que vuelven del host remoto y nunca llegarán al sistema operativo?

Todos los paquetes del host remoto con "AMT-ports" nunca llegan a ningún SO. Son interceptados por Intel ME/AMT. Por defecto son los puertos 16992-16995, 5900 (AMT ver. 6+), 623, 664.

1voto

Lukáš Kučera Puntos 11

Hay que tener en cuenta que AMT está pensada como tecnología OOBM de cliente, no de servidor. Por lo tanto sí, puede ocurrir que tu ordenador decida utilizar los puertos AMT, pero sólo en el caso de que lo hayas configurado específicamente para ello. La mayoría de los sistemas operativos vienen con puertos efímeros preconfigurados en el rango 49152 a 65535 como sugiere la especificación IANA, algunas distribuciones de Linux con 32768 a 61000 y el viejo Windows con 1025-5000.

Así que desde mi punto de vista es seguro usar IP compartida para AMT ya que sus puertos no están en rango efímero (a menos que sepas lo que haces, y cambies esta configuración en particular) y no debe ser usado como puerto de escucha por ninguna aplicación.

-2voto

Mark Puntos 1

Una solución podría ser configurar los puertos para la pila TCP de Windows utilizando netsh .

Por defecto, Windows utiliza el puerto 49152 >> 65636 (o cualquiera que sea el límite superior) Así que es muy seguro utilizar AMT. Puedes establecer el rango de puertos con netsh . Por ejemplo, siempre utilizo unos 1000 puertos para las máquinas perimetrales.

Además, Intel elimina los comandos AMT y pasa el resto del tráfico en esos puertos (16991-16995 en realidad) al sistema operativo (si hay un sistema operativo presente). Así que si usted tiene una aplicación que abrió un puerto en el rango de AMT, el tráfico seguirá pasando por el sistema operativo a la aplicación, porque como he dicho, Intel sólo elimina los comandos de gestión AMT. Es poco probable que tu aplicación esté enviando comandos AMT.

4 votos

Esta respuesta asume (1) que estás usando Windows, y (2) que no estás usando ningún software que pueda intentar usar puertos solapados por AMT por otras razones. (puede tener, por ejemplo, una aplicación VoIP que utilice puertos UDP aleatorios) También hace una afirmación sobre cómo Intel "elimina" los comandos AMT, lo que se demostró claramente que es falso en mi respuesta. ¿Puede proporcionar una referencia que respalde su afirmación? No me sorprendería que Intel considerara esto un error y lo arreglara algún día, pero en el momento en que publiqué mi respuesta, claramente no lo habían hecho.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X