Aislamiento de servidor y dominio mediante IPsec y Directiva de grupo
Capítulo 7: Solución de problemas de IPsec
En este capítulo se proporciona información acerca de cómo solucionar problemas de seguridad del protocolo Internet (IPsec), como en los escenarios de aislamiento de servidor y dominio, y se basa en la experiencia y los procesos del equipo de tecnología de la información (TI) de Microsoft. Siempre que sea posible, en este capítulo se hace referencia a los procedimientos de solución de problemas de Microsoft e información relacionada. La asistencia del departamento de TI de Microsoft se basa en un modelo de varios niveles y el servicio de asistencia se denomina asistencia de nivel 1. Los procedimientos de transferencia de incidencias permiten al personal del servicio de asistencia transferir las incidencias que requieran la ayuda de especialistas. Los procedimientos de este capítulo hacen referencia a los tres niveles de asistencia: nivel 1, nivel 2 y nivel 3. Para garantizar que la guía resulta práctica y concisa en la medida de lo posible, la mayor parte del contenido está en el nivel 2. Se proporcionan indicaciones para el nivel 1 inicial para que una organización determine lo más rápidamente posible si un problema está relacionado con IPsec y, en caso afirmativo, genere la información necesaria para ayudar al personal de soporte técnico de nivel 2 a solucionar el problema. La información más detallada y compleja necesaria para los esfuerzos de solución de problemas del nivel 3 queda fuera del alcance de este capítulo. Si la información proporcionada en este capítulo no soluciona el problema de IPsec, Microsoft recomienda que se ponga en contacto con los Servicios de soporte técnico de Microsoft® para obtener ayuda adicional. Muchos de los procedimientos de soporte técnico, herramientas y secuencias de comandos que utiliza Microsoft se proporcionan en este capítulo de referencia. Estas recomendaciones y herramientas se deben adaptar según las necesidades específicas de la organización. Cuando se utiliza IPsec para proteger el tráfico del protocolo de control de transmisión (TCP) y del protocolo de datagrama de usuario (UDP) de la red, los procedimientos y las herramientas de solución de problemas de red TCP/IP habituales pueden no ser eficaces. Por este motivo, es importante planear y desarrollar técnicas de solución de problemas específicas de IPsec que se puedan utilizar si se produce un problema entre equipos que emplean (o intentan emplear) IPsec para sus comunicaciones. En esta páginaNiveles de soporte técnico y transferencia de incidenciasEn Microsoft, el soporte técnico de aislamiento de servidor y dominio es una oferta estándar y está definido en los contratos de nivel de servicio estándar. El soporte técnico de aislamiento se proporciona en los siguientes niveles:
En la siguiente sección se resumen las técnicas de solución de problemas que puede emplear el personal del servicio de asistencia en la organización de soporte técnico de nivel 1. Solución de problemas de nivel 1En esta sección se presenta el proceso global para solucionar problemas relacionados con IPsec utilizado por el personal del servicio de asistencia, que proporciona soporte técnico de nivel 1. Normalmente, el personal de soporte técnico de nivel 1 es personal del servicio de asistencia telefónico que intenta diagnosticar los problemas de forma remota. ¿El problema es IPsec?Es probable que el servicio de asistencia reciba llamadas del tipo “Me podía conectar al servidor x hasta que se activó IPsec” o “Ayer funcionaba todo y hoy no me puedo conectar a nada”. Por la experiencia del departamento de TI de Microsoft, la ejecución de IPsec incrementa el número de llamadas para todos los tipos de problemas de conectividad de red e incidencias de “acceso denegado” porque los usuarios prestan más atención a los comportamientos de la aplicación y de la red. Cuando alguien cree que puede estar relacionado con IPsec, llama al servicio de asistencia. Un plan de implementación de aislamiento de servidor y dominio debe incluir un sistema de clasificación de llamadas para que el personal del servicio de asistencia pueda ofrecer informes claros acerca del volumen y la naturaleza de los problemas relacionados con IPsec. Después de obtener la información administrativa correspondiente del llamador, el personal del servicio de asistencia debe seguir un proceso de solución de problemas definido. Debido a que los diseños de directiva de IPsec pueden tener consecuencias distintas en las comunicaciones y debido a que el proceso de ejecución puede durar varios días o semanas, se debe definir y actualizar un diagrama de flujo por cada conjunto de cambios de aislamiento que se implemente. El personal de administración del servicio de asistencia debe estar implicado en este proceso de planeamiento. El objetivo del servicio de asistencia debe ser clasificar el problema de modo que se puedan intentar soluciones conocidas. Si con estos intentos no se resuelve el problema, el personal del servicio de asistencia puede garantizar que se recopila la información correcta y que se transfiere el problema al soporte técnico de nivel 2. Por ejemplo, el servicio de asistencia debe poder identificar distintos tipos de problemas de las siguientes formas:
Según la organización, el servicio de asistencia puede utilizar Asistencia remota o Escritorio remoto para conectarse al equipo del llamador. Las directrices que se proporcionan en este capítulo no requieren acceso remoto, aunque pueden constituir herramientas útiles para que el personal de servicio de asistencia las utilice como alternativa en lugar de guiar al usuario por el complemento Monitor IPsec de Microsoft Management Console (MMC) o el visor del registro de sucesos. En los escenarios donde se utilice aislamiento de servidor sin aislamiento de dominio, el personal del servicio de asistencia debe conocer los servidores que son miembros del grupo de aislamiento. Asignar alcance y gravedadUna de las primeras preguntas que debe plantear el soporte técnico de nivel 1 es: ¿A quién afecta el problema? El personal de soporte técnico tiene que saber si otros usuarios experimentan el mismo problema y, en caso afirmativo, cuántos son y dónde se encuentran. A continuación, el personal de soporte técnico debe examinar el alcance del problema. Por ejemplo, ¿afecta la conectividad a un solo servidor o son problemas de mayor alcance, como errores de inicio de sesión o de autenticación en grandes partes de la red? Los problemas con la conectividad pueden implicar numerosos niveles y tecnologías distintos que se utilizan en las comunicaciones de red. Los ingenieros de soporte técnico deben conocer cómo funcionan las comunicaciones de red TCP/IP de Windows en general, así como problemas específicos relacionados con la solución. En esta sección se revisan los distintos tipos de problemas y cuestiones comunes que cada soporte técnico de nivel 1 debe afrontar.
Las otras dos características de la solución de aislamiento de servidor y dominio que también se encuentran normalmente en las implementaciones empresariales de IPsec son el uso de filtros de subred para definir los intervalos de direcciones empleados en la red interna y la aplicación de las directivas de IPsec que están basadas en la pertenencia a dominio y la pertenencia a grupos, independientemente de dónde se encuentre el equipo en la red interna. Por tanto, si hay un problema con el diseño de los filtros de subred o la ruta de acceso de red utilizada por dicho equipo para conectar con los otros equipos, es posible que sólo aparezcan problemas de conectividad en determinadas partes de la red, al utilizar direcciones IP concretas (por ejemplo, una dirección inalámbrica y no una de LAN) o únicamente en algunos equipos. Diagramas de flujo de solución de problemasLos diagramas de flujo de administración de llamadas de esta sección los ha desarrollado el departamento de TI de Microsoft como ayuda para clasificar los problemas de soporte técnico de IPsec de nivel 1. Además de las herramientas estándar, dos de los diagramas de flujo hacen referencia a una secuencia de comandos de actualización de la directiva IPsec, cuya descripción se proporciona en la sección "Ejemplos de secuencias de comandos de soporte técnico", incluida más adelante en este capítulo. La figura 7.1 se utiliza para el diagnóstico inicial y para determinar el tipo de problema:
Nota: en este diagrama de flujo se supone que el equipo del llamador ejecuta IPsec y que las zonas de búsqueda inversa de DNS están configuradas para permitir el funcionamiento correcto del comando ping. La figura 7.2 está diseñada para identificar los problemas con el equipo del llamador. Observe que, además del diagnóstico, en este diagrama de flujo se hace referencia al uso de una secuencia de actualización de la directiva IPsec (consulte "Ejemplos de secuencias de comandos de soporte técnico" más adelante en este capítulo) que puede solucionar el problema sin identificarlo necesariamente. Los pasos de la figura 7.2 ayudan a determinar los siguientes problemas posibles con el equipo del llamador:
La figura 7.3 está diseñada para identificar los problemas con un determinado equipo de destino. Tenga en cuenta que en este diagrama de flujo también se hace referencia al uso de una secuencia de comandos de actualización de la directiva IPsec que puede solucionar el problema sin identificarlo necesariamente. La figura 7.3 ayuda a determinar los siguientes problemas posibles con el equipo de destino (o la ruta de acceso a él):
Después de que el personal de soporte técnico de nivel 1 haya trabajado con los diagramas de flujo, el estado del problema será uno de los siguientes:
Prevención de ataques de ingeniería socialEn una solución de aislamiento, el personal del servicio de asistencia puede descubrir áreas específicas dentro del entorno de TI que no están protegidas por IPsec, como los equipos que son miembros de la lista de exenciones. No se pueden utilizar para proteger información confidencial porque en otras soluciones de seguridad dicha información esencial normalmente sólo está disponible para los equipos de soporte técnico de nivel superior. Por este motivo, el personal del servicio de asistencia debe estar formado para detectar y resistir los ataques de ingeniería social. En un ataque de ingeniería social, una persona que no es de confianza intenta obtener información acerca de cómo está implementada la seguridad y en qué puntos es débil, simplemente aprovechando la tendencia humana a confiar en otras personas. El personal del servicio de asistencia debe controlar atentamente la información siguiente:
El personal del servicio de asistencia también debe desconfiar en el caso de que un llamador solicite la conexión a su dirección IP de equipo para comprobar si hay algo incorrecto (por ejemplo, un atacante pide a alguien del servicio de asistencia que se conecte a su equipo mediante el uso compartido de archivos, Escritorio remoto, Telnet u otro protocolo de red). Si una persona del servicio de asistencia efectúa la conexión sin IPsec, el equipo del atacante puede obtener información acerca de la contraseña o (en algunos casos, como con Telnet) robarla. Esta situación puede producirse porque algunos protocolos de red de cliente no autentican en primer lugar y establecen una confianza segura con el equipo de destino, o no requieren protecciones de contraseña segura antes de revelar la identidad del usuario o la información relacionada con la contraseña. Ejemplos de secuencias de comandos de soporte técnicoEn la mayoría de los escenarios de solución de problemas, puede determinarse una solución rápidamente tras la identificación de la información adecuada. Esta información se puede averiguar con distintas herramientas de Windows, como a las que se hace referencia en los diagramas de flujo. En la solución de Woodgrove Bank, se desarrollaron una serie de secuencias de comandos para proporcionar información clave sin que fuera necesario que el personal de soporte técnico de nivel 1 tuviera un conocimiento detallado de las operaciones y la sintaxis de las herramientas. Estas secuencias de comandos están disponibles en la carpeta Herramientas y plantillas de la descarga de esta guía. Secuencias de comandos disponibles para el soporte técnico de nivel 1Si el usuario es un administrador local de su equipo, el personal del servicio de asistencia puede pedirle que ejecute una de las tres secuencias de comandos proporcionadas con esta solución. Estas secuencias de comandos son ejemplos de las secuencias de comandos personalizadas que se han utilizado para el entorno de Woodgrove Bank descrito en esta guía. Se describen en este capítulo para ilustrar el modo en que se pueden utilizar las secuencias de comandos para respaldar el proceso de solución de problemas. Nota: estas secuencias de comandos son ejemplos probados, pero Microsoft no ofrece soporte técnico para ellas. Se deben utilizar como base para la solución personalizada de una organización. IPsec_Debug.vbsAdemás de proporcionar información de depuración, esta secuencia de comandos puede corregir algunos problemas. Detiene y reinicia el servicio IPsec (lo que elimina todas las asociaciones de seguridad de IKE e IPsec actuales), obliga a una actualización de Directiva de grupo para volver a cargar la directiva IPsec asignada al dominio actual del servicio de directorio Active Directory® y actualiza la caché de directivas. Para evitar la pérdida de conectividad de las sesiones de escritorio remoto, la secuencia de comandos se debe descargar en el equipo del llamador y ejecutarse localmente mediante una cuenta que tenga privilegios administrativos. Utilice la siguiente sintaxis para ejecutar la secuencia de comandos en el símbolo del sistema: cscript IPsec_Debug.vbs La secuencia de comandos realiza las siguientes funciones:
Esta secuencia de comandos también habilita todos los registros relacionados con IPsec para la solución de problemas por parte del departamento de soporte técnico de nivel 2. Detect_IPsec_Policy.vbsEsta secuencia de comandos determina si el equipo está ejecutando la directiva IPsec correcta mediante la búsqueda en la caché del Registro local actual de la información de versión de la directiva IPsec de dominio. Utilice la siguiente sintaxis para ejecutar la secuencia de comandos en el símbolo del sistema: cscript Detect_IPsec_Policy.vbs Nota: esta secuencia de comandos también se llama desde IPsec_Debug.vbs y, por lo tanto, no necesita ejecutarse además de dicha secuencia de comandos. Refresh_IPsec_Policy.vbsSe trata de la secuencia de comandos de actualización de la directiva IPsec a la que se hace referencia en los diagramas de flujo de solución de problemas. Actualiza los vales del protocolo de autenticación Kerberos de equipo y de Directiva de grupo, y puede corregir el problema si éste se debe a una asignación de directiva IPsec incorrecta o a un error de descarga de Directiva de grupo. Utilice la siguiente sintaxis para ejecutar la secuencia de comandos en el símbolo del sistema: cscript Refresh_IPsec_Policy.vbs Transferencia de incidenciasCuando el personal del servicio de asistencia tenga que transferir un posible problema de IPsec, en el nivel 1 se debe recopilar la siguiente información y adjuntarla a la solicitud de servicio:
Los escenarios de aislamiento de servidor suelen tener su propio equipo de soporte técnico para investigar la pertenencia a los grupos de acceso a la red. Preparación de la solución de problemas de nivel 2El soporte técnico de nivel 2 tiene dos funciones principales. En primer lugar, al ser el destino de todas las transferencias de nivel 1, en el nivel 2 se validan los problemas y se revisan las acciones realizadas por el nivel 1 para garantizar que no se ha omitido ningún paso de solución de problemas. En este sentido, en el nivel 2 se debe confirmar que cualquier problema transferido se debe realmente a IPsec y no a un diagnóstico erróneo. En segundo lugar, como ingenieros de soporte técnico de red experimentados, el personal de soporte técnico de nivel 2 debe poder utilizar sus conocimientos y experiencia (se indican en la sección siguiente) para resolver de forma correcta el problema mediante el análisis de los registros sin obtener control administrativo del equipo. No obstante, los registros sólo capturan información, y las acciones correctivas requieren acceso administrativo. No se prevé que un ingeniero de soporte técnico de nivel 2 deba ser administrador de dominio o pueda realizar cambios en la directiva IPsec basada en dominio o en la pertenencia a grupos de equipo. Conocimientos de soporte técnico de nivel 2El personal que debe proporcionar soporte técnico de nivel 2 para IPsec debe disponer de conocimientos y experiencia en las siguientes áreas:
Problemas inherentes al uso de IPsecTal como se ha indicado en la sección anterior, el personal de soporte técnico de nivel 2 de una solución de aislamiento de servidor y dominio necesita conocer los detalles de las comunicaciones protegidas por IPsec, pero también debe poder aislar problemas relacionados con otros componentes de tecnología. Para que se establezca una comunicación IPsec correcta entre dos equipos, ambos normalmente requieren una directiva IPsec compatible. Por ejemplo, una directiva IPsec puede bloquear la comunicación si el equipo remoto no dispone de una directiva IPsec adecuada. Aunque esto puede ser un comportamiento previsto o aceptable durante la ejecución de un cambio de directiva, puede no ser tan evidente si bloquea la conectividad de red con uno o varios equipos y provoca advertencias o errores de aplicación. En el peor de los casos, un administrador puede asignar accidentalmente una directiva IPsec a todos los miembros del dominio que bloquee todo el tráfico. A menos que el error se corrija de inmediato con una asignación correcta que se replique rápidamente después de la asignación original, la replicación de la directiva perjudicial no se puede detener de forma sencilla. Este de tipo de error provoca una situación en la que las comunicaciones entre un cliente y un controlador de dominio requerirían el uso de IPsec. Debido a que la autenticación utilizada en esta solución se basa en el protocolo Kerberos, cualquier cliente que herede esta directiva no podría completar el proceso de inicio de sesión, ya que no podría obtener el vale Kerberos necesario para proteger las comunicaciones. Los administradores deben planear cuidadosamente cualquier cambio de directiva y asegurarse de que existen protecciones de procedimiento para mitigar este tipo de situación. En las guías enumeradas en la sección "Información adicional" al final de este capítulo se proporciona información general acerca de la solución de problemas de TCP/IP. No obstante, muchos de los procedimientos a los que se hace referencia en estas guías sólo funcionan mientras IPsec proporciona una conectividad correcta. Si se produce un error en IKE o IPsec, es probable que la mayoría de estos procedimientos y herramientas dejen de ser efectivos. En un escenario de aislamiento de servidor y dominio, es posible que algunos de los procedimientos documentados en las guías de información general no funcionen en absoluto, aunque IPsec proporcione una conectividad correcta. Para mantener la eficacia en un entorno de aislamiento de servidor y dominio, una organización de soporte técnico debe prever la actualización y la personalización de las herramientas y los procedimientos de solución de problemas. Debido a que existen muchas formas distintas en que se pueden implementar las directivas IPsec para controlar y proteger el tráfico, es improbable que las organizaciones puedan basarse únicamente en los procedimientos existentes y en un kit de herramientas genérico. Es importante para el personal de soporte técnico disponer de ejemplos documentados del resultado previsto de las herramientas de solución de problemas de red obtenidos de un entorno de laboratorio donde el aislamiento de servidor y dominio u otro tipo de implementación de IPsec funcione correctamente. En muchos casos, las herramientas de diagnóstico de red no prevén retrasos de tres segundos para el retroceso a texto no cifrado o los pequeños retrasos necesarios para la negociación IKE inicial de asociaciones de seguridad (SA) IPsec. Por lo tanto, las herramientas pueden mostrar un resultado al ejecutarse inicialmente y otro distinto al ejecutarlas unos segundos después. Asimismo, donde IPsec deniegue deliberadamente el acceso a la red, las herramientas informarán de errores. El tipo de error dependerá de la herramienta y del entorno de IPsec. Nota: en la sección dedicada al nivel 1, se emplearon los términos llamador y destino para ayudar al personal de soporte técnico a solucionar problemas comunes. En la sección del nivel 2 es preferible utilizar los términos iniciador y contestador de IPsec como ayuda para clarificar los procesos de solución de problemas más avanzados. En el resto de este capítulo se utilizan estos términos de IPsec. Directiva de grupo y pertenencia a gruposLa directiva IPsec basada en dominio depende de Directiva de grupo y la descarga de GPO. Si el sistema de Directiva de grupo cliente tiene errores al detectar cambios de GPO o al descargarlos, la conectividad de IPsec se puede ver afectada. Si la asignación de Directiva de grupo está controlada por la pertenencia a unidades organizativas (OU) y las cuentas de equipo se mueven accidentalmente a otra OU, se eliminan o se vuelven a crear en una OU errónea, podría asignarse una directiva IPsec no adecuada. Esta solución utiliza grupos de seguridad para controlar la asignación de directivas y el acceso a la red. La pertenencia a grupos se incluye en los vales del protocolo de autenticación Kerberos versión 5 (los vales TGT y los de servicio) que tienen una duración bastante prolongada. Por lo tanto, los administradores deben planear el tiempo que necesitan los equipos para recibir credenciales de vales TGT y de servicio de Kerberos que contengan actualizaciones de pertenencia a grupos. El protocolo Kerberos dificulta mucho la determinación de si los vales Kerberos de un equipo contienen la pertenencia a grupos adecuada. Esta dificultad es de "diseño", ya que toda la información acerca de la pertenencia a grupos se almacena de un modo cifrado en el vale. La pertenencia a grupos se debe determinar mediante la información del servicio de directorio, no de los vales. Autenticación KerberosEl diseño de aislamiento de servidor y dominio utiliza el protocolo Kerberos versión 5 para la autenticación IKE. Debido a que el protocolo Kerberos necesita una conectividad de red correcta y servicio disponible de DNS y de controladores de dominio, la ausencia de conectividad provoca un error en la autenticación Kerberos y en IKE (también se producirá un error en IKE si se produce en Kerberos). Por lo tanto, los problemas de conectividad entre el equipo A y el equipo B se pueden deber a una conectividad de red bloqueada entre el equipo A y el equipo C, que se deben a que el protocolo Kerberos no puede autenticarse con un controlador de dominio. En situaciones como ésta, la información proporcionada en los sucesos 547 de los registros de auditoría y seguridad de Windows normalmente proporciona orientación valiosa acerca del origen del problema. Tráfico entrante protegido por IPsec necesarioEsta solución de aislamiento de servidor y dominio especifica que se necesita comunicación protegida por IPsec para el acceso entrante. Este requisito puede provocar que las herramientas de supervisión remota que se ejecutan en equipos que no son de confianza o en dispositivos de supervisión de red dedicados informen de que no es posible ponerse en contacto con un equipo remoto. Si estos equipos o dispositivos no se pueden unir al entorno de "confianza", no podrán desempeñar su función de supervisión a menos que se agreguen algunas exenciones al diseño. La solución de problemas resulta complicada debido al hecho de que quizás se necesite IPsec para establecer la conexión con un host de confianza, lo que significa que es posible que el administrador no pueda conectar a un host de confianza y detener el servicio IPsec sin perder conectividad. Si la directiva IPsec del administrador permite retroceso a texto sin cifrar, en la conexión remota se producirá un retraso de tres o cuatro segundos después de que se detenga el servicio en el equipo remoto. No obstante, al detener el servicio IPsec en un equipo remoto se eliminarán las asociaciones de seguridad IPsec que utilicen el resto de los equipos conectados actualmente. Si estos equipos no pueden retroceder a texto sin cifrar, se detendrán las comunicaciones y, finalmente, se perderán las conexiones TCP. Debido a que las interrupciones bruscas de las comunicaciones TCP pueden provocar daños en los datos de las aplicaciones, la detención del servicio IPsec sólo se debe utilizar como la última opción en el proceso de solución de problemas. Antes de que se detenga el servicio IPsec, el equipo debe estar preparado para cerrarse de modo que todos los usuarios conectados y las aplicaciones puedan terminar correctamente las comunicaciones. Problemas de dirección de comunicaciónUn escenario habitual de solución de problemas es la comunicación correcta en una dirección pero no en la dirección inversa. La autenticación IKE normalmente requiere autenticación mutua entre los equipos. Si un equipo no puede obtener un vale Kerberos cuando inicia el modo principal IKE para un equipo remoto, se producirá un error en IKE. Esta situación se puede producir si el cliente Kerberos del equipo iniciador no puede tener acceso a un controlador de dominio del dominio del equipo de destino. Si los equipos son miembros de dominios que no confían mutuamente entre sí (confianza bidireccional), las negociaciones de modo principal IKE se realizarán correctamente cuando un equipo las inicie y se producirá un error si el otro equipo las inicia. De modo similar, los derechos de inicio de sesión de red entrante pueden ser distintos en los dos equipos. Es posible que se produzca un error en la negociación de modo rápido y modo principal IKE en una dirección no sólo por estos motivos, sino también si los diseños de directiva IPsec no son compatibles en ambos lados. Los servidores de seguridad basados en host que interceptan el tráfico por encima de la capa IPsec pueden exigir la direccionalidad en las conexiones. Algunos servidores de seguridad basados en host interceptan el tráfico por debajo de la capa IPsec. Después de establecer una comunicación IPsec correcta, es probable que se permita el tráfico protegido por IPsec en ambas direcciones durante un cierto período de tiempo. El filtrado activo por parte de un enrutador o servidor de seguridad también puede bloquear las acciones de regeneración de clave IKE o el flujo de tráfico IPsec sin afectar a otros protocolos de diagnóstico, como ICMP. Es posible que no se pueda tener acceso a los puertos TCP y UDP en un equipo debido a que no se está ejecutando un servicio o porque un dispositivo que funciona por encima de la capa IPsec (como Windows Firewall o un enrutador de red) está bloqueando el acceso. Solución de problemas de seguimientos de red y rutas de acceso de red avanzadasLos errores en la negociación de IKE normalmente provocan que el equipo deje de responder a la negociación IKE o, en algunos casos, vuelva a enviar el último mensaje "válido" hasta que caduque el límite de reintentos. IKE debe poder enviar datagramas UDP fragmentados que contengan vales Kerberos porque dichos paquetes suelen superar la unidad de transmisión máxima de ruta (PMTU) para la dirección IP de destino. Si no se admite la fragmentación correctamente, los dispositivos de red en una ruta determinada pueden descartar dichos fragmentos. Además, quizás la red no pase paquetes de protocolo IPsec o fragmentos de paquetes IPsec correctamente. La integración de IPsec con TCP permite que TCP reduzca el tamaño de paquete para aceptar la carga de los encabezados IPsec. No obstante, la negociación TCP del tamaño de segmento máximo (MSS) durante el protocolo de enlace TCP no tiene en cuenta la carga IPsec. Por lo tanto, hay un mayor requisito para la detección de ICMP PMTU en la red con el fin de garantizar una comunicación TCP protegida por IPsec correcta. Así pues, la solución de problemas de conectividad puede requerir seguimientos de red de uno o los dos lados de la comunicación, así como registros de ambos lados. Los ingenieros de soporte técnico deben saber leer los seguimientos de red y también comprender la negociación IKE. Los servidores deben tener instalado el software Monitor de red de Windows. Monitor de red de Windows 2000 proporciona análisis de AH e IKE de IPsec. Windows Server 2003 agrega compatibilidad para analizar IPsec ESP nula, analizar ESP cuando se desvía el cifrado y analizar la encapsulación UDP-EPS empleada para NAT transversal. Kit de herramientas de solución de problemasAntes de comenzar a solucionar problemas, es importante identificar las utilidades que pueden obtener información que sirva de ayuda para el proceso de solución de problemas. En esta sección no se intenta duplicar la información que se encuentra en la Ayuda de Windows 2000, Windows XP o Windows Server 2003 o a la que se puede tener acceso en la página de herramientas de solución de problemas del sitio Web de Microsoft Windows Server™ 2003 en www.microsoft.com/resources/documentation/ Aquí sólo se proporciona información de herramientas detallada si no se encuentra fácilmente en la página de herramientas de solución de problemas indicada o cuando resulte útil disponer de resúmenes por versiones de sistema operativo. Complemento Administración de la directiva de seguridad IP de MMCEl complemento Administración de la directiva de seguridad IP de MMC se utiliza para crear u administrar directivas IPsec locales o almacenadas en Active Directory. También se puede utilizar para modificar la directiva IPsec en equipos remotos. El complemento Administración de la directiva de seguridad IP de MMC se incluye en los sistemas operativos Windows Server 2003, Windows XP, Windows 2000 Server y Windows 2000 Professional y se puede utilizar para ver y editar detalles de directivas, filtros, listas de filtros y acciones de filtro de IPsec, así como para asignar y cancelar la asignación de directivas IPsec. Complemento Monitor de seguridad IP de MMCEl complemento Monitor de seguridad IP de MMC muestra las estadísticas de IPsec y las asociaciones de seguridad activas. También se utiliza para ver información acerca de los siguientes componentes de IPsec:
Aunque este complemento forma parte de los sistemas operativos Windows XP y Windows Server 2003, existen diferencias de funcionalidad y de interfaz entre las versiones de Windows XP y Windows Server 2003. Además, la versión de Windows Server 2003 tiene las siguientes características adicionales:
Hay disponible una actualización de este complemento para Windows XP como parte de la actualización que se describe en el artículo 818043 de Microsoft Knowledge Base, "Actualización de NAT-T de L2TP/IPSec para Windows XP y Windows 2000", que está disponible en http://support.microsoft.com/?kbid=818043. Esta actualización permite ver equipos con Windows Server 2003 desde Windows XP. El complemento Monitor de seguridad IP de MMC actualizado también puede leer características avanzadas creadas en Windows Server 2003 (por ejemplo, información de grupo Diffie-Hellman 2048, asignaciones de certificado y filtros dinámicos), pero no puede editarlas. Para obtener más información, consulte el artículo de Knowledge Base al que se hace referencia. NetshNetsh es una utilidad de secuencias de la línea de comandos que permite mostrar o modificar la configuración de red. Además, puede utilizar Netsh de forma local o remota. Netsh está disponible para Windows 2000, Windows XP y Windows Server 2003. No obstante, la versión de Windows Server 2003 se ha mejorado para proporcionar funcionalidad de diagnóstico y administración IPsec. Los comandos de Netsh para IPsec sólo están disponibles para Windows Server 2003; reemplazan a Ipseccmd en Windows XP y a Netdiag como se utiliza en Windows 2000. IpseccmdIpseccmd es una alternativa de la línea de comandos al complemento Directiva de seguridad IP de MMC. Sólo está disponible para Windows XP, y Service Pack 2 de Windows XP proporciona funcionalidad adicional para esta herramienta. Ipseccmd se debe instalar desde la carpeta de herramientas de soporte técnico del CD de Windows XP. Con SP2 de Windows XP hay disponible una versión actualizada que se debe instalar desde la carpeta de herramientas de soporte técnico del CD del SP2 de Windows XP. La versión anterior a SP2 no funciona en equipos actualizados, y la versión actualizada no funciona en equipos anteriores a SP2. La utilidad Ipseccmd actualizada tiene las siguientes capacidades:
Para obtener más información acerca de la utilidad Ipseccmd actualizada, consulte el artículo 818043 de Microsoft Knowledge Base (mencionado anteriormente). Para mostrar toda la configuración y estadísticas de la directiva IPsec para diagnóstico, utilice la sintaxis siguiente: ipseccmd show all Para mostrar las directivas IPsec asignadas y activas (locales o Active Directory), utilice la sintaxis siguiente. ipseccmd show gpo Nota: este comando sólo funciona con la versión de SP2. Para habilitar el registro de depuración en SP2 de Windows XP, utilice la siguiente sintaxis: ipseccmd set logike (no se requiere el reinicio del servicio IPsec) Para desactivar el registro de depuración, utilice la sintaxis siguiente: ipseccmd set dontlogike (de nuevo, no se requiere el reinicio del servicio IPsec) Nota: sólo puede utilizar Ipseccmd para habilitar el registro de Oakley en SP2 de Windows XP; los comandos anteriores no funcionan en equipos anteriores a SP2. NetdiagNetdiag es una herramienta de diagnóstico de la línea de comandos que se utiliza para probar la conectividad y configuración de la red, incluida la información de IPsec. Netdiag está disponible en Windows 2000, Windows XP y Windows Server 2003, pero su funcionalidad cambia con la versión de sistema operativo. En Windows Server 2003, Netdiag ya no incluye funcionalidad de IPsec; en su lugar, puede utilizar el contexto ipsec de netsh y las pruebas de red básicas también se pueden obtener de Netsh. Para todas las versiones de sistema operativo, es importante asegurarse de que utiliza la última versión; para ello, visite el Centro de descarga de Microsoft. Netdiag debe instalarse desde la carpeta de herramientas de soporte técnico del CD del sistema operativo Windows que se utilice. Nota: Netdiag no se actualiza al instalar SP2 de Windows XP. La importancia de Netdiag para la solución de problemas de IPsec depende de la versión de sistema operativo. Las diferencias de funcionalidad se describen en la tabla siguiente. Tabla 7.1: Funcionalidad IPsec de Netdiag en los distintos sistemas operativos
* Proporciona diagnóstico de red, pero sólo muestra el nombre de la directiva IPsec. Si se utiliza Ipseccmd, hay disponible información de IPsec adicional. ** Proporciona diagnóstico de red, pero no muestra información de IPsec. En su lugar, utilice la siguiente sintaxis: netsh ipsec dynamic show all. Otras herramientas útiles de soporte técnico para IPsecAdemás de las herramientas específicas de IPsec mencionadas anteriormente, en la tabla siguiente se enumeran otras herramientas que pueden resultar útiles para solucionar problemas y se deben incluir en el kit de herramientas de solución de problemas de nivel 2. Tabla 7.2: Otras herramientas útiles para solucionar problemas de IPsec
Uso de las herramientas basadas en ICMP con IPsecLas herramientas Ping, Pathping y Tracert de Windows XP y Windows Server 2003 reconocen IPsec, pero es posible que no funcionen correctamente hasta que no se hayan establecido asociaciones de seguridad por software (si se permite el retroceso a texto no cifrado). Si se han negociado asociaciones de seguridad de IPsec correctamente para encapsular el tráfico ICMP que usan estas utilidades, no podrán detectar saltos intermedios (enrutadores) entre el cliente y el destino. Los cálculos de pérdida de paquetes de Ping pueden mostrar paquetes perdidos durante el tiempo necesario para que IKE negocie correctamente un par de asociaciones de seguridad de IPsec con el destino. No estarán disponibles los cálculos de pérdida de paquetes para cada salto intermedio cuando IPsec encapsule el tráfico ICMP. Estas utilidades ICMP están diseñadas para detectar si el controlador de IPsec ha encontrado una coincidencia de un filtro IPsec con el paquete de solicitud de eco ICMP y, por lo tanto, ha solicitado que IKE negocie la seguridad. Cuando esto sucede, la utilidad muestra el mensaje "Negociar seguridad IP". Un error conocido de Windows 2000 provoca que la utilidad Ping no espere el período de tiempo correcto antes de reintentar la siguiente solicitud de eco, lo que significa que el comando puede terminar inmediatamente en lugar de esperar tres segundos hasta que se establezca la asociación de seguridad por software. La utilidad Ping de Windows XP y Windows Server 2003 espera el número de segundos previsto antes de que se envíe la siguiente solicitud de eco. El mensaje "Negociar seguridad IP" no se mostrará en las situaciones siguientes:
Proceso de solución de problemas de IPsecSi el equipo de soporte técnico de nivel 1 ha identificado claramente el problema, el de nivel 2 podrá encontrar rápidamente el procedimiento de solución adecuado en las secciones siguientes. En este modelo, el equipo de soporte técnico de nivel 1 se ocupa de los problemas de acceso relacionados con el cliente. Se espera que los propietarios administrativos de los servidores puedan efectuar diagnósticos de conectividad de red básicos y puedan pasar por alto el soporte técnico de nivel 1. No obstante, cada organización debe ajustar el modelo a su entorno de soporte técnico. El equipo de soporte técnico de nivel 2 debe centrarse en la identificación del lugar donde se produce el error de comunicación y, a continuación, investigar las posibilidades relacionadas en la arquitectura del sistema. Si su organización utiliza las secuencias de comandos que se proporcionan como parte del proceso de solución de problemas, dispondrá de acceso a una serie de archivos de registro de texto que puede utilizar como ayuda para diagnosticar el problema. En la tabla siguiente se ofrecen las descripciones de los archivos que genera la secuencia de comandos. Tabla 7.3: Archivos creados a partir de la secuencia de comandos IPsec_Debug.vbs
Debido a que hay numerosos puntos de error posibles, en esta sección se trata cada componente de diseño en orden, a partir de la conectividad de red. Se han definido procedimientos para ayudarle a realizar las siguientes tareas:
Tenga en cuenta el siguiente escenario de ejemplo: un cliente informa de que puede utilizar el comando ping con un servidor, pero no puede conectarse a un recurso compartido de archivos en dicho servidor. Se trata del único servidor al que no puede tener acceso el cliente. Un examen rápido del suceso 547 (error de negociación IKE), que contiene la dirección IP del servidor, del registro de seguridad indica que el cliente tiene una directiva IPsec y que IKE se está iniciando. Si el suceso 547 del cliente indica que se ha agotado el tiempo de espera de la negociación IKE del cliente, es posible que se haya producido un error en la negociación por parte del servidor. A continuación, el equipo de soporte técnico de nivel 2 revisa la base de datos de sucesos MOM en busca de sucesos 547 recopilados del servidor especificado, que contendrán la dirección IP del cliente actual. Advertencia: inicio y detención del servidor IPsecEn el documento de solución de problemas de TCP/IP de Windows Server 2003 y en otras referencias se describe cómo determinar si IPsec provoca un problema de conectividad mediante la detención del servicio IPsec. Aunque se detendrá el filtrado IPsec en el equipo, también deshabilitará la protección que ofrece IPsec, expondrá el equipo a un acceso de red que no es de confianza y deshabilitará la protección de paquete. Asimismo, en un entorno de aislamiento de dominio, otros miembros del dominio de aislamiento descartarán el tráfico TCP y UDP que no está protegido por IPsec. Si se deshabilita IPsec en un equipo, se producirán interrupciones de conectividad con dichos equipos remotos que tienen establecidas asociaciones de seguridad IPsec actualmente. Cuando se detiene el servicio IPsec, IKE envía notificaciones de eliminación para todas las asociaciones de seguridad IPsec y para la asociación de seguridad IKE a todos los equipos conectados de forma activa. Los equipos remotos con una directiva IPsec que permita retroceder a texto no cifrado volverán a establecer la conectividad al cabo de un retraso de tres segundos. Los equipos remotos con una directiva IPsec que no permita el retroceso a texto no cifrado no podrán establecer comunicación. Por lo tanto, es importante que utilice las técnicas descritas en las secciones siguientes para solucionar problemas de escenarios de aislamiento sin detener el servicio IPsec. Sólo se deshabilitará el servicio IPsec como último recurso para descartar problemas relacionados con IPsec en las siguientes situaciones:
En Windows 2000, al detener el servicio IPsec se desenlazará el controlador IPsec de TCP/IP y se descargará de la memoria. En Windows XP y Windows Server 2003, al detener el servicio IPsec se eliminarán todos los filtros del controlador IPsec y el modo del mismo se establecerá en PERMITIR. No se descarga el controlador IPsec de la memoria. Para impedir la carga del controlador IPsec, se debe deshabilitar el servicio IPsec y reiniciar el equipo. En Windows 2000 y SP1 de Windows XP, el registro de IKE en el archivo Oakley.log requiere el reinicio del servicio IPsec. No es necesario detener el servicio para habilitar y deshabilitar el registro de IKE en el archivo Oakley.log en SP2 de Windows XP y Windows Server 2003. La última actualización de Ipseccmd para SP2 de Windows XP proporciona la sintaxis Comprobación de la conectividad de redSi el equipo de soporte técnico del nivel 1 identifica posibles problemas de conectividad de red, el primer paso es determinar si existe conectividad de red básica. Esta determinación implica comprobar que se utiliza la configuración IP correcta, que existe una ruta de red válida entre el iniciador y el equipo contestador y que funcionan los servicios de resolución de nombres. Problemas de configuración de dirección IP de redSi la configuración IP dinámica no se realiza correctamente, o si las comunicaciones están bloqueadas después de reiniciar el equipo (o incluso durante el funcionamiento normal), es posible que la causa sea IPsec. En Windows Server 2003, dichos problemas pueden estar relacionados con el comportamiento a prueba de errores de IPsec (por ejemplo, si el equipo se inicia en el modo a prueba de errores o en el modo de recuperación de Active Directory). Nota: para obtener información detallada acerca del comportamiento a prueba de errores de Windows Server 2003, consulte "Understanding IPSec Protection During Computer Startup" en "Deploying IPsec" del Windows Server 2003 Deployment Kit en www.microsoft.com/resources/ Windows Server 2003 recurre al comportamiento a prueba de errores si el servicio IPsec no se puede iniciar correctamente o no se puede aplicar la directiva asignada. La protección a prueba de errores sólo se aplica cuando se asigna una directiva IPsec al equipo y cuando el servicio IPsec no está deshabilitado. Por lo tanto, se puede producir un error en la conectividad a un equipo o desde él durante el funcionamiento normal porque el controlador IPsec no exige la directiva IPsec basada en dominio. Después de determinar el tráfico que está permitido y bloqueado por las configuraciones de modo de inicio y persistentes, un error de comunicaciones se puede explicar fácilmente. Para obtener información alternativa o adicional, puede consultar el estado actual desde la línea de comandos con la sintaxis siguiente: netsh ipsec dynamic show config Para Windows Server 2003, el controlador IPsec se carga durante el inicio del equipo con el controlador TCP/IP. Por lo tanto, para anular el comportamiento a prueba de errores del controlador IPsec, se debe deshabilitar el servicio IPsec y reiniciar el equipo. En el capítulo de implementación IPsec mencionado anteriormente se incluye la configuración recomendada de las exenciones de inicio para dejar exentas las conexiones entrantes de Protocolo de escritorio remoto, lo que garantizará que esté disponible el acceso remoto al servidor cuando esté bloqueado otro tráfico. En una aplicación de aislamiento de servidor y dominio, el tráfico de difusión y el tráfico a los servidores DHCP están exentos para garantizar que la configuración de IP dinámica funciona correctamente. No obstante, la lista de exenciones se debe actualizar manualmente y puede quedar obsoleta. Si un equipo no puede obtener una configuración DHCP correcta (por ejemplo, si utiliza una dirección IP de autoconfiguración 169.254.x.x) o tiene problemas para renovar la concesión, se debe examinar la directiva IPsec para comprobar si están las exenciones correctas. Con el servicio IPsec en ejecución, utilice Ipconfig para confirmar que no existen problemas para obtener una dirección:
Si los problemas de configuración de dirección sólo se producen durante el inicio del equipo para SP2 de Windows XP y Windows Server 2003, se debe inspeccionar la configuración de las exenciones (las predeterminadas y las de inicio). Problemas de resolución de nombresEl diseño de directiva IPsec empleado en los escenarios de aislamiento de servidor y dominio no debe interferir en los procedimientos habituales que se utilizan para determinar si funciona la resolución de nombres. Por ejemplo, en el escenario de Woodgrove Bank, el diseño de la directiva IPsec deja exento todo el tráfico a los servidores DNS y WINS. No obstante, es posible configurar los servidores DNS y WINS para no responder a las solicitudes de Ping. Conteste las siguientes preguntas para confirmar que la resolución de nombres funciona correctamente mientras se ejecuta el servicio IPsec:
Las posibles fuentes de problemas de resolución de nombres son: un archivo HOSTS activo y configurado incorrectamente, una entrada de servidor DNS configurada incorrectamente en las propiedades de IP, anotaciones de registros DNS incorrectas, problemas de actualización de archivos de zona, problemas de replicación de Active Directory, uso de retroceso a texto no cifrado para los servidores DNS y problemas de autoactualización de DHCP. Los posibles motivos de los errores de la resolución de nombres NetBIOS son: un archivo LMHOSTS activo y configurado incorrectamente, una entrada de servidor WINS configurada incorrectamente en las propiedades de IP, falta de disponibilidad de servidores WINS, registro WINS incorrecto, problemas de replicación WINS, errores de servidor proxy WINS y tiempo de espera de red para conectar con el servidor WINS. Para consutar los procedimientos para solucionar problemas de DNS integrado en Active Directory, visite la página Troubleshooting Active Directory - Related DNS Problems de Microsoft.com en www.microsoft.com/technet/prodtechnol/ Algunos entornos de alta seguridad pueden necesitar que los servidores DNS y WINS se protejan con IPsec, lo que puede provocar problemas de resolución de nombres. Por ejemplo, si DNS está integrado en Active Directory y existen filtros duplicados para la misma dirección IP en la directiva IPsec, un filtro puede negociar la seguridad con el servidor DNS y otro puede dejar exentos los controladores de dominio. Para obtener más información, consulte la sección "Solución de problemas de la directiva IPsec", que aparece más adelante en este capítulo. Si continúan los problemas de resolución de nombres, puede obtener la lista de filtros del iniciador y comprobar si existen filtros duplicados. Puede utilizar las siguientes opciones de la línea de comandos para ver las listas de filtros de esta tarea: Ipseccmd show filters Netsh ipsec static show all Si se siguen produciendo los problemas de resolución de nombres, el servicio IPsec se debe detener brevemente (si es posible) mientras se repiten las pruebas de resolución de nombres. Si se producen errores en las pruebas de resolución de nombres únicamente cuando el servicio IPsec está en ejecución, debe proseguir la investigación para determinar la directiva IPsec que se aplica, según se describe más adelante en esta sección. Comprobación de la conectividad y la autenticación con los controladores de dominioDebido a que la entrega de la directiva IPsec, la autenticación IKE y los protocolos de capa superiores dependen del acceso a los controladores de dominio, las pruebas de la conectividad de red y del funcionamiento correcto de los servicios de autenticación se deben llevar a cabo antes que los pasos de solución de problemas específicos de IPsec (descritos en la sección siguiente). En un escenario como Woodgrove Bank, el diseño de la directiva IPsec deja exento todo el tráfico a los controladores de dominio, por lo que las pruebas de conectividad de red a ellos no deberían verse afectadas por IPsec. No obstante, la lista de las direcciones IP de controlador de dominio de la lista de exenciones se debe actualizar manualmente. Si la negociación IKE se lleva a cabo en una dirección IP de controlador de dominio, es posible que la directiva IPsec se haya asignado incorrectamente o no se haya actualizado. Para solucionar problemas de acceso a los servicios de red en Active Directory
Se puede utilizar la herramienta de soporte técnico de Windows klist.exe para comprobar si el inicio de sesión y la autenticación Kerberos se realizan correctamente. Klist se debe ejecutar en el contexto de sistema local para ver los vales Kerberos para el equipo. Para ver los vales del servicio Kerberos para el usuario que ha iniciado sesión en el dominio
Para ver los vales de equipo de dominio
Aunque los vales Kerberos contienen información de grupo para el usuario o el equipo, esta información está cifrada y no se pueden ver los grupos. Por lo tanto, la pertenencia a grupos se debe confirmar manualmente mediante la inspección de la misma en Active Directory. Para garantizar que los equipos disponen de la información de pertenencia a grupos más reciente en sus vales Kerberos, utilice klist para purgar los vales Kerberos actuales. Cuando se vuelva a intentar la negociación IKE, se obtendrán nuevos vales Kerberos automáticamente. Para purgar los vales Kerberos para el equipo (Los pasos 1 a 4 se deben realizar en el contexto de sistema local.)
En las siguientes notas del producto se han publicado procedimientos detallados adicionales para la solución de problemas de Kerberos:
Comprobación de permisos y de la integridad de la directiva IPsec en Active DirectoryPuede que sea necesario comprobar la información acerca del contenedor de la directiva IPsec en Active Directory. El siguiente procedimiento utiliza la herramienta de soporte técnico ldp.exe. Para comprobar la información acerca del contenedor de la directiva IPsec
Para la solución avanzada de problemas de recuperación y daños de directivas, se puede utilizar ldp.exe para inspeccionar manualmente el contenido del contenedor Seguridad IP y la relación entre los objetos de directiva IPsec. Windows 2000, Windows XP y Windows Server 2003 utilizan el mismo esquema de directorio básico para la directiva IPsec que se muestra en el diagrama de la estructura de la directiva IPsec, incluido en la referencia técnica How IPsec Works de www.microsoft.com/resources/documentation/ En la tabla siguiente se muestra la relación entre los nombres de objeto de Active Directory y los nombres de componente de la directiva IPsec que están configurados en el complemento para la administración de directivas IPsec de MMC: Tabla 7.4: Componente de directiva IPsec para la asignación de nombres de Active Directory
Ldp.exe proporciona la capacidad de identificar la última vez que se modificaron los objetos de directiva IPsec, lo que puede ser de ayuda para solucionar problemas de versiones y replicación de objetos. Se puede iniciar desde una ventana de comando en el contexto del sistema local para solucionar problemas de permiso de lectura para el servicio IPsec. Precaución: se recomienda que todos los objetos del contenedor Seguridad IP tengan los mismos permisos. Microsoft no recomienda configurar permisos en objetos de directiva IPsec individuales. Para controlar el acceso de lectura y modificación para la directiva IPsec, los permisos se deben administrar en el mismo contenedor Seguridad IP, según lo explicado en el artículo 329194 de Knowledge Base, "IPSec Policy Permissions in Windows 2000 and Windows Server 2003", en http://support.microsoft.com/?kbid=329194. Una directiva IPsec dañada es el motivo más habitual de las situaciones en que un objeto IPsec contiene una referencia de DN a un objeto que ya no existe. No obstante, se pueden producir daños si se incluyen caracteres de control en el nombre de un objeto, los objetos no se pueden leer debido a problemas de permisos o nombres idénticos de objetos provocan un diseño de directiva IPsec incorrecto (por ejemplo, dos versiones de la misma lista de filtros). Consulte la sección siguiente de solución de problemas, "Servicio IPsec", para obtener información acerca de cómo corregir los datos de la directiva IPsec. Nota: los detalles de diseño de estos objetos se consideran una estructura de datos privada interna y Microsoft no los publica. Existen diferencias en el formato de estos objetos en las distintas versiones de Windows y Microsoft puede realizar cambios en estos formatos en cualquier momento. Por lo tanto, estos objetos sólo se deben administrar mediante el complemento Administración de directiva IPsec de MMC y las herramientas de la línea de comandos que estén disponibles para cada plataforma. Sólo debe eliminar los objetos con LDP como última opción, cuando a consecuencia de los daños no se puedan utilizar el complemento Administración de directiva IPsec de MMC o las herramientas de la línea de comandos. Conectividad de rutas de redMicrosoft recomienda que el protocolo ICMP esté exento en las soluciones de aislamiento de servidor y dominio. Existen varios motivos para esta recomendación, incluida la necesidad de utilizar ICMP para las pruebas de rutas de red con utilidades como Ping, Pathping y Tracert. Por lo tanto, estas utilidades deben funcionar correctamente y no mostrar el mensaje "Negociar seguridad IP". Si se muestra este mensaje, es posible que se haya asignado una directiva IPsec incorrecta. Para determinar si el problema está relacionado con la configuración de red básica o la conectividad de ruta
Las pruebas de conectividad de red se pueden realizar correctamente para ICMP, pero no cuando se utilizan los protocolos IKE o IPsec. En concreto, la carga IPsec para los paquetes de autenticación de modo principal IKE que contienen el vale Kerberos suele ser mayor que la PMTU para la dirección IP de destino, que requiere fragmentación. Por lo tanto, los servidores de seguridad basados en host, filtros en enrutadores, servidores de seguridad de red y filtros en el host de destino deben admitir fragmentación y estar abiertos en los protocolos y puertos siguientes:
No se recomienda el filtrado activo en la ruta de accesoEl filtrado activo puede provocar problemas de conectividad para IKE, AH y ESP porque el estado normalmente se basa en tiempos de espera de actividad. Los dispositivos no pueden inspeccionar el tráfico IKE para determinar cuándo se eliminan las asociaciones de seguridad IPsec porque IKE cifra estos mensajes. Por definición, se requiere que IKE pueda regenerar claves en cualquier dirección, lo que significa que los mensajes de eliminación se pueden enviar en cualquier dirección. Si uno de los lados no recibe un mensaje de eliminación, puede creer que todavía existe un par de asociaciones de seguridad IPsec cuando la otra parte ya no lo reconozca y descarte los paquetes que lo utilizan. La dirección en la que IKE regenerará las claves se basa en la dirección del flujo de tráfico cuya duración en bytes caduque más rápidamente, los desplazamientos menores para la regeneración de claves cuando caduque la duración basada en bytes y la dirección en que fluyen los paquetes después de haberse eliminado las asociaciones de seguridad IPsec inactivas. Normalmente, el filtrado activo basado en host del tráfico IKE en los clientes que inician las conexiones (y, por lo tanto, las negociaciones IKE) a través de Windows Firewall no provoca problemas. Windows Firewall no filtra los paquetes IPsec porque el controlador IPsec procesa los paquetes en una capa inferior a la que se realiza el filtrado del servidor de seguridad. No obstante, los puertos IKE se deben configurar como abiertos en el servidor de seguridad del host para recibir negociaciones IKE entrantes para las conexiones de protocolo de capa superior que se permitan a través del servidor de seguridad (por ejemplo, para compartir archivos mediante el protocolo SMB a través del puerto TCP 445). TCP necesita compatibilidad con ICMP PMTULa configuración predeterminada en Windows 2000 y versiones posteriores es que cada paquete TCP tenga el bit No fragmentar configurado en el encabezado IP. Esta configuración se conserva cuando se utiliza el modo de transporte IPsec AH o ESP para proteger el paquete. Por lo tanto, un paquete que sea demasiado grande se descartará en el enrutador y éste debe devolver un mensaje del tipo ICMP Destination Unreachable que especifica el tamaño máximo permitido. Este comportamiento se denomina detección de MTU de ruta TCP. Tanto el equipo cliente como el de destino deben poder recibir mensajes ICMP PMTU para los paquetes IPsec que son demasiado grandes. Resulta muy importante para el tráfico protegido por IPsec evitar la fragmentación, porque la aceleración por hardware normalmente no procesa los paquetes fragmentados. Los paquetes IPsec fragmentados los debe procesar el controlador IPsec por software. Windows 2000 y Windows XP no admiten el procesamiento de detección de ICMP PMTU para los paquetes de modo de transporte IPsec que utilicen encapsulación transversal (puerto UDP 4500). Windows Server 2003 admite este procesamiento de detección. Vea la página "Troubleshooting Translational Bridging" de la sección "TCP/IP Troubleshooting", incluida en la documentación en línea de Windows Server 2003 en www.microsoft.com/resources/documentation/Windows/ Nota: existe un problema conocido que requiere que se habilite la detección de PMTU de TCP para que IPsec proteja el tráfico en un escenario de NAT Traversal, donde las conexiones UDP-ESP de IPsec se inician desde un host externo a la NAT a un host detrás de una NAT. Si se precisa este escenario, confirme que la detección de PMTU de TCP está habilitada. Para ello, compruebe que la siguiente clave del Registro no está definida ni configurada en 1 en ambos lados: Compatibilidad necesaria para la fragmentaciónLas rutas y los filtros de red deben admitir la transmisión de fragmentos para los protocolos IKE, IPsec, AH y ESP. IKE utiliza paquetes UDP y permite que se fragmenten según sea necesario. La implementación de NAT Traversal de IPsec ha agregado compatibilidad para evitar la fragmentación IKE, sólo cuando IKE autentique con certificados (por ejemplo, en escenarios VPN de L2TP/IPsec). La autenticación IKE que utiliza Kerberos no admite evitar la fragmentación y debe poder enviar y recibir paquetes UDP fragmentados que contengan el vale Kerberos. La ruta de red debe admitir la transmisión de fragmentos para AH y ESP porque IPsec protege todo el paquete IP original antes de la fragmentación de salida en la capa IP. IPsec está integrado con TCP de modo que, cuando los paquetes TCP tienen establecido el indicador DF (no fragmentar), la configuración predeterminada, TCP reducirá su tamaño de paquete para dar cabida a los bytes adicionales que se han agregado mediante la encapsulación IPsec. IPsec no está integrado con UDP, y las aplicaciones UDP no disponen de un método para detectar si IPsec protege su tráfico. Por lo tanto, cuando se aplica IPsec AH o ESP, el host fragmentará los paquetes UDP que utilizan el tamaño de MTU completo durante la transmisión. De forma parecida, si ICMP no está exento en los filtros de directiva IPsec, el uso de la utilidad Ping puede producir paquetes ICMP que parezcan paquetes IPsec AH o ESP fragmentados al transmitirlos. Para obtener más información, consulte el artículo 233256 de Microsoft Knowledge Base, “How to Enable IPSec Traffic Through a Firewall”, en http://support.microsoft.com/?kbid=233256. Compatibilidad necesaria para el tráfico de difusión o multidifusiónEl diseño de la directiva IPsec para el aislamiento de servidor y dominio utiliza filtros de Cualquiera <-> Subred. Por lo tanto, el filtro saliente Subred -> Cualquiera buscará coincidencias del tráfico de difusión y multidifusión saliente enviado desde hosts utilizando una dirección IP de subred interna. No obstante, debido a que IPsec no puede proteger el tráfico de multidifusión o difusión saliente, debe descartar dicho tráfico si coincide con el filtro. La multidifusión entrante y la mayoría de los tipos de difusión no coinciden con el filtro de entrada Cualquiera -> Subred correspondiente. Si se necesita tráfico de multidifusión o difusión, puede configurar la clave del Registro en NoDefaultExempt=1, lo que permite que el tráfico de multidifusión y difusión pase por alto el filtrado IPsec en Windows XP y Windows Server 2003. Esta configuración evita problemas conocidos con clientes RTC (comunicaciones en tiempo real) y Windows Media Server, que utilizan tráfico de multidifusión. Para obtener información detallada acerca del uso y las implicaciones de seguridad de la clave del Registro NoDefaultExempt, consulte los siguientes artículos de Knowledge Base:
La clave del Registro se puede configurar para controlar las exenciones predeterminadas según sea necesario para todas las plataformas. El filtrado IPsec no admite la configuración de las direcciones de destino para direcciones de difusión o multidifusión específicas. Los diagnósticos en los dispositivos de red pueden no ser útilesUna de las consecuencias de utilizar la encapsulación IPsec es que las aplicaciones que suponen que el tráfico TCP/IP está en texto sin cifrar ya no pueden inspeccionar el tráfico dentro de la red. Es muy probable que las herramientas de diagnóstico de red que inspeccionan o proporcionan informes a partir de puertos TCP y UDP no puedan interpretar los paquetes encapsulados por IPsec, aunque no se utilice el cifrado AH o ESP. Es posible que se necesiten actualizaciones de los proveedores para dichas herramientas para inspeccionar los paquetes IPsec AH o ESP nula. Problemas de controlador y tarjeta de interfaz de redEn ocasiones, la pérdida de paquetes IPsec se puede deber a las tarjetas de interfaz de red (NIC) que desempeñan funciones especiales. Se debe probar la compatibilidad con IPsec de las tarjetas que realizan operaciones de clúster o "trabajo en equipo". Los controladores de NIC que aceleran las funciones ajenas a IPsec pueden tener problemas con el tráfico protegido por IPsec. Las tarjetas de interfaz de red que aceleran las funciones TCP pueden ser las que admitan el cálculo y la validación de suma de comprobación de TCP (descarga), así como la capacidad para enviar de forma eficaz un búfer de datos TCP grande (descarga de envío grande). Windows 2000 y versiones posteriores deshabilitan automáticamente estas funciones de descarga de TCP en la pila de TCP/IP cuando el controlador IPsec tiene filtros, aunque IPsec sólo realice las funciones de permisos y bloqueos. Los controladores de tarjeta de red que no están certificados y firmados por el laboratorio de calidad de hardware de Windows (WHQL) pueden provocar problemas cuando se utilice IPsec para proteger el tráfico. WHQL utiliza un exhaustivo conjunto de pruebas para certificar que los controladores de NIC están diseñados para admitir la descarga de IPsec. Como ayuda para la solución de problemas, la pila de TCP/IP de Windows 2000, Windows XP y Windows Server 2003 TCP/IP admite una opción de clave del Registro para deshabilitar todas las formas de descarga de TCP/IP. Algunos controladores de NIC también tienen la capacidad de deshabilitar la descarga mediante las propiedades avanzadas de la conexión de red. Es posible que se tenga que reiniciar el equipo para que surtan efecto los cambios de configuración al nivel de controlador. Solución de problemas de pérdida de paquetes en los protocolos IPsecLos paquetes se pueden descartar o perder, lo que afecta a la conectividad de la aplicación. En esta sección se examinan casos habituales en los que IPsec descarta paquetes. Tal como se ha mencionado anteriormente, es posible que determinados dispositivos de red no permitan el paso de los tipos 50 o 51 de protocolo IP o los puertos UDP 500 o 4500. De forma similar, los paquetes encapsulados por IPsec pueden provocar que algunos paquetes se fragmenten y no pasen por la red. En tales casos, normalmente se necesita un seguimiento de monitor de red desde ambas partes de la comunicación para identificar y correlacionar los paquetes que se están enviando y recibiendo. Busque las retransmisiones indicadas por la aparición repetida del mismo tamaño de paquete. Es posible que sea necesario capturar un seguimiento del comportamiento de protocolo típico sin IPsec y, a continuación, compararlo con el comportamiento de protocolo del tráfico protegido por IPsec. Error de suceso 4285Título de suceso: error de autenticación de hash IKE e IPsec proporcionan protección contra la modificación de paquetes mientras están en tránsito por la red. Si un dispositivo modifica una parte del paquete que está protegido mediante un hash de integridad, el controlador IKE o IPsec receptor descartará este paquete y provocará el error de autenticación de hash, que se guarda en el registro del sistema como el suceso 4285. La experiencia ha demostrado que algunos dispositivos, controladores de red y procesadores de paquetes de terceros en ocasiones dañan los paquetes de un determinado tamaño, con un determinado número de fragmentos, de determinados tipos de protocolo o en situaciones concretas (por ejemplo, cuando el dispositivo está congestionado, supervisa el tráfico o se reinicia). Este error también puede representar un ataque en el paquete por parte de una aplicación malintencionada o de una aplicación que no ha detectado que estaba protegido. Este error también puede ser un indicador de un ataque de denegación de servicio. Para diferenciar los paquetes IPsec descartados de los dañados, se pueden emplear las técnicas siguientes. No obstante, también es importante correlacionar estas observaciones con un seguimiento de monitor de red para poder encontrar el origen de los daños.
Aunque el texto del suceso sugiere que un reinicio del servicio IPsec puede solucionar el problema, el origen de la mayoría de los problemas de pérdida de paquetes no es el sistema IPsec. Reiniciar el servicio no solucionará el problema y puede provocar más. El servicio IPsec sólo se debe detener como último recurso para identificar si un problema está relacionado con IPsec o no lo está. La resolución de este error requiere investigación para identificar un patrón de las direcciones IP de origen, las horas del día, adaptadores o situaciones en las que se produce el error. Si el número de paquetes es pequeño, este error no puede avalar la investigación. Es importante comenzar por intentar excluir orígenes de daños en el sistema local. Deshabilite la descarga de IPsec, intente deshabilitar las características avanzadas o de rendimiento del controlador mediante la configuración que ofrecen las propiedades avanzadas y utilice los controladores de NIC más recientes de los que disponga el proveedor, preferiblemente los certificados y firmados por el laboratorio de calidad de hardware de Windows. A continuación, investigue las características de las rutas de red por las que se transmitiría el paquete. Busque otras pruebas de daños de paquetes en las estadísticas de paquetes TCP/IP descartados y en otros equipos que utilicen la misma configuración. El contador IP de Datagramas recibidos descartados aumentará cada vez que IPsec descarte un paquete. Nota: para deshabilitar la funcionalidad de descarga de TCP/IP, utilice la siguiente clave del Registro para equipos con Windows 2000, Windows XP o Windows Server 2003: Error de suceso 4268Título de suceso: paquetes recibidos con índice de parámetros de seguridad incorrecto (SPI) La implementación de IKE de Windows 2000 y Windows XP (incluido SP1) tiene un problema conocido que provoca la pérdida de paquetes en situaciones concretas. Este problema se ha solucionado en Windows Server 2003 y SP2 de Windows XP. Las consecuencias en las comunicaciones de protocolo de capa superior son prácticamente nulas porque los protocolos ya prevén pérdida de paquetes por otros motivos distintos. Este problema se puede identificar por las siguientes cuestiones:
Aunque el texto del suceso sugiere que un reinicio del servicio IPsec puede solucionar el problema, el origen de este tipo de pérdida de paquetes es parte del diseño del sistema IPsec. Reiniciar el servicio no solucionará el problema y puede provocar más. Tal como se ha indicado anteriormente, el servicio IPsec sólo se debe detener como último recurso para identificar si un problema está relacionado con IPsec o no lo está. Un índice de parámetros de seguridad (SPI) de IPsec es una etiqueta en el paquete que indica al contestador la asociación de seguridad que se debe utilizar para procesar el paquete. Si no se reconoce un SPI, se denomina "SPI dañado". Este error indica que el equipo receptor ha recibido paquetes con formato de IPsec sin disponer de una asociación de seguridad IPsec con la que procesarlos. Por lo tanto, debe descartar los paquetes. Son mensajes de error benignos, aunque los paquetes se descartan. La cantidad de sucesos de SPI dañado que se generen depende de lo ocupados que estén los equipos en ese momento y la velocidad a la que estén transmitiendo los datos protegidos por IPsec en el momento de la regeneración de claves. Es probable que las siguientes situaciones generen más sucesos de este tipo:
La consecuencia es que una conexión TCP protegida por IPsec se ralentizará durante unos segundos para retransmitir los datos perdidos. Si se pierden varios paquetes, es posible que TCP pase al modo de prevención de congestión para dicha conexión. En pocos segundos la conexión se debe reanudar a velocidad completa. La copia de archivos, Telnet, Terminal Server y otras aplicaciones basadas en TCP no deberían advertir la pérdida de estos pocos paquetes. No obstante, ha habido algunos casos en los que TCP pierde una ráfaga de paquetes en un vínculo rápido y debe restablecer la conexión. Cuando se restablece la conexión, el socket se cierra y se notifica a las aplicaciones de una interrupción de la conexión, lo que puede interrumpir las transferencias de archivos. La causa más habitual de este error es un problema conocido de Windows 2000 en el que interviene el modo en que IKE sincroniza la generación de claves de asociaciones de seguridad IPsec. Cuando un iniciador de modo rápido IKE es más rápido que el contestador, el primero puede enviar nuevos paquetes protegidos por asociación de seguridad IPsec antes de que el contestador esté preparado para recibirlos. Según lo especificado en las solicitudes de comentario (RFC) de IPsec del grupo Internet Engineering Task Force (IETF), cuando IKE establece un par nuevo de asociaciones de seguridad IPsec, el iniciador debe utilizar la nueva asociación de seguridad IPsec saliente para transmitir datos, y el contestador más lento recibe el tráfico protegido por IPsec que todavía no reconoce. Debido a que la regeneración de claves IKE depende del tiempo transcurrido y de la cantidad de datos enviados bajo la protección de una asociación de seguridad IPsec, se pueden producir sucesos de SPI dañados periódicamente (aunque no necesariamente a intervalos específicos). En escenarios de interoperabilidad de clientes de terceros, un error de SPI dañado puede indicar que un principal IPsec no ha aceptado y procesado un mensaje de eliminación o ha tenido problemas en realizar el último paso de la negociación de modo rápido IKE. El error también puede indicar que un atacante está inundando un equipo con paquetes IPsec suplantados o insertados. El controlador IPsec cuenta estos sucesos y los guarda para realizar un registro de la actividad de SPI dañados. Se puede utilizar la clave del Registro LogInterval para investigar y minimizar estos sucesos. Cuando solucione problemas, configúrela en el valor mínimo (cada 60 segundos) para que los sucesos se registren rápidamente. En Windows 2000, puede detener y reiniciar el servicio del Agente de directivas IPsec para recargar el controlador IPsec. En Windows XP y Windows Server 2003, se debe reiniciar el equipo para recargar los controladores TCP/IP e IPsec. En Windows 2000, estos sucesos no se pueden eliminar mediante valores de clave del registro o revisiones actuales. La configuración predeterminada en Windows XP y Windows Server 2003 es no informar de estos sucesos. Se puede habilitar el informe de estos sucesos con la configuración IPsecDiagnostics mediante la opción de la línea de comandos ipsec de netsh o mediante la clave del Registro directamente. Las técnicas siguientes pueden minimizar estos errores:
Si estas opciones no funcionan y no es posible la actualización a SP2 de Windows XP o Windows Server 2003, póngase en contacto con el servicio de soporte técnico de Microsoft para consultar si existen otras opciones disponibles actualmente. Error de suceso 4284Título de suceso: paquetes en texto sin cifrar que se deben proteger Este suceso indica que se ha establecido una asociación de seguridad IPsec en el momento de recibir los paquetes en texto sin cifrar que deberían haber estado dentro de la asociación de seguridad IPsec. Estos paquetes se descartan para evitar ataques de inserción de paquetes en las conexiones protegidas por IPsec. Aunque se incrementará el contador IP de Datagramas recibidos descartados, IPsec no dispone de un contador de valor que registre los paquetes descartados por este motivo. Este problema sólo se puede identificar en el suceso de error 4284 del registro del sistema, que indica lo siguiente: "Se han recibido <número> paquetes vacíos de <dirección IP> cuya seguridad debía haberse establecido. Puede tratarse de un problema temporal; si persiste, detenga y reinicie el servicio del Agente de directivas IPsec en este equipo." Al igual que con los errores anteriores, no se debe seguir la sugerencia del suceso. Es poco probable que reiniciar el servicio IPsec corrija el error. La causa más probable del error es que haya un problema de configuración de directiva que provoca que un lado envíe tráfico en texto sin cifrar debido a un filtro de permiso saliente más específico. Por ejemplo, si un cliente tiene un filtro para proteger todo el tráfico con un servidor y la directiva del servidor tiene un filtro más específico para permitir respuestas HTTP en texto sin cifrar, el servidor protegerá todo el tráfico al cliente excepto los paquetes HTTP salientes. El cliente recibe estos paquetes y los descarta por motivos de seguridad, debido a que espera que todo el tráfico al servidor y desde él esté protegido en el par de asociaciones de seguridad IPsec. Este suceso también puede producirse durante las operaciones normales y durante los casos de interoperabilidad de cliente de terceros en los que un principal elimina una asociación de seguridad IPsec o un filtro del controlador IPsec mientras el tráfico fluye entre los equipos. Por ejemplo, un lado puede anular la asignación de la directiva IPsec o puede tener una actualización de directiva que elimine asociaciones de seguridad y filtros IPsec. Debido a que un equipo ya ha eliminado el filtro mientras se estaba realizando una comunicación de protocolo de nivel superior activo, es posible que el mensaje de eliminación IKE no llegue y se procese por el otro equipo antes de que lleguen los paquetes de texto sin cifrar, lo que provoca el error. Además, el período de tiempo que se tarda en procesar el mensaje de eliminación depende de la carga actual en el otro equipo. El mensaje de error también se puede producir mientras se carga una directiva grande, debido a que las asociaciones de seguridad IPsec pueden haberse establecido antes de la aplicación del conjunto de filtros completo al controlador IPsec. Si se produce esta situación, es posible que las asociaciones de seguridad IPsec se hayan negociado para tráfico que estará exento una vez terminada la carga de la directiva. El mensaje de error también puede ser una indicación de un ataque de inserción donde se envía tráfico en texto sin cifrar que coincide (deliberada o casualmente) con los selectores de tráfico de una determinada asociación de seguridad entrante activa. Este problema debe transferirse al diseñador de la directiva IPsec. Tiempos de espera de IPsec NAT-T al conectar sobre redes inalámbricasSe ha encontrado un problema reciente que provoca que se agote el tiempo de espera de las conexiones cuando los equipos cliente basados en Windows Server 2003 o Windows XP intentan conectarse un servidor en una red inalámbrica que utiliza IPsec NAT-T. Para obtener más información, consulte el artículo 885267 de Microsoft Knowledge Base en http://support.microsoft.com/?kbid=885267. Comprobación de la directiva IPsec correctaEn esta sección se describen los pasos para detectar los problemas con la asignación y la interpretación de directivas IPsec. Los filtros de una directiva IPsec interpretada correctamente deben estar en el controlador IPsec para que IPsec permita y bloquee paquetes, así como para activar IKE de modo que negocie asociaciones de seguridad IPsec con direcciones IP remotas para proteger el tráfico. También deben existir los filtros apropiados para guiar a IKE como contestador. En esta solución, el diseño de directiva IPsec requiere que todo el tráfico (excepto ICMP) esté protegido por IPsec. La directiva también contiene filtros por cada dirección IP de la lista de exenciones. Nota: en Windows 2000, el servicio IPsec se denomina Agente de directivas IPsec; en Windows XP y Windows Server 2003 este servicio se denomina Servicio IPsec. Los ingenieros de soporte técnico deben estar familiarizados con el uso de Directiva de grupo por parte de IPsec, prioridad de directiva IPsec e interpretación de directiva IPsec. En la sección "Información adicional", al final de este capítulo, se pueden encontrar referencias a información acerca de estos temas. Solución de problemas de Directiva de grupo para IPsecDirectiva de grupo proporciona el mecanismo para asignar una directiva IPsec basada en dominio a un miembro de dominio. La recuperación de los GPO asignados por el miembro de dominio es lo que entrega la asignación de directiva IPsec a un equipo host. Por lo tanto, los problemas de recuperación de GPO provocarán que los equipos no apliquen la directiva IPsec correcta. Los problemas habituales de Directiva de grupo para la administración de directivas IPsec son los siguientes:
Pueden producirse retrasos en la replicación debido a la cantidad de objetos relacionados con IPsec en Active Directory, como directivas IPsec, GPO, cambios de atributos en las asignaciones de directivas IPsec de GPO y en la directiva IPsec e información de pertenencia a grupos de seguridad. Debe llevarse a cabo una planificación cuidadosa para evaluar las consecuencias de un cambio de configuración IPsec según afecte gradualmente a los miembros del dominio. Consulte los procedimientos para solucionar problemas de Directiva de grupo en las siguientes notas del producto:
La asignación de directivas IPsec basada en dominio está implementada mediante dos componentes:
El complemento Administración de directivas IPsec de MMC asigna la directiva a un GPO almacenando la información de la directiva IPsec seleccionada en el componente IPsec del GPO, al que se hace referencia como el nombre distintivo (DN) LDAP: CN=IPSEC,CN=Windows,CN=Microsoft,CN=Machine,CN={GPOGUID}, El DN LDAP de la directiva IPsec asignada se almacena en el atributo ipsecOwnersReference de GPO. Cuando Directiva de grupo recupera la lista de los GPO que se aplican al equipo, los que contienen asignaciones de directiva IPsec se almacenan en el Registro con el GUID de la extensión de lado del cliente de IPsec en la ubicación siguiente: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft La extensión de lado del cliente de IPsec se activa mediante la extensión de lado del cliente de la directiva de seguridad siempre que existe una asignación de directiva IPsec en un GPO. Si se producen problemas al procesar la directiva de seguridad, también puede haberlos al procesar la directiva IPsec. Para encontrar el GUID de cada extensión de Directiva de grupo, busque en la siguiente ubicación del Registro: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft Los GUID relacionados con la implementación de IPsec para las extensiones de lado del cliente de Directiva de grupo son los siguientes:
La extensión de lado del cliente de IPsec copia el DN LDAP y la información relacionada acerca de la directiva IPsec asignada en la siguiente clave del Registro: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ Si varios GPO contienen asignaciones de directiva IPsec, se llama a la extensión de lado del cliente de IPsec por cada GPO. Las reglas de prioridad de GPO se aplican en el orden en que la extensión de lado del cliente recibe los GPO para procesarlos. El orden también se puede ver afectado por la configuración de los propios GPO y por las listas ACL de lectura que impiden que se recuperen algunos GPO asignados. Cada vez que se llama a la extensión de lado del cliente de IPsec, se sobrescribe la información relacionada con IPsec del GPO (incluido el DN) en esta clave del Registro. Cuando se han procesado todos los GPO, la extensión de lado del cliente indica al servicio IPsec que se ha asignado una directiva IPsec basada en dominio. A continuación, el servicio IPsec lee el valor GPTIPsecPolicy\DSIPSECPolicyPath para recuperar la directiva IPsec correcta. El servicio IPsec continúa el sondeo para detectar cambios en la directiva IPsec asignada basándose en la hora de la última actualización de cualquier objeto de directorio de directiva IPsec asignado. El servicio conserva la directiva IPsec en caché como la directiva de dominio más reciente. Existe un problema conocido que permite que el nombre de la directiva IPsec asignada deje de estar sincronizado con el nombre de la directiva IPsec que se utiliza realmente (y que está en caché). El servicio IPsec no actualiza la información de la clave del Registro GPTIPsecPolicy, como DSIPSECPolicyName, y el nombre de la directiva IPsec sólo cambia cuando se llama a la extensión del lado de cliente de IPsec. No obstante, no se llama a la extensión de lado del cliente de IPsec a menos que haya cambiado el atributo DN de la asignación de directiva IPsec en el GPO. El complemento Monitor IPsec de MMC y las herramientas de la línea de comandos utilizan este valor del Registro para informar del nombre de la directiva IPsec asignada actualmente. Por lo tanto, las herramientas IPsec pueden informar del último nombre de directiva IPsec que ha procesado la extensión de lado de cliente, no del que está en uso en estos momentos. Existen varias soluciones para este error; para obtener más información, consulte la sección "Control de versiones de directiva" del capítulo 5, "Creación de directivas IPsec para grupos de aislamiento", en esta guía. Nota: Microsoft recomienda que las convenciones de nomenclatura de directivas IPsec incluyan un número de versión en el nombre para poder encontrar fácilmente la versión aplicada actualmente de la directiva. Si el nombre de directiva es el mismo, no es posible detectar fácilmente cambios de versión. Si no se asigna la directiva IPsec correcta, incluso después de una actualización forzada de Directiva de grupo, los errores del registro de aplicación de los orígenes Userenv o SceCli indicarán problemas de procesamiento de Directiva de grupo. Se debe habilitar el registro de Directiva de grupo para investigar este problema con más detalle. Existen muchos tipos distintos de registros y niveles de registro de Directiva de grupo. En los registros de la extensión de lado del cliente de seguridad se tienen que buscar errores de procesamiento de la directiva de seguridad, así como los errores de los que ha informado la extensión de lado del cliente de IPsec. No existe un registro específico para la extensión de lado del cliente de IPsec. Los seguimientos de monitor de red pueden ser necesarios para capturar el tráfico en el momento de la actualización de Directiva de grupo para confirmar la dirección IP de controlador de dominio que se está utilizando en la recuperación de cada objeto. Entre los problemas se pueden incluir:
Para crear un archivo de registro detallado de la extensión de lado del cliente de seguridad, utilice la siguiente clave del Registro: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft Establezca la entrada ExtensionDebugLevel en un valor REG_DWORD de 0x2. El archivo de registro se creará en %windir%\Security\Logs\Winlogon.log. Nota: una entrada DNS no válida puede significar que las directivas de grupo no se descargan de Active Directory, aunque el inicio de sesión de equipo y usuario sean correctos. Para obtener más información acerca de los problemas de DNS, consulte la sección "Problemas de resolución de nombres" anterior. Solución de problemas del servicio IPsecNo es necesario que el servicio IPsec esté en ejecución para utilizar el complemento Administración de directivas IPsec de MMC. No obstante, si un administrador asigna posteriormente una directiva local, en la columna Directiva asignada se mostrará un error. Los siguientes problemas habituales pueden provocar que se produzca un error del servicio IPsec durante el inicio:
La implementación IPsec de Windows 2000 utiliza un módulo denominado almacén de directivas IPsec (polstore.dll), por lo que el Agente de directivas IPsec y el complemento Administración de directivas IPsec de MMC pueden utilizar un módulo para tener acceso a las tres ubicaciones de almacenamiento de directivas admitidas: local, equipo remoto y Active Directory. Este diseño se ha cambiado y mejorado en Windows XP y Windows Server 2003 con la incorporación de nuevos tipos de directiva IPsec (directiva de inicio y directiva persistente) y el componente SPD (base de datos de directivas de seguridad), que mantiene el estado en tiempo de ejecución de la directiva IPsec para las consultas del monitor IPsec y de IKE. Este cambio de diseño implica que el texto de los sucesos IPsec registrados en Windows 2000 ha cambiado en Windows XP y Windows Server 2003. Este cambio de diseño también implica que se han tenido que efectuar cambios importantes en las interfaces RPC que se utilizan para la administración remota. Para Windows Server 2003, las interfaces RPC se han vuelto a actualizar considerablemente. Por lo tanto, el complemento Administración de directivas IPsec de MMC no puede conectarse a los equipos remotos que no tienen instalada la misma versión de sistema operativo. Además, el modelo de seguridad para SP2 de Windows XP y SP1 de Windows Server 2003 han cambiado fundamentalmente para limitar las conexiones RPC remotas y para activar Windows Firewall de forma predeterminada. Para obtener más información, consulte Changes to Functionality in Microsoft Windows XP Service Pack 2 - Part 2: Network Protection Technologies en www.microsoft.com/technet/prodtechnol/winxppro/ Debido a estos cambios, las interfaces RPC remotas del servicio IPsec se han deshabilitado como medida de seguridad. Por lo tanto, los complementos Monitor IPsec y Administración de directivas IPsec de MMC no pueden realizar la supervisión remota en estos equipos. La administración remota de IPsec se debe realizar con conexiones de Escritorio remoto (Terminal Server), que ejecuta los complementos IPsec de MMC como procesos locales. En Windows 2000, el controlador IPsec se carga de forma predeterminada al final del proceso de inicio por parte del servicio del Agente de directivas. El controlador IPsec no forma parte del procesamiento de paquetes IP hasta que el Agente de directivas informa por primera vez de una directiva activa a dicho controlador. Si no existe una directiva IPsec activa, el controlador IPsec no se incluye en el procesamiento del tráfico IP entrante y saliente. En Windows XP y Windows Server 2003, este diseño se ha mejorado de modo que el controlador TCP/IP carga el controlador IPsec durante el proceso de inicio. El controlador no procesa los paquetes hasta que tiene filtros cargados por el servicio IPsec. En Windows 2000, el Agente de directivas IPsec puede registrar errores para los problemas con el inicio del servicio. Entre estos errores se incluyen los siguientes:
En Windows XP y Windows Server 2003, los siguientes sucesos de error de servicio IPsec indican que el servicio no se puede iniciar:
Solución de los problemas de recuperación de la directiva IPsecEl servicio IPsec utiliza una consulta TCP LDAP autenticada y cifrada para descargar la directiva IPsec asignada para todas las plataformas. Existen opciones para la firma y el sellado LDAP mediante la clave de sesión de Kerberos. Por lo tanto, el servicio IPsec que se ejecute como sistema local debe poder obtener un vale de servicio Kerberos para el servicio LDAP en el servidor Active Directory. Si se confirma que la extensión de lado del cliente de IPsec ha almacenado la directiva IPsec correcta asignada en la clave del Registro GPTIPsecPolicy y el servicio está en ejecución, los siguientes problemas pueden provocar que el servicio IPsec no pueda recuperar la directiva desde Active Directory:
En el complemento Administración de directivas IPsec de MMC se produce un problema conocido cuando se administra la directiva IPsec en Active Directory o en un equipo remoto. Si el complemento MMC se ejecuta en un vínculo lento, es posible que tarde en guardar todos los cambios en una directiva grande. Si se cierra la ventana del complemento MMC, se perderá cualquier objeto o cambio de directiva que no se haya guardado. Esta funcionalidad puede provocar que se dañe una directiva IPsec. Si el complemento Administración de directivas IPsec de MMC se ejecuta en un vínculo lento, utilice una sesión de Escritorio remoto para ejecutar el complemento como un proceso local. Por lo general, se debe probar cualquier secuencia de comandos de herramienta de la línea de comandos que cree la directiva IPsec. Para ello, cree la directiva en el almacén local y examínela con el complemento Administración de directivas IPsec de MMC para comprobar su integridad. Los equipos de prueba también deben aplicar la directiva IPsec local y examinar los detalles en el complemento Monitor IPsec de MMC para confirmar el orden de filtros previsto. Los procedimientos para solucionar y corregir errores de lectura y daños de la directiva IPsec dependen de la ubicación de almacenamiento. Esta solución utiliza únicamente la directiva IPsec basada en dominio, pero otros tipos de directiva IPsec se pueden haber configurado de un modo que provoquen problemas. En el resto de esta sección se revisan los procedimientos de solución de problemas de cada tipo de directiva. Por lo general, el departamento de soporte técnico de nivel 2 debe poder utilizar las herramientas de la línea de comandos o de la interfaz gráfica de usuario para confirmar que se está recuperando la directiva IPsec correcta y que se está interpretando de forma adecuada. Se muestran los pasos para eliminar cada tipo de directiva con la expectativa de que una actualización de directivas instale una directiva correcta. Si no se recupera o instala una directiva correcta de las secuencias de comandos, el problema se transfiere al departamento de soporte técnico de nivel 3. Directiva IPsec de inicioLa utilidad Netsh permite la configuración del modo de inicio de las opciones de exención de inicio admitidas únicamente por Windows Server 2003. La configuración se almacena en las siguientes claves del Registro con los valores predeterminados que se indican:
El valor OperationMode predeterminado requiere que el controlador IPsec realice un filtrado activo del tráfico saliente. Si el servicio IPsec está en ejecución, utilice el comando Para solucionar los problemas de tráfico que pueden producirse por el filtrado activo de IPsec durante el inicio, configure el controlador IPsec para permitir el tráfico al inicio en lugar de efectuar un filtrado activo. Si el servicio IPsec está en ejecución, utilice Directiva IPsec persistenteWindows XP y Windows Server 2003 admiten directivas persistentes. Una situación de error habitual se produce cuando no se elimina una directiva persistente existente antes de definir una nueva y ésta entra en conflicto con la configuración que ya está asignada. La solución descrita en esta guía no utiliza directivas persistentes. No obstante, puede utilizarse en algunos entornos, por lo que en este capítulo se proporcionan instrucciones de solución de problemas. La clave del Registro para directivas persistentes existe de forma predeterminada y está vacía: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ En Windows XP, la mejor forma de detectar una directiva persistente es comprobar que esta clave del Registro no está vacía. El comando ipseccmd show informa de la directiva activa que se encuentra en el servicio IPsec pero no informa de una determinada configuración procedente de una directiva persistente. El servicio IPsec descarta los nombres de las reglas de directiva persistente al interpretar la directiva en la configuración actual. Debido a que ipseccmd no proporciona nombres para filtros y acciones de filtrado, no se pueden utilizar las convenciones de nomenclatura para indicar filtros y acciones de filtrado que proceden de una directiva persistente. Los filtros que tengan nombres del tipo "text2pol{GUID}", tanto si se han creado con ipsecpol.exe como con ipseccmd.exe, incluirán entradas procedentes de una directiva persistente. No obstante, las directivas locales o de dominio que se han creado con las secuencias de comandos también tendrán estos nombres. La directiva persistente se aplica en primer lugar y se combina con la directiva IPsec local o de dominio. Por lo tanto, se tiene que anular la aplicación de la directiva local y de dominio para poder ver sólo la configuración persistente. utilice ipseccmd show all para mostrar todas las directivas activas, incluida la configuración persistente, cuando se inicie el servicio IPsec. Para eliminar todos los objetos (reglas, listas de filtros y acciones de filtrado) que están asociados a una determinada directiva persistente, especifique el nombre de ésta en el comando siguiente: ipseccmd.exe -w PERS -p "policy name" –o La forma más sencilla de asegurarse de que se elimina toda la directiva persistente consiste en eliminar todas las subclaves debajo de la clave Persistent. No obstante, si elimina la clave Persistent, se producirá un error en los comandos ipseccmd futuros al intentar crear una directiva persistente. Para solucionar los daños en una directiva persistente y los conflictos de directivas, elimine todos los objetos del almacén de directivas persistentes y vuelva a ejecutar la secuencia de comandos ipseccmd para crearla. En Windows Server 2003, la directiva persistente tiene capacidades de administración completas que son similares a las de la directiva IPsec local y de dominio. La directiva persistente se almacena en la misma ubicación del Registro mencionada anteriormente. La siguiente secuencia de comandos del comando Netsh mostrará la directiva persistente configurada mediante los comandos del archivo show_persistent.netsh: Netsh –f show_persistent.netsh El archivo show_persistent.netsh es un archivo de texto que contiene las siguientes líneas: Pushd ipsec static Set store persistent show all exit Se puede utilizar la siguiente secuencia de comandos del comando Netsh para eliminar toda la directiva persistente: pushd ipsec static set store persistent delete all exit Directiva IPsec localLa directiva IPsec local se admite en Windows 2000, Windows XP y Windows Server 2003 y se almacena en la siguiente clave del Registro: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ Si se asigna una directiva local, ésta se almacenará en la clave del siguiente modo: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ Si no está asignada una directiva de dominio, la directiva local asignada se agregará a cualquier directiva persistente configurada para convertirse en la directiva activa. Para facilitar considerablemente la solución de problemas, las directivas IPsec que crean las secuencias de comandos ipsecpol o ipseccmd se deben editar con el complemento Administración de directivas IPsec de MMC para definir nombres de filtro para cada filtro antes de utilizarlas en entornos de producción. También se puede utilizar el comando netsh ipsec para crear la directiva en un equipo con Windows Server 2003 y, a continuación, exportarla a un archivo que se puede importar en equipos con Windows 2000 y Windows XP o en un dominio después de haberla probado. En Windows 2000, utilice el comando netdiag /test:ipsec /debug para ver los detalles de asignación y de directiva activa. Se debe utilizar el complemento Administración de directivas IPsec de MMC o las herramientas del Registro para eliminar objetos de directiva IPsec del almacén local. Para forzar una recarga de la directiva IPsec asignada, detenga y reinicie el servicio. En Windows XP, utilice los comandos ipseccmd show gpo o netdiag /test:ipsec para ver los detalles de asignación y directiva activa. Utilice el complemento Administración de directivas IPsec de MMC, las herramientas del Registro o el comando Para forzar que el servicio IPsec vuelva a cargar la directiva, detenga y reinicie el servicio IPsec o anule la asignación de la directiva IPsec y vuelva a asignarla mediante el complemento Administración de directivas IPsec de MMC. También es posible utilizar el comando sc policyagent control 130 para volver a cargar la directiva. Cuando la directiva se vuelve a cargar, se eliminan todas las asociaciones de seguridad IPsec e IKE, lo que puede provocar retrasos de conectividad o interrupciones con los equipos que estaban utilizando activamente asociaciones de seguridad IPsec para transmitir y recibir tráfico. En Windows Server 2003, utilice el comando Utilice el comando netsh ipsec dynamic show all para ver la configuración de directiva activa actual. También puede utilizar Monitor IPsec para inspeccionar distintas partes de la directiva activa. Para eliminar y volver a cargar la directiva local en Windows Server 2003, utilice los mismos comandos que los enumerados para Windows XP. El elemento netsh ipsec se puede utilizar para cancelar la asignación, volver a asignar y eliminar la directiva. Directiva IPsec de Active DirectoryEsta directiva es compatible con Windows 2000, Windows XP y Windows Server 2003. La directiva IPsec de dominio asignada se almacena en el Registro local en la siguiente ubicación: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ La caché del Registro local de la directiva de dominio se almacena en: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ El almacén del directorio se debe administrar mediante el complemento Administración de directivas IPsec de MMC o el comando netsh ipsec ejecutándose como procesos locales en Active Directory. No hay disponibles herramientas que permitan ver directamente el contenido de la caché. Se debe utilizar una herramienta del Registro para determinar si existe la caché y si incluye el contenido adecuado. De forma similar, se utilizan herramientas del Registro para eliminar la directiva de dominio mediante la eliminación de las claves del Registro GPTIPsecPolicy y Cache. Se debe reiniciar el servicio IPsec o se debe utilizar el comando de control de servicio para forzar que se vuelva a cargar la directiva IPsec sin la directiva de dominio. Para actualizar la asignación de directiva IPsec basada en dominio y volver a cargar la directiva IPsec y actualizar el contenido de la caché, utilice gpudpate /force. Para impedir temporalmente que la directiva de dominio se aplique en el equipo local, puede configurar los permisos en las claves del Registro GPTIPsecPolicy y Cache para denegar el acceso de lectura a la cuenta de sistema local. El complemento Monitor de seguridad IPsec de MMC y las herramientas de la línea de comandos mostrarán la directiva de dominio como asignada porque leen la información de GPTIPsecPolicy que se ejecuta en el contexto del usuario administrador local. Para un bloqueo más duradero de la directiva IPsec basada en dominio, se debe impedir que el equipo lea el GPO adecuado en Active Directory. En Windows 2000, pueden aparecer los siguientes errores cuando hay problemas con la directiva:
En Windows XP y Windows Server 2003, los siguientes sucesos indican que el servicio IPsec no pudo recuperar un determinado tipo de directiva. Si una directiva local no se puede leer correctamente en Windows Server 2003 y SP2 de Windows XP, la directiva se omite y se lee la siguiente directiva asignada en el orden de persistencia.
Solución de los problemas de interpretación de la directiva IPsecLa interpretación de la directiva IPsec se realiza después de haber recuperado correctamente la directiva de la ubicación de almacenamiento adecuada. Las direcciones IP de la interfaz de red actual se utilizan para expandir los filtros genéricos de la directiva en filtros específicos. A continuación, la lista de los filtros específicos de entrada y salida se carga en el controlador IPsec para el procesamiento de paquetes. Los sucesos de cambio de interfaz se señalizan al servicio IPsec, que ajusta la configuración del filtro IPsec en el controlador IPsec tan rápido como sea posible, si es necesario (por ejemplo, para filtros de Mi dirección IP). En Windows 2000, los mensajes siguientes pueden indicar un problema con la interpretación o configuración correcta de los componentes IPsec para aplicar la directiva:
En Windows Server 2003, los sucesos siguientes indican que se puede haber producido un problema al interpretar la directiva IPsec. En la mayoría de los casos, Windows XP utiliza el mismo texto de suceso. Se deben resolver estos problemas para que la directiva IPsec funcione correctamente.
Problemas de configuración de directiva con VPN de RRASTal como se ha indicado en la sección de soporte técnico de nivel 1 anteriormente en este capítulo, el servicio RRAS es una fuente habitual de conflictos en la directiva IPsec en algunas organizaciones. En esta sección se explica el motivo por el que la directiva IPsec integrada para los servidores VPN de L2TP/IPsec crea conflictos con la directiva de dominio empleada en esta solución. Esta situación constituye un ejemplo de un problema de filtro duplicado. En la siguiente explicación, el diseño de directiva IPsec empleado en el escenario de Woodgrove Bank se utiliza para ilustrar los problemas. Sin embargo, los principios se aplican a numerosas implementaciones IPsec en toda la organización. El servicio Administrador RAS (RASMAN) genera automáticamente la directiva IPsec para los servidores L2TP/IPsec e incluye los siguientes filtros:
Por lo tanto, el filtro específico de modo principal que controla la respuesta de la negociación IKE a este servidor es la parte de dirección del filtro de entrada:
Observe que el uso de "Mi dirección IP" provoca que el filtro de entrada se expanda por cada dirección IP del servidor VPN. Si se supone que el servidor VPN tiene una dirección IP de interfaz externa para la conectividad de Internet y una interfaz interna para la conectividad de LAN, los filtros de entrada específicos del modo principal IKE son:
El segundo filtro, para la interfaz de LAN interna, es más específico que el filtro de entrada del modo principal IKE de aislamiento de servidor y dominio, que es:
Por lo tanto, cuando un administrador utiliza un cliente de confianza para administrar el servidor VPN, inicia IKE en la dirección IP interna del servidor VPN. La búsqueda de directiva de entrada IKE coincidirá con el filtro de modo principal más específica y responderá con la configuración de modo principal IKE para L2TP. Se utilizará la autenticación de certificados en vez de la autenticación Kerberos, que es la empleada para esta solución. Un segundo caso de conflicto se puede producir si el cliente VPN de Internet utiliza las capacidades de cuarentena del cliente de Administrador de conexiones. El cliente de cuarentena debe pasar una "clave de cuarentena" a la dirección IP de la LAN interna del servidor VPN al final de la cuarentena y obtener acceso VPN completo a la red. En este escenario, se aplica la directiva IPsec de dominio del cliente VPN de la caché cuando se inicia el equipo portátil. Cuando la conexión de cuarentena VPN se establece correctamente, se asigna una dirección IP interna al cliente VPN. La dirección IP interna de cliente puede estar cubierta por uno de los filtros de subred (Cualquiera <-> Subred interna) definidos en la directiva IPsec de aislamiento de dominio. Este filtro es necesario para que los clientes dispongan de acceso autenticado por IPsec completo a través del túnel VPN a los servidores internos y cualquier otra estación de trabajo que pueda tener acceso. No obstante, los filtros de subred de esta solución iniciarán una negociación IKE desde la dirección IP interna de la interfaz virtual de túnel VPN de cliente a la interfaz de LAN interna del servidor VPN. Se producirá un error en el modo principal IKE porque el servidor responderá para aceptar únicamente autenticación de certificados, lo que no es compatible con la directiva empleada para el aislamiento de dominio y servidor. Aunque la directiva permitiera autenticación de certificados, el modo rápido IKE del cliente propondría el filtro para todo el tráfico y el servidor VPN no podría realizar la negociación porque el filtro propuesto es demasiado general. El servidor VPN sólo aceptará filtros de modo rápido que sean específicos de L2TP: UDP origen 1701, destino Cualquiera o UDP origen 1701, destino 1701. Se pueden utilizar las siguientes opciones para resolver el conflicto entre la directiva L2TP/IPsec de servidor RRAS y la directiva de aislamiento:
La solución más simple de esta lista es la primera, que hace que la NIC interna del servidor RRAS esté exenta de utilizar IPsec. Solución de problemas de IKENormalmente se producen errores en IKE e IPsec cuando se implementan por primera vez porque el filtrado de red no permite el puerto UDP 500 o los paquetes de protocolo IPsec. Por este motivo, resulta útil establecer una estación de trabajo o servidor con una dirección IP estática para pruebas que tendrá asignada una directiva simple, como la directiva Servidor (solicitud) de ejemplo predefinida que utiliza una clave previamente compartida. Se debe habilitar la auditoría para capturar los sucesos de auditoría de IKE. Se implementa una directiva IPsec de dominio predeterminada para todos los miembros de dominio que autentica con la misma clave previamente compartida y contiene una regla con un filtro para todo el tráfico (incluido ICMP) a la dirección IP del equipo de prueba. A continuación se implementa una secuencia de comandos de inicio de sesión de dominio para utilizar el comando ping <testserver> o bien Una prueba más avanzada consistiría en confirmar que la encapsulación IPsec funciona con la fragmentación en cada área de la red mediante el uso de ping –l 5000 <IP address> desde el servidor de prueba a los equipos que se encuentran en cada área. La opción –l 5000 provoca que Ping cree una carga de paquete ICMP de 5000 bytes. El protocolo IPsec encapsulará este paquete IP completo y, a continuación, la capa IP lo fragmentará antes de transmitirlo. Todos los fragmentos se deben recibir en el destino y se devuelve una respuesta que consta de un número igual de fragmentos. La experiencia ha demostrado que los dispositivos congestionados o que sirven de límites entre redes de distinta velocidad (por ejemplo, entre Ethernet de 1 gigabit y de 100 megabits) pueden tener problemas al transferir fragmentos. De forma similar, los hosts que se encuentran en vínculos de MTU distinta (como ATM, modo de transferencia asincrónico, FDDI, interfaz de datos distribuidos por fibra, y Token Ring) requieren mensajes ICMP PMTU para detectar correctamente la MTU de ruta de red para los paquetes TCP protegidos por IPsec. Consulte el artículo 314496 de Knowledge Base, "Tamaño de MTU predeterminado para otra topología de red diferente", en http://support.microsoft.com/kb/314496 para obtener información acerca de los distintos valores predeterminados de MTU de red. Solución de problemas de negociación IKELos problemas de IKE pueden resultar difíciles de solucionar porque los errores puede que se produzcan sólo en determinadas situaciones, por ejemplo, cuando se inicia el modo rápido IKE únicamente desde un equipo que normalmente es el contestador. Los problemas también se pueden deber a errores en el sistema de autenticación, como los errores del protocolo Kerberos, o cuando se combinan diseños de directiva incompatibles o una directiva existente con la directiva de dominio. Los errores de IKE provocan que el equipo con la condición de error deje de participar en la negociación IKE, y que el otro equipo de la negociación normalmente agote su límite de reintentos y el tiempo de espera. Si se produce un error en IKE, intente estudiar el error y capturar los registros sin efectuar cambios. La auditoría estándar se puede habilitar dinámicamente sin cambiar la configuración IPsec o el estado de funcionamiento del servicio. No obstante, en Windows 2000 se debe reiniciar el servicio IPsec para habilitar el registro IKE detallado en el archivo Oakley.log. En SP2 de Windows XP y Windows Server 2003, el registro IKE se puede habilitar y deshabilitar mediante la línea de comandos siempre que sea necesario. En algunas situaciones, puede ser necesario detener y reiniciar el servicio IPsec para estudiar el tráfico de red y capturar los resultados del archivo Oakley.log de un estado correcto. Cuando el servicio IPsec se detiene manualmente o como parte del reinicio o cierre del equipo, IKE intenta enviar mensajes de eliminación para limpiar el estado de asociación de seguridad IPsec en todos los principales conectados de forma activa. En ocasiones, el sistema operativo deshabilita la capacidad de enviar paquetes antes de que IKE termine de enviar mensajes de eliminación a todos los principales activos, lo que provoca que el estado de asociación de seguridad IPsec permanezca en el principal. Cuando esto sucede, el principal puede creer que está conectado de forma segura al equipo que se está reiniciando. Después del reinicio, si el equipo no inicia una nueva negociación IKE con su principal, éste tendrá que esperar cinco minutos para que se agote el tiempo de espera de las asociaciones de seguridad IPsec antes de intentar restablecerlas. Para restablecer las asociaciones de seguridad, primero se intenta una negociación de modo rápido durante un minuto y, a continuación, un inicio de modo principal IKE. Desde Windows 2000, el registro IKE se ha mejorado en cada versión. Los sucesos documentados en esta sección se aplican a Windows XP y Windows Server 2003, aunque los sucesos de Windows 2000 tienen una naturaleza similar. El registro de seguridad de Windows es el punto de partida recomendado para intentar determinar el motivo de un error de negociación IKE. Para ver los sucesos IKE, se debe habilitar la auditoría de correcto o error en la configuración "Auditar sucesos de inicio de sesión" de la directiva de seguridad de grupo. Tras habilitar la auditoría, el servicio IKE creará las entradas de auditoría y ofrecerá una explicación del motivo del error en la negociación. No obstante, la explicación de los errores en la negociación IKE casi siempre se proporciona como un error de suceso 547 y puede haber varias causas posibles para el mismo mensaje de error. La lista de los errores de suceso 547 y las causas posibles se describen en detalle en las siguientes secciones. En Windows XP SP2 y Windows Server 2003, todas las auditorías de IKE se pueden deshabilitar con la clave del Registro DisableIKEAudits. Asegúrese de comprobar este valor en los equipos que se estén investigando. Las auditorías de IKE se pueden deshabilitar cuando la auditoría genera tantos sucesos correctos o de error que otros sucesos de la categoría de inicio o cierre de sesión no se pueden supervisar de forma eficaz. Los valores de código de error se suelen indicar en los sucesos de auditoría de IKE y en los detalles de registro. Las descripciones de estos valores de código de error están disponibles en Microsoft MSDN®, en la página System Code Errors (12000-15999) en http://msdn.microsoft.com/library/en-us/debug/base/ La solución de los problemas de negociación IKE requiere un conocimiento exhaustivo del comportamiento previsto del diseño de la directiva IPsec, el proceso de negociación IKE y los sucesos de error de IKE. En esta sección se intentan explicar únicamente los sucesos más habituales relacionados con el escenario de aislamiento de dominio de Woodgrove Bank. No trata todos los sucesos de auditoría ni las condiciones de error de IKE. Después de haber comprendido bien el proceso de negociación IKE, se debe obtener, si es posible, un seguimiento de red de un lado de la comunicación como mínimo para identificar los problemas en IKE antes de intentar recopilar un archivo Oakley.log. Los servidores implementados en escenarios de aislamiento de servidor y dominio deben disponer de la capacidad de capturar un seguimiento con Monitor de red. El archivo Oakley.log proporciona el registro más detallado disponible y se puede requerir de ambos lados de la negociación (con tiempos sincronizados). No obstante, si habilita este registro, se puede ralentizar la negociación IKE, lo que cambiará las condiciones de temporización y provocará que se pierda el estado existente si el servicio se reinicia para volver a leer la clave del Registro (necesario en Windows 2000 y SP1 de Windows XP). Actualmente no existe ninguna guía publicada para interpretar el archivo Oakley.log. A efectos de esta guía, dicha interpretación se considera parte del conjunto de conocimientos del nivel 3. Debido a restricciones de espacio, aquí se ofrecen breves extractos de los detalles de registro para unos pocos errores. Para obtener ayuda con el fin de interpretar el archivo Oakley.log, póngase en contacto con el servicio de soporte técnico de Microsoft. Se mantienen los siguientes cuatro archivos de registro detallado para IKE:
Un error habitual que se suele cometer durante la solución de problemas consiste en no sincronizar la hora en los dos equipos de los que se capturan el registro y los seguimientos de red. De este modo resulta difícil la correlación de registros, aunque no imposible. La correlación de los mensajes IKE con los paquetes de un seguimiento de red se debe comprobar con las cookies de encabezado ISAKMP y los campos identificadores de mensajes de modo rápido IKE. Comportamientos de IKE esperadosSi la red impide que la iniciación de modo principal IKE tenga acceso a la dirección IP de destino prevista, no se podrá negociar la comunicación protegida por IPsec. Si el iniciador no está configurado para retroceder a texto no cifrado, la imposibilidad de ponerse en contacto con el destino aparecerá como un suceso de auditoría 547 en el registro de seguridad con una de las siguientes entradas de texto:
No obstante, para los clientes de aislamiento de dominio, esta condición puede no aparecer como un error si su directiva permite el retroceso a texto no cifrado. Cuando se establece una asociación de seguridad por software, se crea un suceso correcto 541 de modo principal IKE. La indicación de que un suceso 541 muestra una asociación de seguridad por software es que el SPI de salida es cero y todos los algoritmos se muestran como Ninguno. En el siguiente ejemplo se muestran estos parámetros en el suceso 541: ESP Algorithm None HMAC Algorithm None AH Algorithm None Encapsulation None InboundSpi 31311481 (0x1ddc679) OutBoundSpi 0 (0x0) Lifetime (sec) <whatever is configured for QM lifetime> Lifetime (kb) 0 Nota: los eventos de asociación de seguridad por software a la misma dirección IP de destino tendrán marcas de hora distintas y valores de SPI de entrada diferentes. Se producen retrasos de conectividad de un minuto siempre que dos equipos dejan de estar sincronizados en relación con la existencia potencial de un modo principal IKE activo entre ellos. Se pueden producir retrasos de cinco minutos si un equipo cree que hay un par de asociaciones de seguridad IPsec activo entre ellos y el otro equipo (por ejemplo, un servidor) ha eliminado estas asociaciones de seguridad y no está iniciando una regeneración de claves de modo rápido. IKE de Windows 2000 admitía mensajes de eliminación simple, que se perdían en ocasiones. Windows XP y Windows Server 2003 han agregado compatibilidad para la funcionalidad de eliminación "fiable" en forma de mensajes de eliminación múltiple como protección frente a los paquetes descartados. El escenario más común para esta situación es aquel en que un usuario de portátil de aislamiento de dominio extrae el portátil de la estación de acoplamiento para asistir a una reunión. La estación de acoplamiento tiene una conexión Ethernet por cable y el acto de quitar dicha interfaz de red requiere que se eliminen todos los filtros asociados a la misma (si se trata de filtros expandidos de Mi dirección IP). No obstante, ninguno de los filtros con un acción de negociación utiliza Mi dirección IP en la solución de aislamiento de dominio, todos son filtros Cualquiera <-> subred. Por lo tanto, los estados de asociación de seguridad IPsec e IKE permanecen activos en el equipo portátil porque estos filtros no se eliminan en cada cambio de dirección. Si los filtros se han expandido de "Mi dirección IP", se eliminarán cuando desaparezca la dirección IP. Cada vez que un filtro de cualquier tipo se elimina del controlador IPsec, éste informa a IKE de que también se tienen que eliminar todas las asociaciones de seguridad IKE e IPsec que utilizan dicha dirección IP. IKE intentará enviar mensajes de eliminación para estas asociaciones de seguridad y las eliminará internamente. Estos mensajes de eliminación tendrán la misma IP de origen que se utilizó para la asociación de seguridad IKE, aunque puede estar presente otra IP de origen en la interfaz conectada en el momento que se envía la eliminación. El equipo remoto no tiene en cuenta la dirección IP de origen si se reconoce el par de cookies de encabezado ISAKMP y las comprobaciones de cifrado en el paquete son válidas. No obstante, estos mensajes de eliminación no se suelen enviar porque no hay conectividad de red segundos después de que se produzca la desconexión (el equipo portátil se ha extraído). En este caso concreto de filtros Cualquiera <-> subred, los filtros nunca se eliminan, lo que significa que las asociaciones de seguridad IKE e IPsec no se eliminan automáticamente. Mientras tanto, las asociaciones de seguridad IPsec en los equipos remotos que anteriormente estaban conectadas y las eliminaciones de modo rápido IKE se envían a la dirección anterior del equipo portátil. Las asociaciones de seguridad de modo principal IKE permanecen activas durante un tiempo predeterminado de 8 horas en estos equipos remotos, pero se pueden haber eliminado anteriormente por motivos internos que conoce IKE. Como es evidente, el equipo portátil no recibe los mensajes de eliminación de asociación de seguridad IKE en su dirección IP anterior. Cuando el equipo portátil finalmente se vuelve a conectar a la estación de acoplamiento, vuelve a recibir la misma dirección IP. Los recursos compartidos de archivos, los clientes de correo electrónico y otras aplicaciones normalmente se vuelven a conectar a los mismos destinos. No obstante, puede haber diferencias en el estado IKE entre el equipo portátil y estos destinos remotos. Si el equipo portátil todavía tiene un modo principal IKE, intentará una negociación de modo rápido IKE. El modo rápido utiliza un estado de cifrado que el principal remoto ha eliminado, por lo que no reconoce estos mensajes y no responde. En el equipo portátil, IKE hace caducar el límite de reintentos al cabo de un minuto e intenta una nueva negociación de modo principal IKE, que ahora se realiza correctamente. En consecuencia, el usuario del equipo puede advertir un retraso de un minuto al volver a establecer la conexión con los recursos remotos. Microsoft espera poder mejorar este comportamiento en actualizaciones futuras de todas las versiones de Windows que admiten IPsec. La negociación IKE puede informar de que se ha agotado el tiempo de espera por varios motivos. El suceso "Tiempo de espera de negociación caducado" tiene lugar cuando se produce un error en algún paso de la negociación IKE (excepto el retroceso a texto no cifrado) porque se ha agotado el límite de reintentos, excepto cuando IKE termina la negociación con el suceso "Asociación de seguridad IKE eliminada antes de completarse el establecimiento". Estos dos sucesos son esencialmente los mismos. Suelen ser habituales, benignos y previsibles durante las operaciones normales para los clientes móviles, que cambian con frecuencia y rápidamente los estados de conectividad de red cuando se producen los siguientes sucesos:
Un equipo remoto toma estos sucesos como indicación de que el otro equipo se ha desconectado de la red. El equipo remoto intentará regenerar las claves o volver a negociar hasta que se agote el tiempo de espera del paso de la negociación IKE. Los errores de tiempo de espera de negociación se han mejorado en Windows Server 2003 para determinar dónde se ha agotado el tiempo de espera en la negociación IKE mediante la identificación del último paso correcto en la negociación. Estos sucesos también se pueden deber a la presencia de traducción de direcciones de red (NAT) cuando IKE está negociando sin capacidades NAT-T. Sin embargo, también se agotará el tiempo de espera de la negociación IKE si el principal remoto encuentra algún motivo para no establecer la negociación IKE. Por lo tanto, en todos los casos de tiempo de espera de negociación caducado y sucesos "Asociación de seguridad IKE eliminada antes de completarse el establecimiento", el departamento de soporte técnico de nivel 2 debe identificar si el equipo realmente no ha podido realizar la negociación. Para ello, debe consultar los sucesos de auditoría de error 547 en dicho equipo de hasta un minuto antes de que se agotara el tiempo de espera. Sucesos correctos de la negociación IKESi la negociación IKE es correcta, las asociaciones de seguridad de modo principal IKE se mostrarán en el complemento Monitor IPSec de MMC y mediante las herramientas de consulta de la línea de comandos. Para mostrar una lista de las asociaciones de seguridad de modo principal IKE actuales
Las asociaciones de seguridad de modo principal y de modo rápido generarán los siguientes sucesos en el registro de seguridad si está habilitada la auditoría.
Entradas de registro informativas del modo principal IKEPara determinar si hay un problema con el intercambio del modo principal, busque los siguientes sucesos registrados en los registros de sucesos del equipo: Tabla 7.5: Mensajes de registro informativos del modo principal IKE
La existencia de estas entradas no indica un error en las comunicaciones. Estas entradas son informativas y se pueden utilizar para ofrecer información adicional con el fin de determinar la causa real de un problema. Sucesos de error 547 de la negociación de modo principal IKEPueden producirse los siguientes sucesos de error 547 cuando falla la negociación de modo principal IKE:
Se puede esperar cualquiera de los siguientes mensajes "Tiempo de espera de negociación caducado" por los motivos descritos anteriormente. También pueden indicar que el equipo remoto no ha podido realizar la negociación IKE. Normalmente, el departamento de soporte técnico de nivel 2 se centra en la investigación del error de IKE en el equipo remoto en vez de hacerlo en los tiempos de espera de negociación caducados, que son muy habituales para los equipos desconectados, y en la incompatibilidad de diseño de directiva, en que el contestador a una negociación de modo principal IKE o modo rápido IKE no encuentra un filtro específico que coincida con la solicitud entrante.
Errores de auditoría de modo rápido IKE (547)Se pueden producir los siguientes sucesos de error 547 cuando hay un error en la negociación de modo rápido IKE:
No se deben producir errores en el modo rápido IKE para directivas IPsec diseñadas correctamente y bajo cargas operativas típicas. Si aparece alguno de estos errores, primeramente, el departamento de soporte técnico de nivel 2 debe seguir los pasos de la sección "Comprobación de la directiva IPsec correcta". A continuación, debe intentar correlacionar estos sucesos con las condiciones de rendimiento no habituales, como un uso de CPU del 100% o unas condiciones de muy poca memoria de núcleo. Tenga en cuenta que se prevén errores de modo rápido IKE con el tiempo de espera de negociación agotado si el equipo ya no utiliza su dirección IP anterior o por alguno de los motivos explicados anteriormente. Solución de problemas de IKE provocados por la autenticaciónLos siguientes mensajes están relacionados con los errores de autenticación de IKE:
Los dos primeros mensajes indican que la identidad Kerberos del equipo remoto no se puede utilizar para obtener un vale de servicio para el equipo remoto. Esta situación se puede producir porque no hay confianza de dominio o porque no está disponible el acceso a los controladores de dominio. Si no se puede realizar una negociación IKE entrante debido a la configuración de "Tener acceso a este equipo desde la red", la negociación IKE en el lado que aplica los derechos de acceso informará de un suceso 547 "Error al autenticar usando Kerberos", tal como se ha descrito anteriormente. Dicho suceso no indica específicamente que el problema sea el error al activar los derechos "Tener acceso a este equipo desde la red" y, por lo tanto, se debe obtener un archivo Oakley.log del servidor para ver el error específico que se ha generado. Debe investigarse la pertenencia a grupos del iniciador IKE para comprobar si se trata de hecho de un miembro de un grupo autorizado. Si el equipo es miembro de un grupo que tiene acceso autorizado, es posible que no tenga vales Kerberos que refleje la nueva pertenencia a grupos. Asimismo, es posible que el equipo no pueda obtener vales Kerberos correctos. Realice los procedimientos descritos en la sección "Comprobación de la conectividad y la autenticación con los controladores de dominio", incluida anteriormente en este capítulo. Solución de problemas relacionados con las aplicacionesEn esta sección se describe el modo en que el diseño de las aplicaciones puede interactuar con el uso de IPsec en Microsoft Windows. El diseñador de la directiva IPsec debe comprender estas consecuencias. Asimismo, el personal de soporte técnico debe conocerlas para poder clasificar e identificar los problemas rápidamente. La aplicación de la directiva IPsec debe ser muy transparente para las aplicaciones. No obstante, existen circunstancias en las que asignar una directiva IPsec o proteger el tráfico pueden provocar que la aplicación se comporte de modo distinto. En las siguientes secciones se destacan estas cuestiones en el contexto de la solución de aislamiento de dominio de Woodgrove Bank. ICMP permitido, pero TCP y UDP requieren IPsecAlgunas aplicaciones utilizan un mensaje de solicitud de eco ICMP (Ping) para determinar si está accesible una dirección de destino. Por ejemplo, IPsec no protege el tráfico ICMP en esta solución, por lo que una aplicación puede recibir una respuesta ICMP de un destino. Sin embargo, es posible que la aplicación no pueda conectarse al destino mediante tráfico TCP y UDP protegido por IPsec cuando falle la negociación IKE. Retrasos de conexión inicialesLa negociación IKE conlleva considerablemente más procesamiento y tiempo en completarse que un protocolo de enlace de tres vías TCP o una consulta y respuesta de paquete único Nbtstat autenticado. Las aplicaciones que prevén una respuesta de conexión TCP o UDP rápida de un destino pueden determinar que el destino no responde y adoptar otra medida, como informar de un error o intentar conectarse a un destino alternativo. Las negociaciones IKE que utilizan autenticación Kerberos normalmente terminan correctamente en 1-2 segundos. No obstante, este tiempo depende de muchos factores, en concreto, el uso de CPU de ambos equipos y la pérdida de paquetes de red. El retroceso a texto no cifrado siempre requiere tres segundos antes de permitir que el primer paquete del protocolo de enlace TCP se envíe desprotegido. Bloqueos de aplicación al esperar respuesta de la redAlgunas aplicaciones están escritas para suponer que el tiempo para conectarse o recibir un mensaje de error es muy breve. Estas aplicaciones esperarán a que la conexión se establezca (que termine la operación de enlace de socket) antes de mostrar cambios en la interfaz de usuario. Cuando el tráfico de esta aplicación está protegido mediante IPsec, puede parecer que la aplicación se bloquea brevemente durante las conexiones correctas. La aplicación se puede bloquear hasta que termine o se produzcan otros errores no habituales si la conexión no se establece correctamente debido a un error de negociación IKE o a un filtro de bloqueo IPsec. La capa de sockets de red no tiene en cuenta los filtros IPsec o que IKE está negociando la seguridad del tráfico. Normalmente, la aplicación interpreta que estas situaciones se deben a que el host remoto está inactivo o a un error de red. No obstante, las aplicaciones también pueden interpretar los errores de acceso a controladores de dominio como provocados porque el equipo de destino no está disponible o que la conexión se ha rechazado. Procesamiento de paquetes de red en modo núcleo afectadoLas aplicaciones que tienen que ver con controladores de red u otro procesamiento de paquetes en el nivel de núcleo pueden no funcionar correctamente cuando IPsec protege el tráfico. Estas aplicaciones pueden efectuar modificaciones en el paquete, lo que provocará que IPsec lo descarte. Además, las modificaciones IPsec pueden confundir a la aplicación, con un posible resultado de error del sistema (pantalla azul). Exploración de la red desde hosts en dominio de aislamiento afectadaLas herramientas basadas en host que sondean rápidamente las direcciones IP remotas o los puertos abiertos en la red pueden ejecutarse más lentamente si IPsec intenta proteger su tráfico de sondeo. El tráfico de sondeo puede provocar una denegación de servicio en el host local al provocar que IKE se inicie en centenares de direcciones IP en pocos segundos o minutos. Algunas herramientas basadas en SNMP dependen de que se envíen sucesos de captura SNMP a hosts que no son de confianza y que actúan como recolectores de sucesos. Aunque a IPsec se le permita el retroceso a texto no cifrado, es posible que el controlador IPsec descarte los paquetes de captura SNMP salientes antes de que se establezca la asociación de seguridad por software. De modo similar, algunas aplicaciones basadas en UDP (como NTP y el localizador de controlador de dominio de Windows) sólo esperan tres segundos para recibir una respuesta, lo que provoca un error en la aplicación o informes falsos de que un destino es inaccesible. Problemas de proveedores de servicios por niveles de WinsockAlgunas aplicaciones legítimas (como los servidores de seguridad personales) y algunas aplicaciones malintencionadas (como el software espía) pueden provocar problemas si insertan sus propias funciones de inspección de tráfico de red, que se denominan proveedores de servicios por niveles (LSP) de Winsock. El componente IKE de la implementación de Microsoft de IPsec utiliza una función de la API de Winsock ampliada cuyo puntero de función se determina mediante una llamada a WSAIoctl(). Si no se permite que esta llamada de función pase por los LSP instalados, IKE no podrá supervisar los puertos UDP requeridos. En Windows Server 2003, IPsec interpreta esto como un error del componente al aplicar la directiva de seguridad requerida y reacciona a la defensiva. Cuando se invoca el "modo seguro" y el controlador IPsec pasa al modo de bloqueo. Un administrador debe iniciar sesión mediante un inicio de sesión de escritorio para detener el servicio IPsec y restaurar la conectividad. Si el servicio IPsec no responde a la solicitud de detención, se debe configurar como deshabilitado y reiniciar el equipo. Aunque parezca que IKE no tiene una inicialización correcta, el LSP u otro programa de terceros instalado puede bloquear la capacidad del equipo para enviar y recibir protocolos IKE e IPsec. Para el soporte técnico de nivel 2, la solución de problemas de LSP de Winsock consiste en la identificación de que existen LSP. El soporte técnico de nivel 3 debe realizar una investigación exhaustiva para identificar la aplicación que ha instalado los LSP y reordenarlos o quitarlos para comprobar si el servicio IPsec o IKE ya no tienen problemas. Entre las herramientas para detectar los LSP de Winsock se incluyen:
Clientes VPN IPsec de tercerosPuede darse una serie de problemas cuando una implementación IPsec de terceros se instala como parte de un cliente VPN de acceso remoto. Normalmente, estos clientes deshabilitan el servicio IPsec y no están en conflicto con IPsec de Windows nativo. No obstante, se requiere el servicio IPsec nativo para los miembros del dominio de confianza de esta solución. Por lo tanto, las implementaciones de IPsec de terceros pueden entrar en conflicto por los siguientes motivos:
Los proveedores de VPN pueden constituir la mejor fuente de información acerca de si admiten que el servicio IPsec de Windows nativo esté habilitado y si el tráfico en modo de transporte protegido por IPsec se admite por completo a través de su conexión de acceso remoto. En algunos casos, la puerta de enlace del proveedor de VPN admite clientes VPN PPTP y L2TP/IPsec de Windows 2000 y Windows XP. Los clientes VPN de Windows nativos son compatibles con el modo de transporte IPsec completo a través del túnel VPN. Solución de problemas de nivel 3Si con los procedimientos de solución de problemas de nivel 2 no se resuelve el problema, se necesitará experiencia adicional para analizarlo y encontrar una solución. Esta experiencia se considera soporte técnico de nivel 3. En muchos casos, este soporte técnico lo proporcionan especialistas de IPsec contratados u organizaciones de soporte técnico, como el servicio de soporte técnico de Microsoft. El soporte técnico de IPsec de nivel 3 requiere un conocimiento exhaustivo del funcionamiento de IPsec y la pila TCP/IP de Microsoft. El personal de soporte técnico de nivel 3 necesita una formación importante en IPsec y el uso de IPsec en escenarios de aislamiento de servidor y dominio. Los conocimientos que adquiera el personal de nivel 3 pueden permitirles ser responsables de la formación de personal de niveles inferiores y desarrollar documentación de soporte técnico, como resúmenes técnicos, notas de productos, guías de soporte técnico, preguntas más frecuentes e información acerca de la arquitectura y taxonomía de IPsec. El departamento de soporte técnico de nivel 3 también puede ser responsable de desarrollar y documentar los planes de recuperación de desastres. Participación del servicio de soporte técnico de MicrosoftSi los procedimientos de solución de problemas descritos en este capítulo no le ayudan a resolver el problema o si su organización no dispone de suficiente experiencia para utilizar técnicas avanzadas para la solución de problemas, es posible que tenga que transferir el problema al servicio de soporte técnico de Microsoft. Es importante recopilar la máxima información de diagnóstico que sea posible, como la obtenida de los registros y la supervisión de red, antes de ponerse en contacto con el servicio de soporte técnico. Utilice esta lista para recopilar información que el departamento de soporte técnico de nivel 3 o el servicio de soporte técnico de Microsoft necesitarán para analizar el problema:
Para crear un archivo de texto con formato de estos filtros
Un archivo de texto delimitado por tabulaciones con todos los detalles de los filtros se puede importar en una hoja de cálculo o en un documento de procesador de textos. ResumenEn este capítulo se ha proporcionado información detallada acerca de los procesos que ayudarán a los departamentos de soporte técnico de nivel 1 (personal de servicio de asistencia) y de nivel 2 (personal de soporte técnico de red profesional de TI) a comprender el modo de solucionar problemas de comunicación IPsec habituales. No es posible proporcionar información acerca de todos los errores posibles; IPsec y la seguridad de red son cuestiones tan complejas que no se podrían enumerar todas las variaciones. En la medida de lo posible, los desarrolladores de este capítulo han simplificado las posibles opciones para centrarse en la orientación de las áreas donde es más probable que se produzcan problemas en el tipo de entorno de aislamiento de servidor y dominio que se detalla en esta guía. Las secuencias de comandos proporcionadas con esta guía se han probado en la implementación de laboratorio de pruebas del escenario de Woodgrove Bank para probar su eficacia. No obstante, estas secuencias de comandos están diseñadas para que se personalicen según las necesidades de una organización y, por lo tanto, Microsoft no ofrece soporte técnico. Debe resultar evidente para el lector que la solución de problemas de IPsec es técnicamente compleja y requiere conocimientos especiales en numerosas áreas de tecnología aparte de IPsec, incluidas las funciones de red, Active Directory y Directiva de grupo. Sin embargo, la información proporcionada en este capítulo debería permitir al lector solucionar todos los problemas (excepto los más complejos) que pueden afectar a una solución de aislamiento de servidor y dominio. Para los lectores que deseen ampliar sus conocimientos en los páramos del soporte técnico de nivel 3, en la siguiente sección se hace referencia a suficiente material de lectura adicional como para mantenerlos ocupados durante años. Información adicional
|
En este artículo
|
