Skip to content

ANSIBLE🔗

Problema de acceso a equipos🔗

El script oficial de Ansible para configurar WinRM abarca la mayor parte de la configuración, pero no contempla bloqueos en la red, problemas de resolución de nombres o puertos bloqueados en Windows 11.

Para aislar por qué algunos equipos no responden, ejecuta este procedimiento de depuración paso a paso.

1. Comprobaciones rápidas en el cliente local🔗

Ejecuta estos comandos en la máquina donde falla la conexión (o mediante acceso local) desde PowerShell como Administrador:

# Verificar si el servicio WinRM está iniciado
Get-Service WinRM

# Verificar qué puertos están escuchando (5985 para HTTP, 5986 para HTTPS)
Get-NetTCPConnection -LocalPort 5985, 5986 -ErrorAction SilentlyContinue | Select-Object LocalAddress, LocalPort, State

# Verificar la configuración de escucha de WinRM
winrm enumerate winrm/config/listener
  • Si el servicio está detenido: Ejecuta Start-Service WinRM.
  • Si no hay listeners: Re-ejecuta $file añadiendo -EnableKB2894841 o configura manualmente un listener con winrm quickconfig.

2. Firewall de Windows y perfiles de red🔗

En Windows 11, si la interfaz de red no está realmente marcada como Privada o hay reglas de firewall restrictivas, el tráfico entrante será rechazado.

# 1. Comprobar que TODAS las interfaces activas son Privadas/Dominio
Get-NetConnectionProfile

# 2. Verificar que el Firewall permite tráfico WinRM (Puertos 5985/5986)
Get-NetFirewallRule -DisplayGroup "Windows Remote Management" | Select-Object DisplayName, Enabled, Profile

Si las reglas están deshabilitadas, actívalas manualmente:

Enable-NetFirewallRule -DisplayGroup "Windows Remote Management"

3. Depuración de conectividad remota (Desde la máquina de origen / Ansible)🔗

A. Prueba de puerto TCP desde PowerShell (Origen)🔗

Ejecuta desde un equipo con acceso a la red para ver si el puerto responde:

Test-NetConnection -ComputerName "IP_O_NOMBRE_EQUIPO" -Port 5985
  • TcpTestSucceeded : False $\rightarrow$ Existe un Firewall intermedio (router, antivirus local, VPN) o el servicio no está escuchando en esa IP.
  • TcpTestSucceeded : True $\rightarrow$ El puerto está abierto; el problema es de autenticación o cifrado.

B. Validar Autenticación WinRM🔗

Si usas autenticación Kerberos/NTLM en entorno de Dominio o Grupo de Trabajo (Workgroup):

# En entornos de Grupo de Trabajo (no dominio), la máquina de origen necesita confiar en el host remoto:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "IP_O_NOMBRE_EQUIPO" -Force

# Probar autenticación WinRM directa
Test-WSMan -ComputerName "IP_O_NOMBRE_EQUIPO"

Causa raíz común en Windows 11 y cómo resolverla🔗

  1. Filtro de Cuentas Locales (UAC Remote Restrictions): Solo si usas cuentas locales no de Dominio. Por defecto, Windows bloquea conexiones administrativas remotas con usuarios locales. Habilita el acceso agregando este valor al registro:
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "LocalAccountTokenFilterPolicy" -Value 1 -PropertyType DWord -Force
  1. Antivirus de Terceros / EDR: Muchos suites de seguridad (Defender for Endpoint, SentinelOne, Kaspersky, CrowdStrike) bloquean conexiones WinRM entrantes independientemente de la configuración del Firewall de Windows.

Revisa los logs del antivirus en los equipos inalcanzables.

  1. Múltiples Adaptadores de Red (VPN/Virtualización): Si la máquina tiene adaptadores virtuales (Hyper-V, WSL, VPN), el script Set-NetConnectionProfile puede estar cambiando solo una red y dejando otra como Pública, lo que activa de nuevo el firewall.
Get-NetAdapter | Where-Object Status -eq "Up"

Ese error ocurre porque tu sistema operativo está en español. En Windows en español, el parámetro -DisplayGroup usa el nombre localizado: "Administración remota de Windows" (o se debe filtrar directamente por el nombre técnico de las reglas en lugar del grupo de visualización).

Ejecuta cualquiera de las siguientes alternativas en PowerShell como Administrador:

Opción 1: Usar el nombre localizado en español🔗

# Consultar las reglas
Get-NetFirewallRule -DisplayGroup "Administración remota de Windows" | Select-Object DisplayName, Enabled, Profile

# Habilitar las reglas
Enable-NetFirewallRule -DisplayGroup "Administración remota de Windows"

Opción 2: Usar los nombres técnicos de las reglas (Recomendado)🔗

Esta opción funciona independientemente del idioma del sistema operativo (español o inglés):

# Habilitar reglas para HTTP (Puerto 5985) y HTTPS (Puerto 5986)
Enable-NetFirewallRule -Name "WINRM-HTTP-In-TCP", "WINRM-HTTP-In-TCP-PUBLIC", "WINRM-HTTPS-In-TCP", "WINRM-HTTPS-In-TCP-PUBLIC" -ErrorAction SilentlyContinue

# Verificar su estado
Get-NetFirewallRule -Name "WINRM-HTTP-In-TCP*", "WINRM-HTTPS-In-TCP*" | Select-Object Name, DisplayName, Enabled, Profile

Opción 3: Forzar la apertura por el número de puerto directamente🔗

Si por alguna razón las reglas predeterminadas de WinRM no existen o están dañadas, puedes crear una regla explícita para los puertos de WinRM:

New-NetFirewallRule -Name "WinRM_Custom_5985" -DisplayName "WinRM HTTP Custom" -Enabled True -Direction Inbound -Protocol TCP -LocalPort 5985 -Action Allow
New-NetFirewallRule -Name "WinRM_Custom_5986" -DisplayName "WinRM HTTPS Custom" -Enabled True -Direction Inbound -Protocol TCP -LocalPort 5986 -Action Allow

Una vez ejecutada la Opción 1 u Opción 2, vuelve a probar la conectividad remota desde tu equipo de origen.