Windows Server 2025 / Cómo solucionar problemas de IP, DNS y DHCP

Para diagnosticar una conexión en Windows Server 2025, compruebe por separado la configuración IP, la ruta, la resolución de nombres DNS y el servicio que quiere utilizar. Registre la configuración actual de CLIENT1, compárela con un caso que funcione en la misma red y cambie una sola causa probable antes de repetir exactamente la prueba fallida. Un ping, una consulta DNS y una conexión a un puerto aportan evidencias diferentes.

Defina el fallo y los cambios recientes

Delimite el fallo: ¿afecta a todos los clientes o a uno?, ¿fallan nombres y direcciones o solo nombres?, ¿falla un servicio concreto? Anote destino, hora, error y cambios recientes, como reinicios, adaptadores, conmutadores virtuales u opciones DHCP. IP significa protocolo de Internet; DNS es el sistema de nombres de dominio y DHCP, el protocolo de configuración dinámica de host. Compare con un cliente del mismo segmento y con la misma prueba; cambiar a la vez DNS y firewall impide saber qué corrección tuvo efecto.

Acceder por IP puede servir para separar un problema de nombres, pero no siempre equivale a acceder por el nombre del servicio: pueden cambiar los requisitos de certificado y de Kerberos, el protocolo de autenticación. Por defecto Windows no intenta Kerberos cuando el destino se expresa como IP, según la explicación de Kerberos y destinos IP. No convierta una prueba de diagnóstico en un método permanente de conexión ni ignore una advertencia de certificado.

Lea la configuración real del cliente

ipconfig /all
Get-NetIPConfiguration
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4

Ejecute este bloque en Windows PowerShell desde la consola de CLIENT1. Identifique el adaptador del laboratorio y anote IP, máscara, DNS, servidor DHCP, sufijo y modo automático o manual. Tras la práctica de DHCP, espere 172.24.50.100–172.24.50.150 con máscara 255.255.255.0 y DNS 172.24.50.10. Get-NetAdapter ayuda a revisar estado y adaptador; Get-NetRoute muestra prefijos y siguiente salto, incluida la ruta predeterminada 0.0.0.0/0 cuando exista. Una red aislada sin router puede comunicarse dentro de su subred sin gateway: la falta de Internet en ese diseño es esperada. Si falta una interfaz en Get-NetIPConfiguration, revise -All o seleccione su índice real, como explica su referencia de configuración IP.

Una dirección 169.254.x.x sugiere que no se obtuvo una concesión utilizable; no demuestra por sí sola que el servidor DHCP esté averiado. Revise primero que la máquina esté encendida, el adaptador habilitado y conectado al conmutador correcto, y la obtención de IP automática si corresponde. Compare el servidor DHCP real con DC1, no solo la dirección recibida. La guía de diagnóstico del cliente DHCP señala los registros Operational y Admin de eventos del cliente DHCP en el Visor de eventos, dentro de Registros de aplicaciones y servicios. Busque eventos de la misma hora y adaptador del fallo.

Separe la conectividad del acceso al servicio

ping 172.24.50.10
Test-NetConnection -ComputerName 172.24.50.20 -Port 445

Ejecute estas dos pruebas desde CLIENT1. Ping comprueba respuestas del protocolo de mensajes de control de Internet (ICMP); una respuesta bloqueada no implica que todos los servicios fallen. Test-NetConnection con -Port comprueba una conexión del protocolo de control de transmisión (TCP): revise TcpTestSucceeded para ese destino y puerto, según su referencia de diagnóstico de conexiones. El puerto 445 corresponde a archivos compartidos mediante SMB (Server Message Block). Solo espere éxito si FS1 ya ofrece ese servicio en .20; en esta fase aún puede no estar preparado. True no demuestra permisos de recurso compartido, autenticación ni lectura de un archivo.

Si falla dentro de la misma subred, compruebe alimentación y conexión de las máquinas virtuales, conmutador, IP duplicadas y máscaras. Si solo falla el acceso externo, examine el gateway real, las rutas, la traducción de direcciones de red (NAT) y las reglas de salida; no invente un router para una red aislada. Antes de cambiar un puerto de prueba, confirme que deba existir un servicio escuchando. Revise el perfil, el origen permitido y el destino de las reglas pertinentes del firewall sin desactivarlo globalmente.

Compare el DNS explícito y la resolución predeterminada

Resolve-DnsName 'fs1.lab.example.test' -Type A -Server 172.24.50.10
nslookup fs1.lab.example.test 172.24.50.10
Resolve-DnsName 'fs1.lab.example.test' -Type A

En CLIENT1, las primeras dos consultas señalan el DNS de DC1, 172.24.50.10; la última usa la resolución configurada del cliente. Si está creado el registro A de fs1.lab.example.test, espere 172.24.50.20 como dirección resuelta, no confunda esa respuesta con la dirección del servidor DNS. Nslookup permite comparar una consulta sin utilizar la caché DNS del cliente. Si la consulta dirigida funciona y la predeterminada falla, revise configuración de DNS, adaptadores, políticas y caché; es una pista, no una causa ya demostrada. Un nombre de dominio completo (FQDN, Fully Qualified Domain Name) que funciona frente a un nombre corto que falla orienta hacia el sufijo y la lista de búsqueda.

Separe NXDOMAIN, que indica que el nombre consultado no existe, de un tiempo de espera sin respuesta; también puede existir el nombre sin el tipo de registro solicitado. Use las comprobaciones DNS del cliente junto con las comprobaciones de zonas y reenviadores del servidor. Clear-DnsClientCache vacía la caché del cliente local; Clear-DnsServerCache actúa sobre la del servicio DNS del servidor. Incluso DC1 tiene papeles de cliente y servidor distintos. Identifique cuál es relevante y conserve evidencia antes de vaciarla; ninguna de esas acciones corrige un registro erróneo en la zona autoritativa. Si solo falla resolución externa, compruebe los reenviadores y la ruta de salida sin reemplazar el DNS interno por uno público.

Compruebe DHCP y repita la prueba original

En DC1, abra Windows PowerShell como administrador y consulte el servidor local con el bloque siguiente. Verifique DHCPServer como Running, el ámbito 172.24.50.0 activo, capacidad disponible y la concesión correspondiente al cliente real. Revise además la vinculación a la interfaz del laboratorio y, solo en un dominio existente, la autorización en Active Directory. La guía general de diagnóstico DHCP incluye estas comprobaciones. Entre subredes puede necesitarse un agente de retransmisión DHCP; no lo añada para resolver un fallo en un laboratorio de un único conmutador.

Get-Service DHCPServer
Get-DhcpServerv4Scope
Get-DhcpServerv4ScopeStatistics -ScopeId 172.24.50.0
Get-DhcpServerv4Lease -ScopeId 172.24.50.0

Si necesita renovar, hágalo desde la consola de CLIENT1 y solo en el adaptador previsto. Después de un cambio, repita el mismo nombre, IP o puerto que fallaba y confirme también que las funciones antes correctas siguen funcionando. Si no mejora, restaure únicamente el valor cambiado y conserve comando, destino, hora y error. Desactivar todo el firewall, vaciar todas las cachés o recrear el ámbito simultáneamente elimina pistas y dificulta la recuperación.

Por ejemplo, si la consulta directa a .10 responde correctamente pero la predeterminada falla y descubre un DNS manual equivocado en CLIENT1, anote el valor inicial y abra ncpa.cpl → propiedades del adaptador aislado → Protocolo de Internet versión 4 (TCP/IPv4) → Propiedades. Corrija solo el DNS necesario a 172.24.50.10; mantenga IP, máscara y gateway, y repita ambas consultas. Si el DNS procede de DHCP, revise la opción 006 del ámbito y renueve el cliente en vez de ocultar el error con una excepción manual; la configuración del ámbito y sus opciones DHCP muestra cómo comprobarlo.