Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit les tunnels du client Cisco AnyConnect Secure Mobility, le comportement de reconnexion et la détection d'homologues morts (DPD), ainsi que le minuteur d'inactivité.
Deux méthodes sont utilisées pour connecter une session AnyConnect :
En fonction de la façon dont vous vous connectez, vous créez trois tunnels (sessions) différents sur le dispositif de sécurité adaptatif Cisco (ASA), chacun ayant un objectif spécifique :
Remarque : AnyConnect-Parent représente la session lorsque le client n'est pas connecté activement. En effet, il fonctionne de la même manière qu'un cookie, en ce sens qu'il s'agit d'une entrée de base de données sur l'ASA qui correspond à la connexion d'un client particulier. Si le client est en veille/veille prolongée, les tunnels (protocoles IPsec/IKE (Internet Key Exchange)/TLS (Transport Layer Security)/DTLS (Datagram Transport Layer Security)) sont désactivés, mais le parent reste inactif jusqu'à ce que le minuteur d'inactivité ou le temps de connexion maximal prenne effet. Cela permet à l'utilisateur de se reconnecter sans réauthentifier.
Voici un exemple de sortie des deux méthodes de connexion.
AnyConnect connecté via le lancement Web :
ASA5520-C(config)# show vpn-sessiondb detail anyconnect
Session Type: AnyConnect Detailed
Username : walter Index : 1435
Assigned IP : 192.168.1.4 Public IP : 172.16.250.17
Protocol : Clientless SSL-Tunnel DTLS-Tunnel
License : AnyConnect Premium
Encryption : Clientless: (1)RC4 SSL-Tunnel: (1)RC4 DTLS-Tunnel: (1)AES128
Hashing : Clientless: (1)SHA1 SSL-Tunnel: (1)SHA1 DTLS-Tunnel: (1)SHA1
Bytes Tx : 335765 Bytes Rx : 31508
Pkts Tx : 214 Pkts Rx : 18
Pkts Tx Drop : 0 Pkts Rx Drop : 0
Group Policy : My-Network Tunnel Group : My-Network
Login Time : 22:13:37 UTC Fri Nov 30 2012
Duration : 0h:00m:34s
Inactivity : 0h:00m:00s
NAC Result : Unknown
VLAN Mapping : N/A VLAN : none
Clientless Tunnels: 1
SSL-Tunnel Tunnels: 1
DTLS-Tunnel Tunnels: 1
Clientless:
Tunnel ID : 1435.1
Public IP : 172.16.250.17
Encryption : RC4 Hashing : SHA1
Encapsulation: TLSv1.0 TCP Dst Port : 443
Auth Mode : userPassword
Idle Time Out: 2 Minutes Idle TO Left : 1 Minutes
Client Type : Web Browser
Client Ver : Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0
Bytes Tx : 329671 Bytes Rx : 31508
SSL-Tunnel:
Tunnel ID : 1435.2
Assigned IP : 192.168.1.4 Public IP : 172.16.250.17
Encryption : RC4 Hashing : SHA1
Encapsulation: TLSv1.0 TCP Src Port : 1241
TCP Dst Port : 443 Auth Mode : userPassword
Idle Time Out: 2 Minutes Idle TO Left : 1 Minutes
Client Type : SSL VPN Client
Client Ver : Cisco AnyConnect VPN Agent for Windows 3.1.01065
Bytes Tx : 6094 Bytes Rx : 0
Pkts Tx : 4 Pkts Rx : 0
Pkts Tx Drop : 0 Pkts Rx Drop : 0
DTLS-Tunnel:
Tunnel ID : 1435.3
Assigned IP : 192.168.1.4 Public IP : 172.16.250.17
Encryption : AES128 Hashing : SHA1
Encapsulation: DTLSv1.0 Compression : LZS
UDP Src Port : 1250 UDP Dst Port : 443
Auth Mode : userPassword
Idle Time Out: 2 Minutes Idle TO Left : 1 Minutes
Client Type : DTLS VPN Client
Client Ver : Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0
Bytes Tx : 0 Bytes Rx : 0
Pkts Tx : 0 Pkts Rx : 0
Pkts Tx Drop : 0 Pkts Rx Drop : 0
AnyConnect connecté via l'application autonome :
ASA5520-C(config)# show vpn-sessiondb detail anyconnect
Session Type: AnyConnect Detailed
Username : walter Index : 1436
Assigned IP : 192.168.1.4 Public IP : 172.16.250.17
Protocol : AnyConnect-Parent SSL-Tunnel DTLS-Tunnel
License : AnyConnect Premium
Encryption : AnyConnect-Parent: (1)none SSL-Tunnel: (1)RC4 DTLS-Tunnel: (1)AES128
Hashing : AnyConnect-Parent: (1)none SSL-Tunnel: (1)SHA1 DTLS-Tunnel: (1)SHA1
Bytes Tx : 12244 Bytes Rx : 777
Pkts Tx : 8 Pkts Rx : 1
Pkts Tx Drop : 0 Pkts Rx Drop : 0
Group Policy : My-Network Tunnel Group : My-Network
Login Time : 22:15:24 UTC Fri Nov 30 2012
Duration : 0h:00m:11s
Inactivity : 0h:00m:00s
NAC Result : Unknown
VLAN Mapping : N/A VLAN : none
AnyConnect-Parent Tunnels: 1
SSL-Tunnel Tunnels: 1
DTLS-Tunnel Tunnels: 1
AnyConnect-Parent:
Tunnel ID : 1436.1
Public IP : 172.16.250.17
Encryption : none Hashing : none
TCP Src Port : 1269 TCP Dst Port : 443
Auth Mode : userPassword
Idle Time Out: 2 Minutes Idle TO Left : 1 Minutes
Client Type : AnyConnect
Client Ver : 3.1.01065
Bytes Tx : 6122 Bytes Rx : 777
Pkts Tx : 4 Pkts Rx : 1
Pkts Tx Drop : 0 Pkts Rx Drop : 0
SSL-Tunnel:
Tunnel ID : 1436.2
Assigned IP : 192.168.1.4 Public IP : 172.16.250.17
Encryption : RC4 Hashing : SHA1
Encapsulation: TLSv1.0 TCP Src Port : 1272
TCP Dst Port : 443 Auth Mode : userPassword
Idle Time Out: 2 Minutes Idle TO Left : 1 Minutes
Client Type : SSL VPN Client
Client Ver : Cisco AnyConnect VPN Agent for Windows 3.1.01065
Bytes Tx : 6122 Bytes Rx : 0
Pkts Tx : 4 Pkts Rx : 0
Pkts Tx Drop : 0 Pkts Rx Drop : 0
DTLS-Tunnel:
Tunnel ID : 1436.3
Assigned IP : 192.168.1.4 Public IP : 172.16.250.17
Encryption : AES128 Hashing : SHA1
Encapsulation: DTLSv1.0 Compression : LZS
UDP Src Port : 1280 UDP Dst Port : 443
Auth Mode : userPassword
Idle Time Out: 2 Minutes Idle TO Left : 1 Minutes
Client Type : DTLS VPN Client
Client Ver : 3.1.01065
Bytes Tx : 0 Bytes Rx : 0
Pkts Tx : 0 Pkts Rx : 0
Pkts Tx Drop : 0 Pkts Rx Drop : 0
La session est considérée comme inactive (et le compteur commence à augmenter) uniquement lorsque le tunnel SSL n'existe plus dans la session. Ainsi, chaque session est horodatée avec l'heure d'abandon du tunnel SSL.
ASA5520-C# show vpn-sessiondb detail anyconnect
Session Type: AnyConnect Detailed
Username : walter Index : 1336
Public IP : 172.16.250.17
Protocol : AnyConnect-Parent <- Here just the AnyConnect-Parent is active
but not SSL-Tunnel
License : AnyConnect Premium
Encryption : AnyConnect-Parent: (1)none
Hashing : AnyConnect-Parent: (1)none
Bytes Tx : 12917 Bytes Rx : 1187
Pkts Tx : 14 Pkts Rx : 7
Pkts Tx Drop : 0 Pkts Rx Drop : 0
Group Policy : My-Network Tunnel Group : My-Network
Login Time : 17:42:56 UTC Sat Nov 17 2012
Duration : 0h:09m:14s
Inactivity : 0h:01m:06s <- So the session is considered Inactive
NAC Result : Unknown
VLAN Mapping : N/A VLAN : none
Un tunnel SSL peut être déconnecté de deux façons :
anyconnect dpd-interval
commande sous les attributs WebVPN dans les paramètres de stratégie de groupe. Par défaut, le DPD est activé et défini sur 30 secondes pour l'ASA (passerelle) et le client.Attention : soyez conscient du bogue Cisco ayant l'ID CSCts6926 - DPD ne parvient pas à terminer le tunnel DTLS après la perte de la connexion du client.
Comme expliqué précédemment, le DPD ne ferme pas la session AnyConnect elle-même. Il tue simplement le tunnel dans cette session afin que le client puisse rétablir le tunnel. Si le client ne peut pas rétablir le tunnel, la session reste active jusqu'à ce que le minuteur d'inactivité expire sur l'ASA. Comme les DPD sont activés par défaut, les clients peuvent souvent être déconnectés en raison de flux se fermant dans une direction avec des périphériques NAT (Network Address Translation), pare-feu et proxy. L'activation de keepalives à de faibles intervalles, par exemple 20 secondes, permet d'éviter cela.
Les Keepalive sont activés sous les attributs WebVPN d'une stratégie de groupe particulière avec la anyconnect ssl keepalive
commande. Par défaut, les minuteurs sont définis sur 20 secondes.
AnyConnect tente de se reconnecter si la connexion est interrompue. Ce paramètre n'est pas configurable automatiquement. Tant que la session VPN sur l'ASA est toujours valide et si AnyConnect peut rétablir la connexion physique, la session VPN est reprise.
La fonction de reconnexion se poursuit jusqu'à l'expiration du délai d'expiration de la session ou du délai de déconnexion, qui correspond en fait au délai d'inactivité (ou 30 minutes si aucun délai d'expiration n'est configuré). Une fois que ceux-ci expirent, le client ne peut pas continuer car les sessions VPN ont déjà été abandonnées sur l'ASA. Le client continue tant qu'il pense que l'ASA a toujours la session VPN.
AnyConnect se reconnecte quel que soit le changement d’interface réseau. Peu importe si l'adresse IP de la carte réseau change ou si la connectivité passe d'une carte réseau à une autre (sans fil à câblé ou vice versa).
Lorsque vous envisagez le processus de reconnexion pour AnyConnect, vous devez vous souvenir de trois niveaux de sessions. En outre, le comportement de reconnexion de chacune de ces sessions est faiblement couplé, en ce que l'une quelconque d'entre elles peut être rétablie sans dépendre des éléments de session de la couche précédente :
Conseil : ces versions ASA et les versions ultérieures contiennent un jeton de session cryptographique plus puissant : 9.1(3) et 8.4(7.1)
Un temporisateur de déconnexion est démarré dès que la connexion réseau est interrompue. Le client AnyConnect continue à essayer de se reconnecter tant que ce minuteur n’expire pas. Le délai de déconnexion est défini sur le paramètre le plus bas, soit le délai d'inactivité de la stratégie de groupe, soit le délai de connexion maximal.
La valeur de ce minuteur apparaît dans l’Observateur d’événements pour la session AnyConnect de la négociation :
Dans cet exemple, la session se déconnecte au bout de deux minutes (120 secondes), ce qui peut être vérifié dans l'historique des messages d'AnyConnect :
Conseil : pour que l'ASA réponde à un client qui tente de se reconnecter, la session Parent-Tunnel doit toujours exister dans la base de données ASA. En cas de basculement, les DPD doivent également être activés pour que le comportement de reconnexion fonctionne.
Comme le montrent les messages précédents, la reconnexion a échoué. Cependant, si la reconnexion réussit, voici ce qui se passe :
Attention : prenez connaissance du bogue Cisco ayant l'ID CSCtg3110. La base de données de session VPN ne met pas à jour l'adresse IP publique dans la base de données de session ASA lorsque AnyConnect se reconnecte.
Dans cette situation où les tentatives de reconnexion échouent, vous rencontrez ce message :
Remarque : cette demande d'amélioration a été déposée afin de rendre ceci plus granulaire : ID de bogue Cisco CSCsl52873 - ASA n'a pas de délai d'attente de déconnexion configurable pour AnyConnect.
Une fonction d’itinérance permet à AnyConnect de se reconnecter après la mise en veille d’un PC. Le client continue d'essayer jusqu'à ce que les délais d'inactivité ou de session expirent et qu'il ne désactive pas immédiatement le tunnel lorsque le système passe en mode veille prolongée/veille. Pour les utilisateurs qui ne veulent pas de cette fonctionnalité, définissez le délai d'expiration de la session sur une valeur faible afin d'empêcher les reconnexions de mise en veille/reprise.
Remarque : après la correction du bogue Cisco ayant l'ID CSCso17627 (Version 2.3(111)+), un bouton de contrôle a été introduit afin de désactiver cette fonction de reconnexion lors de la reprise.
Le comportement de reconnexion automatique pour AnyConnect peut être contrôlé via le profil XML AnyConnect avec ce paramètre :
<AutoReconnect UserControllable="true">true
<AutoReconnectBehavior>ReconnectAfterResume</AutoReconnectBehavior>
</AutoReconnect>
Avec cette modification, AnyConnect tente de se reconnecter lorsque l'ordinateur est remis en veille. La préférence AutoReconnectBehavior prend par défaut la valeur DisconnectOnSuspend. Ce comportement de routage est différent de celui d'AnyConnect client version 2,2. Pour la reconnexion après la reprise, l'administrateur réseau doit soit définir ReconnectAfterResume dans le profil, soit rendre les préférences ReconnexionAutomatique et ComportementReconnexionAutomatique contrôlables par l'utilisateur dans le profil pour permettre aux utilisateurs de le définir.
R. Du point de vue du client, les DPD ne démontent un tunnel que pendant l’étape d’établissement du tunnel. Si le client rencontre trois nouvelles tentatives (envoie quatre paquets) au cours de l'étape d'établissement du tunnel et ne reçoit pas de réponse du serveur VPN principal, il revient à l'utilisation de l'un des serveurs de secours s'il est configuré. Cependant, une fois le tunnel établi, les DPD manqués n'ont aucun impact sur le tunnel du point de vue du client. L'impact réel des DPD est sur le serveur VPN comme expliqué dans la section DPD et Minuteurs d'inactivité.
R. Oui, IKEv2 a un nombre fixe de tentatives - six tentatives/sept paquets.
R. En plus d'être un mappage sur l'ASA, le tunnel parent est utilisé afin de pousser les mises à niveau d'image AnyConnect de l'ASA vers le client, parce que le client n'est pas activement connecté pendant le processus de mise à niveau.
R. Vous pouvez filtrer les sessions inactives à l'aide de la commande show vpn-sessiondb anyconnect filter inactive. Cependant, il n'y a pas de commande pour fermer uniquement les sessions inactives. Au lieu de cela, vous devez fermer des sessions spécifiques ou toutes les sessions par utilisateur (index - nom), protocole ou groupe de tunnels. Une demande d'amélioration, ID de bogue Cisco CSCuh5707 , a été déposée afin d'ajouter l'option pour se déconnecter uniquement des sessions inactives.
R. Le minuteur Idle TO Left de la session AnyConnect-Parent est réinitialisé après l’arrêt du tunnel SSL ou du tunnel DTLS. Cela permet au délai d'inactivité d'agir comme un délai d'inactivité déconnecté. Cela devient effectivement le temps autorisé pour le client à se reconnecter. Si le client ne se reconnecte pas dans le temporisateur, le tunnel parent est terminé.
R. La tête de réseau ne connaît pas l'état du client. Dans ce cas, l'ASA attend que le client se reconnecte jusqu'à ce que la session expire au moment de l'inactivité. DPD ne tue pas une session AnyConnect ; il tue simplement le tunnel (au sein de cette session) afin que le client puisse rétablir le tunnel. Si le client ne rétablit pas de tunnel, la session reste active jusqu'à l'expiration du minuteur d'inactivité.
Si le problème concerne les sessions qui sont utilisées, définissez les connexions simultanées sur une valeur faible, par exemple 1. Avec ce paramètre, les utilisateurs qui ont une session dans la base de données de session voient leur session précédente supprimée lorsqu'ils se reconnectent.
R. Au départ, lorsque la session est établie, les trois tunnels (Parent, SSL et DTLS) sont répliqués vers l'unité en veille. Une fois que l’ASA a basculé, les sessions DTLS et TLS sont rétablies car elles ne sont pas synchronisées avec l’unité en veille, mais toutes les données qui circulent dans les tunnels doivent fonctionner sans interruption une fois la session AnyConnect rétablie.
Les sessions SSL/DTLS n'ayant pas d'état, l'état et le numéro d'ordre SSL ne sont pas conservés et peuvent être très contraignants. Par conséquent, ces sessions doivent être rétablies à partir de zéro, ce qui est fait avec la session Parent et le jeton de session.
Conseil : en cas de basculement, les sessions client VPN SSL ne sont pas transférées vers le périphérique de secours si les keepalives sont désactivés.
R. Lorsque les protocoles ont été élaborés, deux délais d'attente différents ont été prévus pour :
Le délai d'attente déconnecté n'a jamais été implémenté sur l'ASA. Au lieu de cela, l'ASA envoie au client la valeur de délai d'inactivité pour les délais d'inactivité et de déconnexion.
Le client n'utilise pas le délai d'inactivité, car l'ASA gère le délai d'inactivité. Le client utilise la valeur du délai d'attente déconnecté, qui est la même que la valeur du délai d'attente inactif, afin de savoir quand abandonner les tentatives de reconnexion puisque l'ASA a abandonné la session.
Alors qu'il n'est pas connecté activement au client, l'ASA expire la session via le délai d'inactivité. La principale raison de ne pas mettre en oeuvre le délai d'attente déconnecté sur l'ASA était d'éviter l'ajout d'un autre temporisateur pour chaque session VPN et l'augmentation de la surcharge sur l'ASA (bien que le même temporisateur puisse être utilisé dans les deux instances, juste avec des valeurs de délai d'attente différentes, puisque les deux cas sont mutuellement exclusifs).
La seule valeur ajoutée avec le délai d'attente déconnecté est de permettre à un administrateur de spécifier un délai d'attente différent lorsque le client n'est pas connecté de manière active par rapport à inactif. Comme indiqué précédemment, l'ID de bogue Cisco CSCsl52873 a été enregistré pour cela.
R. Par défaut, AnyConnect tente de rétablir une connexion VPN lorsque vous perdez la connectivité. Il ne tente pas de rétablir une connexion VPN après la reprise d'un système par défaut. Référez-vous à Comportement du client AnyConnect en cas de suspension du système pour plus de détails.
R. Une reconnexion au niveau du tunnel n'effectue aucune des deux opérations. Il s’agit d’une reconnexion sur SSL ou DTLS uniquement. Ils passent environ 30 secondes avant d'abandonner. Si DTLS échoue, il est simplement abandonné. Si SSL échoue, il provoque une reconnexion au niveau de la session. Une reconnexion au niveau de la session rétablit complètement le routage. Si l'adresse du client attribuée lors de la reconnexion, ou tout autre paramètre de configuration ayant un impact sur l'adaptateur virtuel, n'a pas été modifié, l'adaptateur virtuel n'est pas désactivé. Bien qu'il soit peu probable que les paramètres de configuration reçus de l'ASA soient modifiés, il est possible qu'une modification de l'interface physique utilisée pour la connexion VPN (par exemple, si vous vous déconnectez et passez d'une connexion filaire à une connexion Wi-Fi) entraîne une valeur d'unité de transmission maximale (MTU) différente pour la connexion VPN. La valeur MTU a un impact sur la valeur VA, et une modification de cette valeur entraîne la désactivation de la valeur VA, puis sa réactivation.
R. AnyConnect n’offre aucune fonction magique supplémentaire permettant la persistance des sessions pour les applications. Mais la connectivité VPN est restaurée automatiquement, peu de temps après la reprise de la connectivité réseau à la passerelle sécurisée, à condition que les délais d'inactivité et de session configurés sur l'ASA n'aient pas expiré. Et contrairement au client IPsec, la reconnexion automatique aboutit à la même adresse IP de client. Tandis qu'AnyConnect tente de se reconnecter, l'adaptateur virtuel AnyConnect reste activé et à l'état connecté, de sorte que l'adresse IP du client reste présente et activée sur le PC client tout le temps, ce qui donne une persistance de l'adresse IP du client. Cependant, les applications PC clientes perçoivent toujours la perte de connectivité à leurs serveurs sur le réseau d'entreprise si la restauration de la connectivité VPN prend trop de temps.
R. Cette fonctionnalité fonctionne sur Mac et Linux. Il y a eu des problèmes avec Mac et Linux, mais des améliorations récentes ont été apportées, en particulier pour Mac. Linux nécessite toujours une prise en charge supplémentaire (ID de bogue Cisco CSCsr16670, ID de bogue Cisco CSCsm69213), mais la fonctionnalité de base est également présente. En ce qui concerne Linux, AnyConnect ne reconnaît pas qu’une interruption/reprise (veille/réveil) s’est produite. Cela a essentiellement deux impacts :
R. AnyConnect n’est pas lié à une interface physique particulière pendant toute la durée de vie de la connexion VPN. Si l’interface physique utilisée pour la connexion VPN est perdue ou si les tentatives de reconnexion dépassent un certain seuil d’échec, AnyConnect n’utilise plus cette interface et tente d’atteindre la passerelle sécurisée avec toutes les interfaces disponibles jusqu’à l’expiration des minuteurs d’inactivité ou de session. Notez qu'une modification de l'interface physique peut entraîner une valeur MTU différente pour l'appliance virtuelle, ce qui entraîne la désactivation et la réactivation de l'appliance virtuelle, mais toujours avec la même adresse IP client.
En cas d’interruption du réseau (interface désactivée, réseaux modifiés, interfaces modifiées), AnyConnect tente de se reconnecter ; aucune nouvelle authentification n’est nécessaire lors de la reconnexion. Ceci s'applique même à un commutateur d'interfaces physiques :
Exemple :
1. wireless off, wired on: AC connection established
2. disconnect wired physically, turn wired on: AC re-established connection in
30 seconds
3. connect wired, turn off wireless: AC re-established connection in 30 secs
R. Dans un CV, vous soumettez à nouveau le jeton authentifié qui reste pendant toute la durée de la session, puis la session est rétablie.
R. Cette opération n'est effectuée que lors de la connexion initiale.
R. Non, ils s'exécutent uniquement sur la connexion initiale. Quelque chose comme cela serait prévu pour la future fonction d'évaluation périodique de la posture.
R : Oui, c'est correct puisque vous ne rétablissez pas le nom d'hôte via DNS pour rétablir une session en cours.
Révision | Date de publication | Commentaires |
---|---|---|
3.0 |
22-Dec-2023 |
Mise à jour de texte de remplacement, traduction automatique et formatage. |
2.0 |
22-Nov-2022 |
Titre et introduction mis à jour, traduction automatique, exigences de style, géronds et formatage. |
1.0 |
13-Aug-2021 |
Première publication |