Comment résoudre le problème de connexion entre Log Collector

• Pour dépanner et résoudre les problèmes liés à la connectivité et à la synchronisation de Panorama et du collecteur de journaux.
• En suivant les instructions, les utilisateurs devraient être en mesure de diagnostiquer et de corriger les problèmes courants dans leurs configurations Panorama et Log Collector.
• Certains des problèmes évoqués sont généralement observés lors de la configuration.

• • Les journaux du pare-feu ne sont pas envoyés à Panorama/Log Collector.
  • Log Collector est déconnecté de Panorama.
  • Certains journaux sont manquants ou retardés lorsqu'une requête est lancée.

• N'importe quel panorama
• Collecteurs de bûches
• PAN-OS 10.0 et supérieur.

1. Vérifiez que les autorisations appropriées pour que les Panoramas (mode Panorama et/ou mode Collecteur de journaux) puissent communiquer sont en place.
   1. Utilisez le dépannage de la connectivité Panorama .
   2. Assurez-vous que le port TCP 28270 est ouvert entre les appareils si un pare-feu se trouve au milieu.
   3. Si la version PAN-OS 11.1 ou supérieure est utilisée, assurez-vous que le port 28 et les ports 9300-9302 sont ouverts. La communication inter-LC utilise ces ports.
2. Vérifiez toute connexion instable entre les appareils, exécutez la commande ci-dessous plusieurs fois pour voir toute déconnexion/reconnexion fréquente.

> show netstat numeric yes | match 28270
Proto Recv-Q Send-Q Local Address           Foreign Address         State   

3. Si la communication entre les panoramas/collecteurs de journaux cesse de fonctionner :
   1. Vérifiez le ms.log pour voir les messages d'erreur en utilisant la commande > less mp-log ms.log

01:20:06.757 -0700 COMM: connection established. sock=29 remote ip=10.253.0.106 port=3978 local port=60640
01:20:06.757 -0700 cms agent: Pre. send buffer limit=46080. s=29
01:20:06.757 -0700 cms agent: Post. send buffer limit=425984. s=29
01:20:06.757 -0700 Error: cs_load_certs_ex(cs_common.c:655): keyfile not exists
01:20:06.757 -0700 Error: pan_cmsa_tcp_channel_setup(src_panos/cms_agent.c:883): cms agent: cs_load_certs_ex failed
01:20:06.757 -0700 cmsa: client will use default context
01:20:06.757 -0700 Warning: pan_cmsa_tcp_channel_setup(src_panos/cms_agent.c:988): client will not use SNI

09:13:27.723 -0800 Error: sc3_ca_exists(sc3_certs.c:221): SC3: Failed to get the current CA name. 
09:13:27.723 -0800 Warning: sc3_init_sc3(sc3_utils.c:351): SC3: Failed to get the Current CC name

2. Sur le collecteur de journaux dédié, les problèmes sc3 observés dans le fichier ms.log peuvent être résolus en réinitialisant la connexion. Reportez-vous à Comment réinitialiser la communication sécurisée entre le pare-feu et panorama .
3. N'exécutez pas la commande sc3 reset sur les pare-feu de gestion Panorama ou en mode mixte. Consultez le support pour résoudre le problème. L'exécution de la commande entraînera la déconnexion de tous les pare-feu de Panorama.

4. Une mise à niveau a-t-elle été effectuée sur l'un des appareils du groupe de collecteurs? Si oui, assurez-vous que tous les appareils exécutent la même version au sein du groupe de collecteurs.
5. Redémarrez le serveur de gestion sur les deux appareils pour réinitialiser la connexion.

debug software restart process management-server

6. Vérifiez que les collecteurs de journaux sont tous sains du point de vue de Panorama, y ​​compris le collecteur de journaux local de Panorama.
   1. Depuis l'interface graphique de Panorama : Panorama > Géré > Collecteurs
   2. En fonction du problème rencontré, utilisez les bases de connaissances suivantes en conséquence.
      1. Log-Collector affichant le état « synchroniser» et « déconnecté »
      2. Collecteur de journaux indiquant une incompatibilité de version de Ring
      3. Le collecteur de journaux affiche « Désynchronisation » en raison d'une « incompatibilité IP pour interface de gestion »
7. Vérifiez que l'ElasticSearch du collecteur de journaux est sain, y compris le collecteur de journaux local du Panorama.
   1. Vous trouverez ci-dessous un exemple d’ElasticSearch non sain.

admin@Log_Collector> debug elasticsearch es-state option health 

epoch      timestamp cluster         status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1683877500 07:45:00  __pan_cluster__ red             1         1    461 461    0    0      115             0                  -     80.03472222222221

2. Redémarrez ElasticSearch à l'aide de la commande ci-dessous et revérifiez l'état de santé. Notez que si plusieurs collecteurs de journaux sont configurés, il faut identifier le collecteur de journaux qui rencontre des problèmes, puis redémarrer Elasticsearch sur le collecteur de journaux défaillant. Si vous avez besoin d'aide, contactez le support technique .

admin@Log_Collector> debug elasticsearch es-restart option all
Elasticsearch was restarted with option all by user admin

3. Vous trouverez ci-dessous un exemple d’ElasticSearch sain.

admin@Log_Collector> debug elasticsearch es-state option health 

epoch      timestamp cluster         status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1683877131 07:38:51  __pan_cluster__ green           1         1     32  32    0    0        0             0                  -                100.0%

8. Si les journaux sont manquants ou retardés, reportez-vous aux retards de transfert des journaux ou aux journaux manquants en raison d'une latence élevée entre les collecteurs de journaux d'un groupe de collecteurs .