Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configurar VPN IPsec basada en políticas con certificados

En este ejemplo, se muestra cómo configurar, verificar y solucionar problemas de PKI. En este tema se incluyen las siguientes secciones:

Requisitos

En este ejemplo, se utilizan los siguientes componentes de hardware y software:

  • Versión 9.4 o posterior de Junos OS

  • Dispositivos de seguridad de Juniper Networks

Antes de comenzar:

  • Asegúrese de que la interfaz LAN interna del dispositivo de la serie SRX sea ge-0/0/0 en confianza de zona y tenga una subred IP privada.

  • Asegúrese de que la interfaz de Internet del dispositivo esté ge-0/0/3 en la zona desconfiada y tenga una IP pública.

  • Asegúrese de que se permite todo el tráfico entre las LAN locales y remotas, y que el tráfico se puede iniciar desde cualquier lado.

  • Asegúrese de que el SSG5 se preconfiguró correctamente y se cargó con un certificado local listo para usar, certificado de CA y CRL.

  • Asegúrese de que el dispositivo SSG5 esté configurado para usar el FQDN de ssg5.example.net (ID de IKE).

  • Asegúrese de que los certificados PKI con claves de 1024 bits se usen para las negociaciones de IKE en ambos lados.

  • Asegúrese de que la CA sea una CA independiente en el dominio example.com para ambos pares VPN.

Descripción general

Figura 1 muestra la topología de red utilizada para este ejemplo para configurar una VPN IPsec basada en políticas para permitir que los datos se transfieran de forma segura entre una oficina corporativa y una oficina remota.

Figura 1: Diagrama de topología de redDiagrama de topología de red

La administración de PKI es la misma para VPN basadas en políticas y VPN basadas en rutas.

En este ejemplo, el tráfico VPN entra en la interfaz ge-0/0/0.0 con el salto siguiente de 10.1.1.1. Por lo tanto, el tráfico se saliente en la interfaz ge-0/0/3.0. Cualquier política de túnel debe tener en cuenta las interfaces entrantes y salientes.

Opcionalmente, puede usar un protocolo de enrutamiento dinámico como OSPF (no descrito en este documento). Cuando se procesa el primer paquete de una sesión nueva, el dispositivo que ejecuta Junos OS realiza primero una búsqueda de ruta. La ruta estática, que también es la ruta predeterminada, dicta la zona para el tráfico VPN saliente.

Muchos CA usan nombres de host (por ejemplo, FQDN) para especificar varios elementos de la PKI. Dado que el CDP normalmente se especifica mediante una DIRECCIÓN URL que contiene un FQDN, debe configurar una resolución DNS en el dispositivo que ejecuta Junos OS.

La solicitud de certificado se puede generar mediante los siguientes métodos:

  • Creación de un perfil de CA para especificar la configuración de CA

  • Generación de la solicitud de certificado PKCS10

El proceso de solicitud de certificado PKCS10 implica generar un par de claves públicas o privadas y, luego, generar la propia solicitud de certificado mediante el par de claves.

Tome nota de la siguiente información sobre el perfil de CA:

  • El perfil de CA define los atributos de una autoridad de certificación.

  • Cada perfil de CA está asociado a un certificado de CA. Si se debe cargar un certificado de CA nuevo o renovado sin quitar el certificado de CA más antiguo, se debe crear un perfil nuevo. Este perfil también se puede utilizar para la obtención en línea de la CRL.

  • Puede haber varios perfiles de este tipo presentes en el sistema creados para diferentes usuarios.

Si especifica una dirección de correo electrónico de administrador de CA a la que enviar la solicitud de certificado, el sistema compone un correo electrónico desde el archivo de solicitud de certificado y lo reenvía a la dirección de correo electrónico especificada. La notificación de estado de correo electrónico se envía al administrador.

La solicitud de certificado se puede enviar a la CA mediante un método fuera de banda.

Las siguientes opciones están disponibles para generar la solicitud de certificado PKCS10:

  • certificate-id — Nombre del certificado digital local y el par de claves pública/privada. Esto garantiza que se utilice el par de claves adecuado para la solicitud de certificado y, en última instancia, para el certificado local.

    A partir de Junos OS versión 19.1R1, se agrega una comprobación de confirmación para evitar que el usuario agregue ., /, %y espacio en un identificador de certificado mientras genera un certificado local o remoto o un par de claves.

  • subject — Formato de nombre distinguido que contiene el nombre común, el departamento, el nombre de la empresa, el estado y el país:

    • CN: nombre común

    • Ou — Departamento

    • O— Nombre de la empresa

    • L — Localidad

    • ST — Estado

    • C — País

    • CN — Teléfono

    • DC: componente de dominio

      No es necesario introducir todos los componentes del nombre del asunto. Tenga en cuenta también que puede introducir varios valores de cada tipo.

  • domain-name — FQDN. El FQDN proporciona la identidad del propietario del certificado para las negociaciones de IKE y proporciona una alternativa al nombre del asunto.

  • filename (path | terminal) — (Opcional) Ubicación en la que se debe colocar la solicitud de certificado o el terminal de inicio de sesión.

  • ip-address — (Opcional) dirección IP del dispositivo.

  • email — (Opcional) Dirección de correo electrónico del administrador de CA.

    Debe usar un nombre de dominio, una dirección IP o una dirección de correo electrónico.

La solicitud de certificado generada se almacena en una ubicación de archivo especificada. Se guarda una copia local de la solicitud de certificado en el almacenamiento de certificados local. Si el administrador vuelve a emitir este comando, se generará de nuevo la solicitud de certificado.

La solicitud de certificado PKCS10 se almacena en un archivo y una ubicación especificados, desde los cuales puede descargarla y enviarla a la CA para su inscripción. Si no especificó el nombre de archivo o la ubicación, puede obtener detalles de solicitud de certificado PKCS10 mediante el show security pki certificate-request certificate-id <id-name> comando de la CLI. Puede copiar el resultado del comando y pegarlo en un front-end web para el servidor de CA o en un correo electrónico.

La solicitud de certificado PKCS10 se genera y se almacena en el sistema como una solicitud de certificado o certificado pendiente. Se envía una notificación de correo electrónico al administrador de la CA (en este ejemplo, certadmin@example.com).

Una identidad única denominada ID de certificado se usa para nombrar el par de claves generado. Este ID también se usa en la inscripción de certificados y en los comandos de solicitud para obtener el par de claves correcto. El par de claves generado se guarda en el almacén de certificados en un archivo con el mismo nombre que el ID de certificado. El tamaño del archivo puede ser de 1024 o 2048 bits.

Se puede crear un perfil predeterminado (reserva) si las CA intermedias no están preinstaladas en el dispositivo. Los valores de perfil predeterminados se utilizan en ausencia de un perfil de CA configurado específicamente.

En el caso de un CDP, se sigue el siguiente orden:

  • Por perfil de CA

  • CDP integrado en certificado de CA

  • Perfil de CA predeterminado

Recomendamos usar un perfil de CA específico en lugar de un perfil predeterminado.

El administrador envía la solicitud de certificado a la CA. El administrador de CA verifica la solicitud de certificado y genera un nuevo certificado para el dispositivo. El administrador del dispositivo de Juniper Networks lo recupera, junto con el certificado de CA y CRL.

El proceso de recuperar el certificado de CA, el nuevo certificado local del dispositivo y la CRL de la CA depende de la configuración de ca y del proveedor de software en uso.

Junos OS admite los siguientes proveedores de CA:

  • Confiar

  • Verisign

  • Microsoft

Aunque otros servicios de software de CA, como OpenSSL, se pueden usar para generar certificados, Junos OS no verifica estos certificados.

Configuración

Configuración básica de PKI

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.

Para configurar PKI:

  1. Configure una familia de protocolos y direcciones IP en las interfaces de Gigabit Ethernet.

  2. Configure una ruta predeterminada al próximo salto de Internet.

  3. Establezca la hora y la fecha del sistema.

    Después de confirmar la configuración, verifique la configuración del reloj mediante el show system uptime comando.

  4. Establezca la dirección del servidor NTP.

  5. Establezca la configuración de DNS.

Configuración de un perfil de CA

Procedimiento paso a paso

  1. Cree un perfil de CA de confianza.

  2. Cree una comprobación de revocación para especificar un método para comprobar la revocación del certificado.

    Establezca el intervalo de actualización, en horas, para especificar la frecuencia en la que se va a actualizar la CRL. Los valores predeterminados son la próxima hora de actualización en CRL, o 1 semana, si no se especifica ninguna hora de actualización siguiente.

    En la revocation-check instrucción de configuración, puede usar la disable opción para deshabilitar la comprobación de revocación o seleccionar la crl opción para configurar los atributos CRL. Puede seleccionar la disable on-download-failure opción para permitir que las sesiones coincidan con el perfil de CA, cuando se produjo un error en la descarga de CRL para un perfil de CA. Las sesiones solo se permitirán si ninguna CRL antigua está presente en el mismo perfil de CA.

  3. Especifique la ubicación (URL) para recuperar la CRL (HTTP o LDAP). De forma predeterminada, la DIRECCIÓN URL está vacía y utiliza la información CDP incrustada en el certificado de CA.

    Actualmente solo puede configurar una DIRECCIÓN URL. La compatibilidad con la configuración de URL de respaldo no está disponible.

  4. Especifique una dirección de correo electrónico para enviar la solicitud de certificado directamente a un administrador de CA.

  5. Confirme la configuración:

Generación de un par de claves públicas y privadas

Procedimiento paso a paso

Cuando se configura el perfil de CA, el siguiente paso es generar un par de claves en el dispositivo de Juniper Networks. Para generar el par de claves privadas y públicas:

  1. Cree un par de claves de certificado.

Resultados

Después de generar el par de claves público-privado, el dispositivo de Juniper Networks muestra lo siguiente:

Inscribir un certificado local

Procedimiento paso a paso

  1. Genere una solicitud de certificado digital local en el formato PKCS-10. Consulte solicitud de seguridad pki generate-certificate-request.

    En el ejemplo del certificado PKCS10, la solicitud comienza con e incluye la línea BEGIN CERTIFICATE REQUEST y termina con e incluye la línea END CERTIFICATE REQUEST. Esta parte se puede copiar y pegar en su CA para su inscripción. Opcionalmente, también puede descargar el archivo ms-cert-req y enviarlo a su CA.

  2. Envíe la solicitud de certificado a la CA y recupere el certificado.

Carga de CERTIFICADOS y certificados locales

Procedimiento paso a paso

  1. Cargue el certificado local, el certificado de CA y la CRL.

    Puede comprobar que todos los archivos se cargaron con el comando file list.

  2. Cargue el certificado en el almacenamiento local desde el archivo externo especificado.

    También debe especificar el ID de certificado para mantener el vínculo adecuado con el par de claves privadas o públicas. En este paso, se carga el certificado en el almacenamiento de memoria caché ram del módulo PKI, se comprueba la clave privada asociada y se verifica la operación de firma.

  3. Cargue el certificado de CA desde el archivo externo especificado.

    Debe especificar el perfil de CA para asociar el certificado de CA al perfil configurado.

  4. Cargue la CRL en el almacenamiento local.

    El tamaño máximo de la CRL es de 5 MB. Debe especificar el perfil de CA asociado en el comando.

Resultados

Compruebe que se cargan todos los certificados locales.

Puede mostrar los detalles del certificado individual especificando el ID de certificado en la línea de comandos.

Compruebe todos los certificados de CA o los certificados de CA de un perfil de CA individual (especificado).

Compruebe todas las CRLs cargadas o las CRLs del perfil de CA individual especificado.

Compruebe la ruta de certificado para el certificado local y el certificado de CA.

Configuración de la VPN IPsec con los certificados

Procedimiento paso a paso

Para configurar la VPN IPsec con el certificado, consulte el diagrama de red que se muestra en Figura 1

  1. Configure zonas de seguridad y asigne interfaces a las zonas.

    En este ejemplo, los paquetes son entrantes en ge-0/0/0y la zona de entrada es la zona de confianza.

  2. Configure los servicios de host entrante para cada zona.

    Los servicios de entrada de host son para el tráfico destinado al dispositivo de Juniper Networks. Estas opciones de configuración incluyen, entre otros, FTP, HTTP, HTTPS, IKE, ping, rlogin, RSH, SNMP, SSH, Telnet, TFTP y traceroute.

  3. Configure las entradas de la libreta de direcciones para cada zona.

  4. Configure la propuesta de IKE (fase 1) para usar el cifrado RSA.

  5. Configure una política de ICR.

    El intercambio de fase 1 puede tener lugar en modo principal o en modo agresivo.

  6. Configure una puerta de enlace IKE.

    En este ejemplo, el par se identifica por un FQDN (nombre de host). Por lo tanto, el ID de IKE de puerta de enlace debe ser el nombre de dominio del par remoto. Debe especificar la interfaz externa o el ID de par correctos para identificar correctamente la puerta de enlace IKE durante la configuración de fase 1.

  7. Configure la política IPsec.

    En este ejemplo, se utiliza el conjunto de propuestas Estándar, que incluye esp-group2-3des-sha1 y esp-group2- aes128-sha1 propone. Sin embargo, se puede crear una propuesta única y, luego, especificarla en la política IPsec si es necesario.

  8. Configure la VPN IPsec con una puerta de enlace IKE y una política IPsec.

    En este ejemplo, se debe hacer referencia al nombre vpn ike-vpn en la política de túnel para crear una asociación de seguridad. Además, si es necesario, se puede especificar un tiempo de inactividad y un ID de proxy si son diferentes de las direcciones de política de túnel.

  9. Configure políticas de túnel bidireccional para el tráfico VPN.

    En este ejemplo, el tráfico de la LAN del host a la LAN de oficina remota requiere una política de túnel de confianza de zona a zona de desconfianza. Sin embargo, si una sesión debe originarse desde la LAN remota a la LAN del host, también es necesaria una política de túnel en la dirección opuesta de la confianza de desconfianza de la zona a la zona. Cuando se especifica la política en la dirección opuesta como la política de par, la VPN se convierte en bidireccional. Tenga en cuenta que, además de la acción de permiso, también debe especificar el perfil IPsec que se va a utilizar. Tenga en cuenta que, para las políticas de túnel, la acción siempre se permite. De hecho, si está configurando una política con la acción denegar, no verá una opción para especificar el túnel.

  10. Configure una regla TDR de origen y una política de seguridad para el tráfico de Internet.

    El dispositivo utiliza la interfaz de origen-nat especificada y traduce la dirección IP de origen y el puerto para el tráfico saliente, utilizando la dirección IP de la interfaz de salida como la dirección IP de origen y un puerto aleatorio superior para el puerto de origen. Si es necesario, se pueden crear políticas más granulares para permitir o denegar cierto tráfico.

  11. Mueva la política de túnel por encima de la política de cualquier permiso.

    La política de seguridad debe estar por debajo de la política de túnel en la jerarquía porque la lista de políticas se lee de arriba abajo. Si esta política estuviera por encima de la política de túnel, el tráfico siempre coincidiría con esta política y no continuaría con la siguiente. Por lo tanto, no se cifraría ningún tráfico de usuario.

  12. Configure la configuración tcp-mss para el tráfico TCP a través del túnel.

    TCP-MSS se negocia como parte del protocolo de enlace TCP de 3 vías. Limita el tamaño máximo de un segmento TCP para adaptarse a los límites de MTU en una red. Esto es muy importante para el tráfico VPN, ya que la sobrecarga de encapsulación IPsec junto con la sobrecarga de IP y trama puede hacer que el paquete ESP resultante supere la MTU de la interfaz física, lo que provoca fragmentación. Dado que la fragmentación aumenta el uso del ancho de banda y de los recursos del dispositivo, y, en general, debe evitarse.

    El valor recomendado para usar para tcp-mss es 1350 para la mayoría de las redes basadas en Ethernet con una MTU de 1500 o superior. Es posible que deba modificarse este valor si cualquier dispositivo de la ruta tiene un valor menor de MTU o si hay alguna sobrecarga adicional, como PPP, Frame Relay, etc. Por regla general, es posible que deba experimentar con diferentes valores tcp-mss para obtener un rendimiento óptimo.

Verificación

Confirme que la configuración funciona correctamente.

Confirmación del estado de fase 1 de ICR

Propósito

Confirme el estado de VPN comprobando cualquier estado de asociaciones de seguridad de fase 1 de IKE.

La PKI relacionada con túneles IPsec se forma durante la configuración de fase 1. La finalización de la fase 1 indica que la PKI tuvo éxito.

Acción

Desde el modo operativo, ingrese el show security ike security-associations comando.

Significado

El resultado indica lo siguiente:

  • El par remoto es 10.2.2.2 y el estado es UP, lo que significa la asociación exitosa del establecimiento de fase 1.

  • El ID de IKE del par remoto, la política IKE y las interfaces externas son todas correctas.

  • El índice 20 es un valor único para cada asociación de seguridad IKE. Puede usar estos detalles de salida para obtener más detalles sobre cada asociación de seguridad. Consulte Obtener detalles sobre asociaciones de seguridad individuales.

La salida incorrecta indicaría lo siguiente:

  • El estado del par remoto está apagado.

  • No hay asociaciones de seguridad IKE.

  • Hay parámetros de política IKE, como el tipo de modo incorrecto (Aggr o Principal), problemas de PKI o propuestas de fase 1 (todos deben coincidir en ambos pares). Para obtener más información, consulte Solución de problemas de IKE, PKI e IPsec.

  • La interfaz externa no es válida para recibir los paquetes IKE. Compruebe las configuraciones para problemas relacionados con la PKI, compruebe el registro del demonio de administración de claves (kmd) para cualquier otro error o ejecute opciones de seguimiento para encontrar la discordancia. Para obtener más información, consulte Solución de problemas de IKE, PKI e IPsec.

Obtener detalles sobre asociaciones de seguridad individuales

Propósito

Obtenga detalles sobre ICR individual.

Acción

Desde el modo operativo, ingrese el show security ike security-associations index 20 detail comando.

Significado

El resultado muestra los detalles de las SA de IKE individuales, como el rol (iniciador o respondedor), el estado, el tipo de intercambio, el método de autenticación, los algoritmos de cifrado, las estadísticas de tráfico, el estado de negociación de fase 2, etc.

Puede utilizar los datos de salida para:

  • Conozca el papel de la SA de IKE. La solución de problemas es más fácil cuando el par tiene la función de respondedor.

  • Obtenga las estadísticas de tráfico para verificar el flujo de tráfico en ambas direcciones.

  • Obtenga el número de asociaciones de seguridad IPsec creadas o en curso.

  • Obtenga el estado de cualquier negociación de fase 2 completada.

Confirmación del estado de fase 2 de IPsec

Propósito

Ver asociaciones de seguridad IPsec (fase 2).

Cuando se confirme la fase 1 de ICR, vea las asociaciones de seguridad IPsec (fase 2).

Acción

Desde el modo operativo, ingrese el show security ipsec security-associations comando.

Significado

El resultado indica lo siguiente:

  • Hay un par SA IPsec configurado disponible. El número de puerto 500 indica que se utiliza un puerto IKE estándar. De lo contrario, se trata de traducción de direcciones de red (TDR-T), 4500 o puerto de alto nivel aleatorio.

  • El índice de parámetros de seguridad (SPI) se utiliza para ambas direcciones. La duración o los límites de uso de la SA se expresan en segundos o en kilobytes. En la salida, 1676/unlim indica que la vida útil de la fase 2 está establecida para caducar en 1676 segundos y no hay un tamaño de vida útil especificado.

  • El número de ID muestra el valor de índice único para cada SA de IPsec.

  • Un guión (-) en la columna Mon indica que la supervisión de VPN no está habilitada para esta SA.

  • El sistema virtual (vsys) es cero, que es el valor predeterminado.

La vida útil de la fase 2 puede ser diferente de la vida útil de la fase 1 porque la fase 2 no depende de la fase 1 después de que la VPN esté activa.

Mostrar detalles de la asociación de seguridad IPsec

Propósito

Muestra los detalles individuales de SA de IPsec identificados por el número de índice.

Acción

Desde el modo operativo, ingrese el show security ipsec security-associations index 2 detail comando.

Significado

El resultado muestra la identidad local y la identidad remota.

Tenga en cuenta que una discordancia de ID de proxy puede provocar un error en la finalización de la fase 2. El ID de proxy se deriva de la política de túnel (para VPN basadas en políticas). La dirección local y la dirección remota se derivan de las entradas de la libreta de direcciones, y el servicio se deriva de la aplicación configurada para la política.

Si la fase 2 falla debido a una discordancia de ID de proxy, compruebe qué entradas de libreta de direcciones están configuradas en la política y asegúrese de que se envían las direcciones correctas. También asegúrese de que los puertos coincidan. Compruebe dos veces el servicio para asegurarse de que los puertos coincidan con los servidores remotos y locales.

Si se configuran varios objetos en una política de túnel para la dirección de origen, la dirección de destino o la aplicación, el ID de proxy resultante para ese parámetro se cambia a ceros.

Por ejemplo, suponga el siguiente escenario para una política de túnel:

  • Direcciones locales de 192.168.10.0/24 y 10.10.20.0/24

  • Dirección remota de 192.168.168.0/24

  • Aplicación como junos-http

El ID de proxy resultante es local 0.0.0.0/0, remoto 192.168.168.0/24, servicio 80.

Los ID de proxy resultantes pueden afectar a la interoperabilidad si el par remoto no está configurado para la segunda subred. Además, si utiliza la aplicación de un proveedor de terceros, es posible que tenga que introducir manualmente el ID de proxy para que coincida.

Si IPsec no se completa, compruebe el registro kmd o utilice el set traceoptions comando. Para obtener más información, consulte Solución de problemas de IKE, PKI e IPsec.

Comprobación de estadísticas sa de IPsec

Propósito

Compruebe las estadísticas y los errores de una SA IPsec.

Para propósitos de solución de problemas, compruebe los contadores de carga/encabezado de autenticación de seguridad de encapsulación (ESP/AH) para detectar errores con una SA IPsec determinada.

Acción

Desde el modo operativo, ingrese el show security ipsec statistics index 2 comando.

Significado

Un valor de error de cero en el resultado indica una condición normal.

Recomendamos ejecutar este comando varias veces para observar cualquier problema de pérdida de paquetes en una VPN. La salida de este comando también muestra las estadísticas de los contadores de paquetes cifrados y descifrados, los contadores de errores, entre otros.

Debe habilitar las opciones de seguimiento de flujo de seguridad para investigar qué paquetes ESP están experimentando errores y por qué. Para obtener más información, consulte Solución de problemas de IKE, PKI e IPsec.

Prueba del flujo de tráfico a través de la VPN

Propósito

Pruebe el flujo de tráfico a través de la VPN después de que la fase 1 y la fase 2 se hayan completado correctamente. Puede probar el flujo de tráfico mediante el ping comando. Puede hacer ping desde el host local hasta el host remoto. También puede iniciar pings desde el propio dispositivo de Juniper Networks.

En este ejemplo, se muestra cómo iniciar una solicitud de ping desde el dispositivo de Juniper Networks al host remoto. Tenga en cuenta que cuando se inician pings desde el dispositivo de Juniper Networks, se debe especificar la interfaz de origen para garantizar que se realice la búsqueda de ruta correcta y que se haga referencia a las zonas adecuadas en la búsqueda de política.

En este ejemplo, la interfaz ge-0/0/0.0 reside en la misma zona de seguridad que el host local y debe especificarse en la solicitud de ping para que la búsqueda de política pueda ser de confianza de zona a zona de desconfianza.

Acción

Desde el modo operativo, ingrese el ping 192.168.168.10 interface ge-0/0/0 count 5 comando.

Confirmación de la conectividad

Propósito

Confirme la conectividad entre un host remoto y un host local.

Acción

Desde el modo operativo, ingrese el ping 192.168.10.10 from ethernet0/6 comando.

Significado

Puede confirmar la conectividad de extremo a extremo mediante el ping comando del host remoto al host local. En este ejemplo, el comando se inicia desde el dispositivo SSG5.

La conectividad de extremo a extremo con errores puede indicar un problema con el enrutamiento, la política, el host final o el cifrado/descifrado de los paquetes ESP. Para comprobar las causas exactas del error:

  • Compruebe las estadísticas de IPsec para obtener más información sobre los errores como se describe en Comprobación de estadísticas sa de IPsec.

  • Confirme la conectividad del host final mediante el ping comando de un host en la misma subred que el host final. Si otros hosts pueden acceder al host final, puede asumir que el problema no está con el host final.

  • Habilite las opciones de seguimiento de flujo de seguridad para solucionar los problemas relacionados con el enrutamiento y las políticas.

Solución de problemas de IKE, PKI e IPsec

Solucione problemas de IKE, PKI e IPsec.

Pasos básicos de solución de problemas

Problema

Los pasos básicos de solución de problemas son los siguientes:

  1. Identificar y aislar el problema.

  2. Depuración del problema.

El enfoque común de iniciar la solución de problemas es con la capa más baja de las capas OSI y trabajar su camino hasta la pila de OSI para confirmar la capa en la que se produce el error.

Solución

Los pasos básicos para solucionar problemas de IKE, PKI e IPsec son los siguientes:

  • Confirme la conectividad física del vínculo de Internet a los niveles físicos y de vínculo de datos.

  • Confirme que el dispositivo Juniper Networks tiene conectividad al salto siguiente de Internet y conectividad al par IKE remoto.

  • Confirme la finalización de la fase 1 de ICR.

  • Confirme la finalización de la fase 2 de ICR si la finalización de la fase 1 de ICR es correcta.

  • Confirme el flujo de tráfico a través de la VPN (si la VPN está activa y activa).

Junos OS incluye la función de opciones de seguimiento. Con esta función, puede habilitar una marca de opción de seguimiento para escribir los datos desde la opción de seguimiento en un archivo de registro, que puede configurarse o configurarse manualmente y almacenarse en memoria flash. Estos registros de seguimiento se pueden conservar incluso después de un reinicio del sistema. Compruebe el almacenamiento flash disponible antes de implementar las opciones de seguimiento.

Puede habilitar la función de opciones de seguimiento en el modo de configuración y confirmar la configuración para usar la función de opciones de seguimiento. De manera similar para deshabilitar las opciones de seguimiento, debe desactivar las opciones de seguimiento en el modo de configuración y confirmar la configuración.

Comprobación del espacio libre en el disco en su dispositivo

Problema

Compruebe las estadísticas sobre el espacio libre en disco en los sistemas de archivos de su dispositivo.

Solución

Desde el modo operativo, ingrese el show system storage comando.

Representa /dev/ad0s1a la memoria flash incorporada y actualmente está al 35 por ciento de su capacidad.

Comprobación de los archivos de registro para comprobar diferentes escenarios y subir archivos de registro a un FTP

Problema

Vea los archivos de registro para comprobar los mensajes de depuración de IKE de seguridad, los debugs de flujo de seguridad y el estado de inicio de sesión en syslog.

Solución

Desde el modo operativo, ingrese los show log kmdcomandos , show log pkid, show log security-tracey show log messages .

Puede ver una lista de todos los registros en el directorio /var/log mediante el show log comando.

Los archivos de registro también se pueden cargar en un servidor FTP mediante el file copy comando.

Habilitación de opciones de seguimiento de ICR para ver mensajes en IKE

Problema

Para ver mensajes de éxito o error para IKE o IPsec, puede ver el registro kmd mediante el show log kmd comando. Dado que el registro de kmd muestra algunos mensajes generales, puede ser útil obtener detalles adicionales mediante la habilitación de opciones de seguimiento de IKE y PKI.

Generalmente, es recomendable solucionar problemas del par que tiene la función de respondedor. Debe obtener la salida de seguimiento del iniciador y del respondedor para comprender la causa de una falla.

Configure las opciones de rastreo de IKE.

Solución

Si no especifica nombres de archivo para el campo <filename>, todas las opciones de seguimiento de IKE se escriben en el registro kmd.

Debe especificar al menos una opción de marca para escribir datos de seguimiento en el registro. Por ejemplo:

  • file size : tamaño máximo de cada archivo de seguimiento, en bytes. Por ejemplo, un millón (1 000 000) puede generar un tamaño máximo de archivo de 1 MB.

  • files — Número máximo de archivos de seguimiento que se generarán y almacenarán en un dispositivo de memoria flash.

Debe confirmar la configuración para iniciar el seguimiento.

Habilitación de opciones de seguimiento de PKI para ver mensajes en IPsec

Problema

Habilite las opciones de seguimiento de PKI para identificar si una falla de IKE está relacionada con el certificado o con un problema que no es PKI.

Solución

Configurar opciones de seguimiento de IKE y PKI para solucionar problemas de configuración de IKE con certificados

Problema

Configure las opciones recomendadas para las opciones de seguimiento de IKE y PKI.

Las opciones de seguimiento de IKE y PKI utilizan los mismos parámetros, pero el nombre de archivo predeterminado para todos los seguimientos relacionados con PKI se encuentra en el registro pkid.

Solución

Análisis del mensaje de éxito de fase 1

Problema

Comprenda el resultado del show log kmd comando cuando las condiciones de fase 1 y fase 2 de IKE son correctas.

Solución

El resultado de la muestra indica lo siguiente:

  • 10.1.1.2— Dirección local.

  • ssg5.example.net — Par remoto (nombre de host con FQDN).

  • udp: 500—TDR-T no se negoció.

  • Phase 1 [responder] done— Estado de fase 1, junto con el rol (iniciador o respondedor).

  • Phase 2 [responder] done: estado de fase 1, junto con la información del ID de proxy.

    También puede confirmar el estado de SA de IPsec mediante los comandos de verificación mencionados en Confirmación del estado de fase 1 de ICR.

Análisis del mensaje de error de fase 1 (discordancia de propuesta)

Problema

Comprender el resultado del show log kmd comando, en el que la condición de fase 1 de IKE es una falla, ayuda a determinar la razón por la que la VPN no establece la fase 1.

Solución

El resultado de la muestra indica lo siguiente:

  • 10.1.1.2— Dirección local.

  • ssg5.example.net — Par remoto (nombre de host con FQDN).

  • udp: 500—TDR-T no se negoció.

  • Phase-1 [responder] failed with error (No proposal chosen)— Error de fase 1 debido a la discordancia de propuesta.

Para resolver este problema, asegúrese de que los parámetros de las propuestas de fase 1 de la puerta de enlace de IKE coincidan tanto en el respondedor como en el iniciador. Confirme también que existe una política de túnel para la VPN.

Análisis del mensaje de error de fase 1 (error de autenticación)

Problema

Comprenda el resultado del show log kmd comando cuando la condición de fase 1 de IKE es una falla. Esto ayuda a determinar la razón por la que la VPN no establece la fase 1.

Solución

El resultado de la muestra indica lo siguiente:

  • 10.1.1.2— Dirección local.

  • 10.2.2.2—Par remoto

  • Phase 1 [responder] failed with error (Authentication failed)— Falla de fase 1 debido a que el respondedor no reconoce la solicitud entrante que se origina desde un par de puerta de enlace válido. En el caso de IKE con certificados PKI, esta falla suele indicar que se especificó o se especificó un tipo de ID de IKE incorrecto.

Para resolver este problema, confirme que el tipo de ID de IKE del par correcto se especifica en el par local según lo siguiente:

  • Cómo se generó el certificado de par remoto

  • Nombre alternativo del asunto o información de DN en el certificado de par remoto recibido

Análisis del mensaje de error de fase 1 (error de tiempo de espera)

Problema

Comprenda el resultado del show log kmd comando cuando la condición de fase 1 de IKE es una falla.

Solución

El resultado de la muestra indica lo siguiente:

  • 10.1.1.2— Dirección Llocal.

  • 10.2.2.2—Par remoto.

  • Phase 1 [responder] failed with error(Timeout)— Falla de fase 1.

    Este error indica que el paquete IKE se pierde enroute al par remoto o que hay un retraso o ninguna respuesta del par remoto.

Dado que este error de tiempo de espera es el resultado de esperar una respuesta del demonio de PKI, debe revisar el resultado de las opciones de seguimiento de PKI para ver si hay un problema con la PKI.

Análisis del mensaje de error de fase 2

Problema

Comprenda el resultado del show log kmd comando cuando la condición de fase 2 de IKE es una falla.

Solución

El resultado de la muestra indica lo siguiente:

  • 10.1.1.2— Dirección local.

  • ssg5.example.net — Par remoto (nombre de host tipo ID IKE con FQDN).

  • Phase 1 [responder] done— Éxito de fase 1.

  • Failed to match the peer proxy ids: se reciben los ID de proxy incorrectos. En el ejemplo anterior, los dos ID de proxy recibidos son 192.168.168.0/24 (remoto) y 10.10.20.0/24 (local) (para service=any). Según la configuración dada en este ejemplo, la dirección local esperada es 192.168.10.0/24. Esto muestra que hay una discordancia de configuraciones en el par local, lo que da como resultado la falla de la coincidencia del ID de proxy.

    Para resolver este problema, corrija la entrada de la libreta de direcciones o configure el ID de proxy en cualquiera de los pares para que coincida con el otro par.

    El resultado también indica que el motivo del error es No proposal chosen. Sin embargo, en este caso también verá el mensaje Failed to match the peer proxy ids.

Análisis del mensaje de error de fase 2

Problema

Comprenda el resultado del show log kmd comando cuando la condición de fase 2 de IKE es una falla.

Solución

El resultado de la muestra indica lo siguiente:

  • 10.1.1.2 — Dirección local.

  • fqdn(udp:500,[0..15]=ssg5.example.net—Par remoto.

  • Phase 1 [responder] done— Éxito de fase 1.

  • Error = No proposal chosen—No se eligió ninguna propuesta durante la fase 2. Este problema se debe a la discordancia de propuesta entre los dos pares.

    Para resolver este problema, confirme que las propuestas de fase 2 coincidan en ambos pares.

Solución de problemas comunes relacionados con IKE y PKI

Problema

Solucione problemas comunes relacionados con IKE y PKI.

Habilitar la función de opciones de seguimiento le ayuda a recopilar más información sobre los problemas de depuración de la que se puede obtener de las entradas de registro normales. Puede utilizar el registro de opciones de seguimiento para comprender las razones de los errores de IKE o PKI.

Solución

Métodos para solucionar los problemas relacionados con IKE y PKI:

  • Asegúrese de que la configuración del reloj, la fecha, la zona horaria y el ahorro de luz natural sean correctas. Utilice NTP para mantener el reloj preciso.

  • Asegúrese de usar un código de país de dos letras en el campo "C=" (país) de la DN.

    Por ejemplo: usar "EE. UU." y no "EE. UU." o "Estados Unidos". Algunas CA requieren que se rellene el campo de país de la DN, lo que le permite introducir el valor de código de país solo con un valor de dos letras.

  • Asegúrese de que si un certificado par usa varios campos OU=o CN=, está utilizando el nombre distinguido con el método contenedor (la secuencia se debe mantener y distingue entre mayúsculas y minúsculas).

  • Si el certificado aún no es válido, compruebe el reloj del sistema y, si es necesario, ajuste la zona horaria del sistema o simplemente agregue un día en el reloj para una prueba rápida.

  • Asegúrese de que se configuran un tipo y un valor de ID de IKE coincidentes.

  • La PKI puede fallar debido a un error de comprobación de revocación. Para confirmar esto, desactive temporalmente la comprobación de revocación y vea si la fase 1 de ICR puede completarse.

    Para deshabilitar la comprobación de revocación, utilice el siguiente comando en el modo de configuración:

    set security pki ca-profile <ca-profile> revocation-check disable