Planear cómo reactivar clientes en Configuration Manager
Se aplica a: Configuration Manager (rama actual)
Configuration Manager admite paquetes de reactivación tradicionales para reactivar equipos en modo de suspensión cuando quiera instalar el software necesario, como las actualizaciones de software y las aplicaciones.
Nota:
En este artículo se describe cómo funciona una versión anterior de Wake on LAN. Esta funcionalidad sigue existiendo en Configuration Manager versión 1810, que también incluye una versión más reciente de Wake en LAN. Ambas versiones de Wake on LAN pueden habilitarse simultáneamente y, en muchos casos, se habilitarán. Para obtener más información sobre cómo funciona la nueva versión de Wake on LAN a partir de 1810 y cómo habilitar una o ambas versiones, consulte Configuración de Wake on LAN.
Cómo reactivar clientes en Configuration Manager
Configuration Manager admite paquetes de reactivación tradicionales para reactivar equipos en modo de suspensión cuando quiera instalar el software necesario, como las actualizaciones de software y las aplicaciones.
Puede complementar el método de paquete de reactivación tradicional mediante la configuración del cliente proxy de reactivación. El proxy de reactivación usa un protocolo punto a punto y equipos elegidos para comprobar si otros equipos de la subred están despiertos y reactivarlos si es necesario. Cuando el sitio está configurado para Wake On LAN y los clientes están configurados para el proxy de reactivación, el proceso funciona de la siguiente manera:
Los equipos con el cliente Configuration Manager instalado y que no están inactivos en la subred comprueban si otros equipos de la subred están despiertos. Para realizar esta comprobación, se envían entre sí un comando de ping TCP/IP cada cinco segundos.
Si no hay respuesta de otros equipos, se supone que están dormidos. Los equipos que están despiertos se convierten en el equipo administrador de la subred.
Dado que es posible que un equipo no responda debido a un motivo que no sea que está inactivo (por ejemplo, está desactivado, quitado de la red o la configuración del cliente de reactivación del proxy ya no se aplica), los equipos reciben un paquete de reactivación todos los días a las 2 p. m. hora local. Los equipos que no responden ya no se supone que estén dormidos y no se despertarán mediante el proxy de reactivación.
Para admitir el proxy de reactivación, al menos tres equipos deben estar despiertos para cada subred. Para lograr este requisito, tres equipos se eligen de forma no determinista para ser equipos protectores de la subred. Este estado significa que permanecen despiertos, a pesar de cualquier directiva de energía configurada para suspender o hibernar después de un período de inactividad. Los equipos guardianes respetan los comandos de apagado o reinicio, por ejemplo, como resultado de las tareas de mantenimiento. Si se produce esta acción, los equipos guardianes restantes reactivan otro equipo en la subred para que la subred siga teniendo tres equipos guardianes.
Los equipos del administrador piden al conmutador de red que redirija el tráfico de red de los equipos en suspensión a sí mismos.
El redireccionamiento lo logra el equipo administrador que difunde una trama Ethernet que usa la dirección MAC del equipo en suspensión como dirección de origen. Este comportamiento hace que el conmutador de red se comporte como si el equipo en suspensión se hubiera movido al mismo puerto en el que está el equipo administrador. El equipo administrador también envía paquetes ARP para que los equipos en suspensión mantengan la entrada actualizada en la memoria caché ARP. El equipo administrador también responde a las solicitudes ARP en nombre del equipo en suspensión y responde con la dirección MAC del equipo en suspensión.
Advertencia
Durante este proceso, la asignación de IP a MAC para el equipo en suspensión sigue siendo la misma. El proxy de reactivación funciona informando al conmutador de red de que un adaptador de red diferente usa el puerto registrado por otro adaptador de red. Sin embargo, este comportamiento se conoce como aleta MAC y es inusual para la operación de red estándar. Algunas herramientas de supervisión de red buscan este comportamiento y pueden suponer que algo está mal. Por lo tanto, estas herramientas de supervisión pueden generar alertas o apagar puertos cuando se usa el proxy de reactivación.
No use el proxy de reactivación si las herramientas y servicios de supervisión de red no permiten aletas MAC.
Cuando un equipo administrador ve una nueva solicitud de conexión TCP para un equipo en suspensión y la solicitud es a un puerto en el que el equipo en suspensión estaba escuchando antes de que se suspendiera, el equipo administrador envía un paquete de reactivación al equipo en suspensión y, a continuación, deja de redirigir el tráfico de este equipo.
El equipo en suspensión recibe el paquete de reactivación y se reactiva. El equipo remitente reintenta automáticamente la conexión y, esta vez, el equipo está despierto y puede responder.
El proxy de reactivación tiene los siguientes requisitos previos y limitaciones:
Importante
Si tiene un equipo independiente responsable de la infraestructura de red y los servicios de red, notifique e incluya a este equipo durante el período de evaluación y pruebas. Por ejemplo, en una red que usa el control de acceso de red 802.1X, el proxy de reactivación no funcionará y puede interrumpir el servicio de red. Además, el proxy de reactivación podría provocar que algunas herramientas de supervisión de red generen alertas cuando las herramientas detecten el tráfico para reactivar otros equipos.
Todos los sistemas operativos Windows que aparecen como clientes admitidos en Sistemas operativos compatibles para clientes y dispositivos son compatibles con Wake On LAN.
No se admiten los sistemas operativos invitados que se ejecutan en una máquina virtual.
Los clientes deben estar habilitados para el proxy de reactivación mediante la configuración de cliente. Aunque la operación de proxy de reactivación no depende del inventario de hardware, los clientes no notifican la instalación del servicio de proxy de reactivación a menos que estén habilitados para el inventario de hardware y envíen al menos un inventario de hardware.
Los adaptadores de red (y posiblemente el BIOS) deben estar habilitados y configurados para los paquetes de reactivación. Si el adaptador de red no está configurado para paquetes de reactivación o esta opción está deshabilitada, Configuration Manager lo configurará y habilitará automáticamente para un equipo cuando reciba la configuración de cliente para habilitar el proxy de reactivación.
Si un equipo tiene más de un adaptador de red, no puede configurar qué adaptador usar para el proxy de reactivación; la elección no es determinista. Sin embargo, el adaptador elegido se registra en el archivo SleepAgent_<DOMAIN>@SYSTEM_0.log.
La red debe permitir solicitudes de eco ICMP (al menos dentro de la subred). No puede configurar el intervalo de cinco segundos que se usa para enviar los comandos de ping ICMP.
La comunicación no está cifrada y no autenticada, y no se admite IPsec.
No se admiten las siguientes configuraciones de red:
802.1X con autenticación de puerto
Redes inalámbricas
Conmutadores de red que enlazan direcciones MAC a puertos específicos
Redes solo IPv6
Duraciones de concesión dhcp inferiores a 24 horas
Si desea reactivar equipos para la instalación programada de software, debe configurar cada sitio principal para usar paquetes de reactivación.
Para usar el proxy de reactivación, debe implementar la configuración del cliente proxy de reactivación de Power Management además de configurar el sitio principal.
Decida si desea usar paquetes de difusión dirigidos por subred, o paquetes de unidifusión y qué número de puerto UDP usar. De forma predeterminada, los paquetes de reactivación tradicionales se transmiten mediante el puerto UDP 9, pero para ayudar a aumentar la seguridad, puede seleccionar un puerto alternativo para el sitio si este puerto alternativo es compatible con enrutadores y firewalls intermedios.
Elegir entre unidifusión y Subnet-Directed difusión para wake-on-LAN
Si decide reactivar equipos mediante el envío de paquetes de reactivación tradicionales, debe decidir si desea transmitir paquetes de unidifusión o paquetes de difusión directos de subred. Si usa el proxy de reactivación, debe usar paquetes de unidifusión. De lo contrario, use la tabla siguiente para ayudarle a determinar qué método de transmisión elegir.
| Método de transmisión | Ventaja | Desventaja |
|---|---|---|
| Unidifusión | Solución más segura que las difusiones dirigidas por subred porque el paquete se envía directamente a un equipo en lugar de a todos los equipos de una subred. Es posible que no requiera la reconfiguración de los enrutadores (es posible que tenga que configurar la memoria caché ARP). Consume menos ancho de banda de red que las transmisiones de difusión dirigidas por subred. Compatible con IPv4 e IPv6. |
Los paquetes de reactivación no encuentran equipos de destino que hayan cambiado su dirección de subred después de la última programación de inventario de hardware. Los conmutadores pueden tener que configurarse para reenviar paquetes UDP. Es posible que algunos adaptadores de red no respondan a los paquetes de reactivación en todos los estados de suspensión cuando usan unidifusión como método de transmisión. |
| difusión de Subnet-Directed | Mayor tasa de éxito que la unidifusión si tiene equipos que cambian con frecuencia su dirección IP en la misma subred. No se requiere ninguna reconfiguración del conmutador. Alta tasa de compatibilidad con adaptadores de equipo para todos los estados de suspensión, ya que las difusiones dirigidas por subredes eran el método de transmisión original para enviar paquetes de reactivación. |
Solución menos segura que el uso de unidifusión porque un atacante podría enviar flujos continuos de solicitudes de eco ICMP desde una dirección de origen falsificada a la dirección de difusión dirigida. Esto hace que todos los hosts respondan a esa dirección de origen. Si los enrutadores están configurados para permitir difusiones dirigidas por subred, se recomienda la configuración adicional por motivos de seguridad: - Configurar enrutadores para permitir solo difusiones dirigidas por IP desde el servidor de sitio Configuration Manager, mediante un número de puerto UDP especificado. : configure Configuration Manager para usar el número de puerto no predeterminado especificado. Es posible que sea necesario reconfigurar todos los enrutadores intermedios para habilitar las difusiones dirigidas por subred. Consume más ancho de banda de red que las transmisiones de unidifusión. Solo se admite con IPv4; No se admite IPv6. |
Advertencia
Hay riesgos de seguridad asociados con las difusiones dirigidas por subred: un atacante podría enviar secuencias continuas de solicitudes de eco del Protocolo de mensajes de control de Internet (ICMP) desde una dirección de origen falsificada a la dirección de difusión dirigida, lo que hace que todos los hosts respondan a esa dirección de origen. Este tipo de ataque por denegación de servicio se denomina normalmente ataque pitufo y normalmente se mitiga al no habilitar difusiones dirigidas a subredes.