Event Log Forwarder für Windows - Logs kommen bei QNAP nicht an
Hallo, wir haben auf unseren Windows 2016 Server der SolarWinds Event Log Forwarder for Windows installiert.
Wie folgt eingerichtet:
Auf der QNAP haben wir folgendes eingerichtet:
Wo liegt das Problem? Die Logs kommen bei der QNAP nicht an.
Vielen Dank!
Wie folgt eingerichtet:
Auf der QNAP haben wir folgendes eingerichtet:
Wo liegt das Problem? Die Logs kommen bei der QNAP nicht an.
Vielen Dank!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 567985
Url: https://administrator.de/contentid/567985
Ausgedruckt am: 14.11.2024 um 09:11 Uhr
13 Kommentare
Neuester Kommentar
Na das was du da eingestellt hast: ausgehend udp 514
Du kannst ja auch mal auf TCP umstellen und schauen, ob das Test-Event auch mit erfolgreich quittiert wird. Udp ist so wie eine Flaschenpost, Du weisst nie, ob sie wirklich ankommt. Dann würdest Du auch in Wireshark sehen, ob die Verbindung steht.
Grüße
lcer
Du kannst ja auch mal auf TCP umstellen und schauen, ob das Test-Event auch mit erfolgreich quittiert wird. Udp ist so wie eine Flaschenpost, Du weisst nie, ob sie wirklich ankommt. Dann würdest Du auch in Wireshark sehen, ob die Verbindung steht.
Grüße
lcer
Zitat von @SabSchap:
Port ist freigegeben. Ausgehend TCP 514.
Test Event per TCP funktioniert auch.
Dennoch kommt nichts beim QNAP an.
Und was sagt wireshark?Port ist freigegeben. Ausgehend TCP 514.
Test Event per TCP funktioniert auch.
Dennoch kommt nichts beim QNAP an.
Grüße
lcer
Port ist freigegeben. Ausgehend TCP 514.
TCP ist ja Blödsinn. Das wäre dann kein Wunder das es nicht klappt, denn Syslog nutzt generell immer UDP als Transport Protokoll !!https://de.wikipedia.org/wiki/Syslog
Kein Wunder also das das dann in die Hose geht wenn man TCP in der Firewall einstellt !
Hallo aqui
Grüße
lcer
Zitat von @aqui:
https://de.wikipedia.org/wiki/Syslog
Kein Wunder also das das dann in die Hose geht wenn man TCP in der Firewall einstellt !
Wenn man aber tcp als Transportprotokoll bei Sender und Empfänger einstellt ( und das einstellbar ist, wie oben in den Screenshots gezeigt) dann sollte es auch gehen. Und man hat verhindert, das irgendwelche UDP Pakete im Nirvana verschwinden. Als Test ist durchaus legitim. Im Produktiven Betrieb kann man sich streiten.Port ist freigegeben. Ausgehend TCP 514.
TCP ist ja Blödsinn. Das wäre dann kein Wunder das es nicht klappt, denn Syslog nutzt generell immer UDP als Transport Protokoll !!https://de.wikipedia.org/wiki/Syslog
Kein Wunder also das das dann in die Hose geht wenn man TCP in der Firewall einstellt !
Grüße
lcer
Bei einem QNAP NAS ist das aber eher zu bezweifeln, denn in der regel arbeitet im QNAP ein Linux Betriebssystem das den OS eigenen Syslog Daemon nutzt und der macht immer UDP.
Ein identisches Syslog Setup hier auf einem älteren TS-439 QNAP loggt fehlerlos alle Syslogs von Cisco Routern und Switches und einigen pfSense Firewalls mit. Alle nutzen durchgehend UDP.
Vielleicht sollte der TO wirklich mal den Wireshark anschmeissen und mal wirklich nachsehen. Das würde wenigstens hier absolute Klarheit für alle Beteiligten schaffen !
Ein identisches Syslog Setup hier auf einem älteren TS-439 QNAP loggt fehlerlos alle Syslogs von Cisco Routern und Switches und einigen pfSense Firewalls mit. Alle nutzen durchgehend UDP.
Vielleicht sollte der TO wirklich mal den Wireshark anschmeissen und mal wirklich nachsehen. Das würde wenigstens hier absolute Klarheit für alle Beteiligten schaffen !
Hallo aqui,
auf meinem QNAP sieht das so aus:
da läuft ein rsyslog, und man udp oder tcp einstellen.
ja, das wäre gut.
Grüße
lcer
Zitat von @aqui:
Bei einem QNAP NAS ist das aber eher zu bezweifeln, denn in der regel arbeitet im QNAP ein Linux Betriebssystem das den OS eigenen Syslog Daemon nutzt und der macht immer UDP.
Bei einem QNAP NAS ist das aber eher zu bezweifeln, denn in der regel arbeitet im QNAP ein Linux Betriebssystem das den OS eigenen Syslog Daemon nutzt und der macht immer UDP.
auf meinem QNAP sieht das so aus:
[/etc] # cat rsyslog.conf
$ModLoad imtcp.so
$InputTCPServerRun 514
$ModLoad imudp.so
$UDPServerRun 514
$template SyslogProtocolStructDataFormat,"<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %syslogtag%%msg:::drop-last-lf%\n"
$outchannel root_rotation, /share/MD0_DATA/syslog/messages, 52428800, /etc/init.d/log_rotation.sh /share/MD0_DATA/syslog/messages
:hostname, isequal, "localhost" ~
*.* $root_rotation;SyslogProtocolStructDataFormat
[/etc] # cat rsyslog.conf
da läuft ein rsyslog, und man udp oder tcp einstellen.
Vielleicht sollte der TO wirklich mal den Wireshark anschmeissen und mal wirklich nachsehen. Das würde wenigstens hier absolute Klarheit für alle Beteiligten schaffen !
ja, das wäre gut.
Grüße
lcer
Hallo,
Wie willst Du Daten schützen, wenn Du bei Fehlfunktionen nicht die erforderlichen Diagnosetools verwendest?
Grüße
lcer
Wie willst Du Daten schützen, wenn Du bei Fehlfunktionen nicht die erforderlichen Diagnosetools verwendest?
Grüße
lcer
Hallo,
Wenn Du Wireshark auf dem PC nicht haben willst, kannst Du auch auf einem geeigneten Switch eine Portspiegelung einrichten und einen anderen PC mit Wireshark zur Datenauswertung nutzen.
Grüße
lcer
Zitat von @SabSchap:
Ich habe gerade einen Portscanner drüber laufen lassen. Weder auf dem Server noch auf der QNAP wird der UDP Port 514 angezeigt.
Ein Portscanner ist hier das falsche Tool! Du musst schauen ob die Pakete tatsächlich rausgehen. Nimm Wireshark.Ich habe gerade einen Portscanner drüber laufen lassen. Weder auf dem Server noch auf der QNAP wird der UDP Port 514 angezeigt.
Wenn Du Wireshark auf dem PC nicht haben willst, kannst Du auch auf einem geeigneten Switch eine Portspiegelung einrichten und einen anderen PC mit Wireshark zur Datenauswertung nutzen.
Grüße
lcer