Resolución de Problemas en Servicios de Red, DNS y Autenticación

1. Diagnóstico de Servicios DHCP y VLAN

• a) El cliente de VLAN 10 obtiene dirección, máscara y gateway, pero recibe un resolver público como DNS. Por ello, puede alcanzar el servidor web por IP, pero falla la resolución de nombres internos: 8.8.8.8 no conoce la zona privada. Se debe corregir la opción DHCP 006 para entregar el DNS interno 10.10.10.10.
• b) El cliente de VLAN 20 genera una dirección APIPA (169.254.x.x). Aunque el ámbito esté activo, la solicitud DHCP es broadcast y no atraviesa el router. Al no existir un DHCP Relay en la interfaz, la petición no llega al servidor.
• c) El relay recibe el broadcast DHCP y lo reenvía al servidor como tráfico dirigido, permitiendo que este seleccione el ámbito correcto.
• d) Orden de resolución de problemas:
  1. Revisar la configuración completa del cliente.
  2. Comprobar VLAN, interfaz y conectividad básica.
  3. Verificar el relay de cada interfaz.
  4. Revisar estado y ocupación del ámbito.
  5. Comprobar concesiones y logs.
  6. Validar las opciones 006 y 015.
  7. Probar una consulta directa al DNS interno.

2. Gestión de Registros DNS y Caché

• Tipos de registros:
  • A: Relaciona un nombre con una dirección IPv4.
  • CNAME: Define un alias que apunta a otro nombre.
  • PTR: Permite la resolución inversa.
  • SRV: Publica la ubicación de servicios (LDAP, Kerberos).
  • MX: Indica servidores de correo.
  • NS: Identifica servidores autoritativos.
  • SOA: Contiene metadatos de autoridad de la zona.
  • TXT: Publica texto estructurado o verificaciones.
• b) El cliente conserva la respuesta almacenada en caché durante el TTL (Time To Live). Si se obtuvo a las 10:15 con un TTL de 3600s, será válida hasta las 11:15, ignorando cambios en el servidor autoritativo.
• c) Secuencia de migración: Reducir el TTL, esperar su expiración, realizar el cambio del registro A, comprobar la respuesta autoritativa y volver a elevar el TTL.
• d) El CNAME solo modifica la resolución de nombres; no sustituye a una redirección HTTP, la cual requiere una respuesta específica del servidor web.

3. Autenticación y Seguridad (AAA)

• c) Modelo AAA: Autenticación (identidad), Autorización (permisos) y Accounting (registro de sesión).
• d) Orden de evidencias en FreeRADIUS:
  1. IP del punto de acceso en clients.conf.
  2. Coincidencia del shared secret.
  3. Conectividad entre AP y FreeRADIUS.
  4. Módulo LDAP habilitado.
  5. Existencia y atributos del usuario.
  6. Revisión de logs o modo debug.
  7. Prueba final (Access-Accept).

4. Permisos y Control de Acceso (ACL)

• c) La solución más precisa es una ACL individual para conceder lectura, evitando modificar la responsabilidad del fichero o abrir acceso a todos los usuarios.
• d) Gestión de permisos: chown cambia el propietario, chgrp el grupo, chmod modifica las clases estándar (owner-group-others) y las ACL permiten permisos granulares.

5. Diagnóstico de Servidores Web y SSL

• b) HTTPS falla si el módulo SSL no está habilitado o el VirtualHost 443 no está activo. Se requiere soporte SSL/TLS y un certificado válido.
• c) Si el nombre no resuelve, la petición no llega al servidor. Si llega al access log pero sirve el sitio incorrecto, el problema reside en la selección del VirtualHost o la cabecera Host.
• d) Una prueba de solo cabeceras permite verificar estados y redirecciones sin descargar el cuerpo.

6. Infraestructura de Active Directory

• b) Active Directory depende de DNS para localizar controladores mediante registros SRV, que publican servicios, puertos y prioridades.
• e) Un rol define la función principal del servidor (ej. DNS, AD DS), mientras que una característica es un componente de soporte.