Oder mittels Cronjob tcpdump o.ä. laufen lassen, die Ausgabe von top speichern...
Wenn sich solche Phänomene schon zeitlich dermaßen exakt wiederholen, kann man das ja ruhig nutzen
MfG Aleph
Oder mittels Cronjob tcpdump o.ä. laufen lassen, die Ausgabe von top speichern...
Wenn sich solche Phänomene schon zeitlich dermaßen exakt wiederholen, kann man das ja ruhig nutzen
MfG Aleph
thys,
das "freut" mich, dass ich nicht der einzige mit dem Problem bin.
Wo hast du ein Feedback-Formular gefunden welches ohne Anmeldung bei yahoo funktioniert ?
Leider gar nicht, ich habe mir einen Account angelegt.
Wie ich gerade feststellen durfte, ist meine Mail von vor 4 Tagen nun durchgekommen, auch weitere Testmails konnten zugestellt werden. Allerdings habe ich glaube ich am Dienstag wieder dieses elende Formular ausgefüllt.
MfG Aleph
Dachte ich zuerst auch, aber wie es scheint, ist das eine generische Fehlermeldung - zumal bei Yahoo selbst nichts von einer Nutzerinteraktion steht.
Der Server läuft unter dieser IP-Adresse erst rund 2 Monate. Laut Mail-Log kann ich die Yahoo-Empfänger in dieser Zeit an einer Hand abzählen. Vor allem gingen zwischen dem zweimaligen Auftreten des Problems nur Testmails an meinen eigenen Yahoo-Account raus - das wüsste ich, wenn ich diese Mails als Spam markiert haben sollte
MfG Aleph
Guten Morgen,
ich habe wiederholt das Problem, dass an Yahoo gehende E-Mails nicht ankommen:
Zitat(host mta6.am0.yahoodns.net[66.196.118.36] said: 421 4.7.0 [TSS09] All messages from 185.170.112.133 temporarily deferred due to user complaints - 4.16.56.1; see Error: "421 4.7.0 [XXX] Messages from x.x.x.x temporarily deferred - 4.16.56.1" | Postmaster Help- SLN3326 (in reply to MAIL FROM command))
Das Problem bestand vor rund einem Monat schon einmal, das lag aber wohl daran, dass ich DKIM noch nicht eingerichtet hatte.
Laut Error: "421 4.7.0 [XXX] Messages from x.x.x.x temporarily deferred - 4.16.56.1" |Postmaster Help- SLN3326 sollen folgende Voraussetzungen erfüllt sein:
Ich habe dann also DKIM eingerichtet, ein "Complaint Feedback Loop"-Formular bei Yahoo ausgefüllt und nach rund 2 Tagen gingen die Mails endlich raus.
Seit 4 Tagen hängen nun wieder Mails in der Warteschleife. Ich habe mehrere Checks durchgeführt und kann bislang keinen Fehler entdecken. Laut DKIM Test - DKIM Verify - DKIM Validator (Ergebnisse gibt es unter Perl Nopaste) etwa gibt es bei den Tests zu SPF, DKIM, PTR und RBL keine Probleme. DMARC und DomainKeys sind (noch) nicht eingerichtet, scheinen aber auch keine zwingende Voraussetzung zu sein.
Der Mailserver (postfix, dovecot, etc.) wird gegenwärtig von 4 Personen genutzt. Ich kontrolliere die Logs mit tenshi gewissenhaft und kann ziemlich sichergehen, dass da kein Schindluder getrieben wird - aber ich scheine ja auch auf keiner RBL gelandet zu sein. Fast schon unnötig zu erwähnen, dass sonst alles läuft - GMX, Web.de, Gmail etc. bereiten keine Probleme.
An DMARC will ich mich langfristig zwar sowieso setzen, aber das wollte ich eigentlich in aller Ruhe an einem Wochenende erledigen...
Hat jemand eine Idee, woran das Problem liegen könnte?
MfG Aleph
gunnarh und chrko,
vielen Dank für eure Antworten. chrkos Hinweis hat letztendlich den Ausschlag gegeben. Falls noch jemand vor dem Problem stehen sollte. Einmal den ZSK und einmal den KSK angeben, die entsprechenden Flags und Algorithmen auswählen und beim DNSKEY die 5 Zahlen am Anfang weglassen.
MfG Aleph
gunnarh,
vielen Dank für deine Antwort und den Hinweis mit SHA1 - die Schlüssel werde ich, wenn das grundsätzliche Prozedere klar ist, dann wahrscheinlich nochmal ersetzen.
Ich habe die Schlüssel aus der Datei "dsset-syncookie.de." entnommen, diese Datei wurde beim Erstellen der Schlüssel angelegt und hat folgenden Inhalt:
Zitatsyncookie.de. IN DS 29115 7 1 BB3553956DC52388B7A36DC526DBC2DD5D36A82D
syncookie.de. IN DS 29115 7 2 9008BC78042FA31CF513DA72670C15E63C29B98A2858683900CDE3C0 6E541D7C
Auch wenn ich jetzt beide Schlüssel als KSK angebe, werden keine gültigen DS-Records gefunden. Einigermaßen verwirrend ist halt, dass bei ormanns.net andere Angaben notwendig / möglich sind als bei syncookie.de - bei letzterer Domain kann ich nur den öffentlihen Schlüssel, die Flags (0 / ZSK(256) / KSK (257)) und natürlich den Algorithmus angeben.
MfG Aleph
Hallo zusammen,
ich verwalte mit drei Nameservern mehrere Domains, bei zweien davon habe ich nun DNSSEC eingerichtet. Bei einer davon funktioniert alles wie gewünscht, bei der anderen werden zwar die DS-Records im CCP übernommen, allerdings werden nach mehr als 2 Tagen immer noch keine DS-Records gefunden.
1.
ormanns.net funktioniert problemlos (siehe ormanns.net | DNSViz oder DNSSEC Analyzer - ormanns.net)
Im CCP sind die Angaben wie folgt:
ZitatÖffentlicher Schlüssel: 36D135565E4FD83871C5A2829548BC495AD565ED52CEE4EF5C79F5281FD17B6F
Hashtyp: SHA-256 (2)
Keytag: 64101
Algorithmus: RSASHA1-NSEC3-SHA1 (7)
ZitatÖffentlicher Schlüssel: 859E544AC10965403C0C666FCD5D4368A5F0E383
Hashtyp: SHA-1 (1)
Keytag: 64101
Algorithmus: RSASHA1-NSEC3-SHA1 (7)
Im Zonefile sind Kormanns.net.+007+38219.key und Kormanns.net.+007+64101.key eingebunden.
2.
für syncookie.de werden keine DS-Records gefunden (siehe syncookie.de | DNSViz oder DNSSEC Analyzer - syncookie.de)
Im CCP sind die Angaben wie folgt:
ZitatÖffentlicher Schlüssel: BB3553956DC52388B7A36DC526DBC2DD5D36A82D
Flags: ZSK (256)
Algorithmus: RSASHA1-NSEC3-SHA1 (7)
ZitatÖffentlicher Schlüssel: 9008BC78042FA31CF513DA72670C15E63C29B98A2858683900CDE3C06E541D7C
Flags: KSK (257)
Algorithmus: RSASHA1-NSEC3-SHA1 (7)
Im Zonefile sind /var/cache/bind/Ksyncookie.de.+007+29115.key und /var/cache/bind/Ksyncookie.de.+007+63779.key eingebunden.
Ich habe das Gefühl, irgendwas simples übersehen zu haben...vielleicht findet jemand ja einen - womöglich offensichtlichen - Fehler?
MfG Aleph
Der Vollständigkeit halber - mit folgenden Settings in sshd_config laufen die Tunnel mittlerweile absolut stabil:
ClientAliveInterval 60
ClientAliveCountMax 5
MfG Aleph
Ich habe mich nochmal an das Problem gesetzt und hierzu einen Server (Server1) bei einem weiteren Hoster so eingerichtet, dass diese jeweils einen SSH-Tunnel auf den beiden netcup-Servern öffnet. Diese loggen dann zu Server1.
1. Mir fiel auf, dass mittlerweile nur noch einer der beiden Tunnel Probleme bereitet. Der andere Tunnel arbeitet einwandfrei.
2. Die Disconnects geschehen nicht scheinbar willkürlich, sondern in festen zeitlichen Abständen:
ZitatAlles anzeigen05:07:30 vmd16610 autossh[29711]: ssh child pid is 30422
05:17:45 vmd16610 autossh[29711]: timeout polling to accept read connection
05:17:45 vmd16610 autossh[29711]: port down, restarting ssh
05:17:45 vmd16610 autossh[29711]: starting ssh (count 49)
05:17:45 vmd16610 autossh[29711]: ssh child pid is 30440
05:28:00 vmd16610 autossh[29711]: timeout polling to accept read connection
05:28:00 vmd16610 autossh[29711]: port down, restarting ssh
05:28:00 vmd16610 autossh[29711]: starting ssh (count 50)
05:28:00 vmd16610 autossh[29711]: ssh child pid is 30468
05:38:15 vmd16610 autossh[29711]: timeout polling to accept read connection
05:38:15 vmd16610 autossh[29711]: port down, restarting ssh
05:38:15 vmd16610 autossh[29711]: starting ssh (count 51)
05:38:15 vmd16610 autossh[29711]: ssh child pid is 30484
05:48:30 vmd16610 autossh[29711]: timeout polling to accept read connection
3. Die Kernelconfig, ssh_config und sshd_config sind auf beiden Gentoo-Systemen identisch.
ssh_config
ZitatHost *
ServerAliveInterval 60
ServerAliveCountMax 1000
SendEnv LANG LC_*
sshd_config
ZitatAlles anzeigenPort 12345
PasswordAuthentication no
UsePAM yes
PrintMotd no
PrintLastLog no
TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 1000
# override default of no subsystems
Subsystem sftp /usr/lib64/misc/sftp-server
AcceptEnv LANG LC_*
4. Es bestehen derzeit keine iptables-Regeln.
5. Auf Server1, der die Tunnel aufmacht, sind keine Host-spezifischen SSH-Einstellungen gesetzt, die etwa die Verbindung zu einem bestimmten System beeinflussen.
6. Die Disconnects geschehen nicht aufgrund von Inaktivität. Lasse ich syslog-ng etwas loggen, was dann durch den Tunnel läuft, wird der Tunnel trotzdem "zeitplanmäßig" unterbrochen.
-> Trotz gleicher Einstellungen verhalten sich die Gentoo-Systeme unterschiedlich.
So langsam gehen mir die Ideen aus, woran es liegen könnte, wenn es denn ein Softwareproblem sein soll.
MfG Aleph
Zum Einlesen in die Materie könnte [HowTo] Absicherung und Administration eines Linux-Servers (Stand: 29. 11. 2015) hilfreich sein.
Alles andere wurde ja eigentlich schon gesagt - ein eigener Server ist nun mal leider kein "schnell einrichten und dann nie wieder drum kümmern müssen"-Ding.
MfG Aleph
Ich nutze das Setup auch nur privat - wenn hier und da _mal_ die Verbindung abreißt, ist es nicht so dramatisch
TCPKeepAlive ist aktiviert und ServerAliveInterval habe ich nicht geändert, es sollte also per default deaktiviert sein. NAT nutze ich nur, um die auf einem Nicht-Standard-Port eingehenden SSH-Verbindungsversuche auf 22 weiterzuleiten.
Witzigerweise sind die SSH-Verbindungen von einem anderen Rechner zu den Gentoo-Systemen seit über 12 Stunden stabil....ich bin ein bisschen ratlos.
MfG Aleph
Du meinst wahrscheinlich "make menuconfig" - ich habe den Kernel von Hand konfiguriert und dann kompiliert.
MfG Jimini
Wie genau meinst du das?
MfG Aleph
Hallo zusammen,
ich habe gestern 2 Server in Betrieb genommen, einen RS 1000 G7 SE und einen Root-Server 500. Beide laufen mit Gentoo (4.7.10-hardened) und sind alles andere als ausgelastet.
Von meinem Monitoringsystem zuhause habe ich nun mit autossh mehrere SSH-Tunnel zu jedem der beiden Server eingerichtet (nach dem Schema autossh -N -M12345 -R 5140:localhost:514 -f user@netcup-server).
Leider bricht der Tunnel regelmäßig, d.h. mehrfach pro Stunde zusammen. Er wird zwar natürlich jedesmal neu aufgebaut, die Verbindung sollte aber grundsätzlich nicht so instabil sein.
An meiner Internetverbindung zuhause sollte es nicht liegen, da von hier aus ebenfalls ein Tunnel zu einem dritten Server bei einem anderen Hoster besteht. Dieser Tunnel ist deutlich stabiler - die Verbindung wird im Schnitt alle paar Tage kurz unterbrochen.
Da ich mein Logging- und Monitoringsystem langfristig auf den Root-Server 500 verlagern wollte, stehe ich aktuell natürlich vor einem Problem: wenn die Tunnel dauerhaft instabil sind, ist an ein gescheites Logging ja nicht zu denken.
Hat jemand Ideen, was ich checken könnte? Momentan sieht es halt stark danach aus, als würde es an der Verbindung zum Hoster liegen.
MfG Aleph