So beheben Sie Verbindungsprobleme zwischen Log Collector

• Zur Fehlersuche und Lösung von Problemen im Zusammenhang mit der Konnektivität und Synchronisierung von Panorama und dem Protokollsammler.
• Durch Befolgen der Anweisungen sollten Benutzer in der Lage sein, häufige Probleme in ihren Panorama- und Log Collector-Setups zu diagnostizieren und zu beheben.
• Einige der besprochenen Probleme, die im Allgemeinen beim Einrichtung auftreten.

• • Firewall-Protokolle werden nicht an Panorama/Log Collector gesendet.
  • Die Verbindung des Log Collectors zu Panorama ist getrennt.
  • Beim Starten einer Abfrage fehlen einige Protokolle oder werden verzögert gesendet.

• Jedes Panorama
• Holzsammler
• PAN-OS 10.0 und höher.

1. Überprüfen Sie, ob die entsprechenden Berechtigungen zur Kommunikation der Panoramen (Panorama-Modus und/oder Log-Kollektor-Modus) vorhanden sind.
   1. Verwenden Sie die Fehlerbehebung bei Panorama-Konnektivität .
   2. Stellen Sie sicher, dass der TCP Port 28270 zwischen den Geräten geöffnet ist, wenn sich eine Firewall dazwischen befindet.
   3. Wenn PAN-OS Version 11.1 oder höher verwendet wird, stellen Sie sicher, dass Port 28 und Ports 9300-9302 geöffnet sind. Die Inter-LC-Kommunikation verwendet diese Ports.
2. Überprüfen Sie, ob die Verbindung zwischen den Geräten instabil ist. Führen Sie den folgenden Befehl einige Male aus, um zu erkennen, ob die Verbindung häufig getrennt bzw. wiederhergestellt wird.

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

3. Wenn die Kommunikation zwischen Panoramas/Log Collectors nicht mehr funktioniert:
   1. Überprüfen Sie die Datei ms.log, um die Fehlermeldungen mit dem Befehl > less mp-log ms.log anzuzeigen.

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. Auf dem dedizierten Protokollsammler können die im ms.log angezeigten SC3-Probleme durch Zurücksetzen der Verbindung behoben werden. Siehe So setzen Sie die sichere Kommunikation zwischen Firewall und Panorama zurück .
3. Führen Sie den Befehl sc3 reset nicht auf Panorama-Firewalls oder im gemischten Modus aus . Wenden Sie sich zur Lösung an den Support . Wenn Sie den Befehl ausführen, werden alle Firewalls von Panorama getrennt.

4. Wurde eines der Geräte in der Collector Group aktualisiert? Wenn ja, stellen Sie sicher, dass auf allen Geräten innerhalb der Collector Group die gleiche Version ausgeführt wird.
5. Starten Sie den Verwaltungsserver auf beiden Geräten neu, um die Verbindung zurückzusetzen.

debug software restart process management-server

6. Überprüfen Sie, ob alle Log Collector aus Panorama-Sicht fehlerfrei sind, einschließlich des lokalen Log Collector von Panorama.
   1. Über die Panorama-Benutzeroberfläche: Panorama > Verwaltet > Sammler
   2. Verwenden Sie je nach angezeigtem Problem die folgenden KBs.
      1. Log-Collector zeigt den Status „nicht synchronisieren“ und „getrennt“ an
      2. Log Collector zeigt Nichtübereinstimmung der Ringversion an
      3. Log Collector zeigt „Nicht synchron“ aufgrund von „IP-Nichtübereinstimmung für Schnittstelle“ an
7. Überprüfen Sie, ob die ElasticSearch des Log Collectors (einschließlich des lokalen Log Collectors im Panorama) fehlerfrei funktioniert.
   1. Unten sehen Sie ein Beispiel für eine fehlerhafte ElasticSearch.

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. Starten Sie ElasticSearch mit dem folgenden Befehl neu und überprüfen Sie den Zustand erneut. Beachten Sie, dass bei der Konfiguration mehrerer Protokollsammler einer den Protokollsammler mit dem Problem identifizieren und dann Elasticsearch auf dem fehlgeschlagenen Protokollsammler neu starten muss. Wenn Sie Hilfe benötigen, wenden Sie sich an den Support .

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

3. Unten sehen Sie ein Beispiel für eine fehlerfreie ElasticSearch.

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. Wenn die Protokolle fehlen oder verspätet sind, lesen Sie „Verzögerungen bei der Protokollweiterleitung“ oder „Fehlende Protokolle aufgrund hoher Latenz zwischen Protokollsammlern in einer Sammlergruppe“ .