Beiträge von oliver.g

    Dann setze deine Konfig doch mal statisch um. Unter die Zeile auto eth0:

    Code
    iface eth0 inet static
      address <IpDesServers>
      netmask 255.255.252.0
      gateway <IpDesGateways>

    Die IPs entnimmst du dem SCP. Die netmask sollte passen, falls sie im SCP mit 22 angegeben ist, sonst auch anpassen.


    In /etc/resolv.conf trägst du folgendes ein:

    Code
    nameserver 8.8.8.8
    nameserver 8.8.4.4

    Dann rebooten und schauen ob du wieder nach außen pingen und auflösen kannst. Nach innen sollte dann auch wieder gehen ohne Firewall.

    Hast du mal den Browser Cache geleert? Mal mit einem anderen Browser probiert?

    Wenn du dich per SSH mit dem Server über die Subdomain verbinden kannst, sollte DNS-technisch ja alles OK sein. Kann sein, dass in deinem Browser noch der alte DNS-Eintrag gecached ist (auf die Domainpark-Seite deines Domain-Anbieters). Ich gehe davon aus, du hast den DNS-Eintrag erst vor kurzem auf deine Server-IP geändert?


    Probiere doch mal folgendes:

    Ich setze voraus du benutzt Windows? Dann trägst du in die Datei C:\Windows\System32\drivers\etc\hosts mal folgendes ein:

    <IP deines Servers> <Subdomain>


    Dann Browsercache löschen und nochmal versuchen die Subdomain aufzurufen. Damit schließt du Probleme mit DNS-Caching schon mal aus.

    Ja, finde es auch komisch, aber dennoch zeigt es ja, dass es per se nicht an deinem Server liegt, wenn du auch den netcup-Webserver nicht erreichen kannst. Lässt du die Verbindung zu deinem Server von extern monitoren (z.b. uptimerobot)?

    Häufig habe ich Probleme selbst die Homepage von netcup aufzurufen, während mein Server unerreichbar ist. Hat jemand Tipps für mich wie ich den Fehler auf Serverseite noch eingrenzen kann?

    Das klingt aber doch eher nach einem Problem mit deiner Verbindung, wenn du manchmal auch Probleme hat die Website von netcup aufzurufen?!

    Hier meine Logs:


    partner...

    Code
    May 16 12:25:21 relay01 postfix/smtpd[30825]: connect from unknown[192.168.xxx.yyy]
    May 16 12:25:21 relay01 postfix/smtpd[30825]: 26F6E594E: client=unknown[192.168.xxx.yyy]
    May 16 12:25:21 relay01 postfix/cleanup[31523]: 26F6E594E: message-id=<kcim.591aefb1.31f.782c006561c3e456@mail01.<domain>.de>
    May 16 12:25:21 relay01 postfix/qmgr[26408]: 26F6E594E: from=<<local>@<domain>.de>, size=3202, nrcpt=1 (queue active)
    May 16 12:25:21 relay01 postfix/smtpd[30825]: disconnect from unknown[192.168.xxx.yyy]
    May 16 12:25:21 relay01 postfix/smtp[31524]: warning: numeric domain name in resource data of MX record for <targetdomain>.de: <ip>
    May 16 12:25:21 relay01 postfix/smtp[31524]: 26F6E594E: to=<<targetaddress>@<targetdomain>.de>, relay=<ip>[<ip>]:25, delay=0.24, delays=0.03/0.02/0.12/0.07, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 50565411B6)
    May 16 12:25:21 relay01 postfix/qmgr[26408]: 26F6E594E: removed


    social...

    Code
    May 16 12:25:37 relay01 postfix/smtpd[30825]: connect from unknown[192.168.xxx.yyy]
    May 16 12:25:37 relay01 postfix/smtpd[30825]: C1BD9594E: client=unknown[192.168.xxx.yyy]
    May 16 12:25:37 relay01 postfix/cleanup[31523]: C1BD9594E: message-id=<kcim.591aefc1.351.1f62807e0f571b2e@mail01.<domain>.de>
    May 16 12:25:37 relay01 postfix/qmgr[26408]: C1BD9594E: from=<<local>@<domain>.de>, size=3253, nrcpt=1 (queue active)
    May 16 12:25:37 relay01 postfix/smtpd[30825]: disconnect from unknown[192.168.xxx.yyy]
    May 16 12:25:37 relay01 postfix/smtp[31524]: warning: numeric domain name in resource data of MX record for <targetdomain>.de: <ip>
    May 16 12:25:38 relay01 postfix/smtp[31524]: C1BD9594E: to=<<target2>@<targetdomain>.de>, relay=<ip>[<ip>]:25, delay=0.23, delays=0.02/0/0.16/0.05, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as EC107411B6)
    May 16 12:25:38 relay01 postfix/qmgr[26408]: C1BD9594E: removed


    Sieht eigentlich in Ordnung aus, außer, dass du offensichtlich deinen MX Record direkt auf die IP setzt, anstatt auf einen Hostnamen:

    Code
    warning: numeric domain name in resource data of MX record for <targetdomain>.de: <ip>


    Ich weiß nicht ob das evtl. das Problem ist?!


    EDIT: Nach Lösung des Problems alle IP- und Mail-Adressen anonymisiert => Spamschutz

    SMTP Header ist für dein Problem erstmal unwichtig, weil dieser ja erst dann übetragen wird, wenn überhaupt eine Verbindung aufgebaut wurde, aber da scheint es ja schon zu Haken!


    Läuft dein Server auf DualStack? A und AAAA Record für den Server angelegt, worauf der MX zeigt? Postfix Listener für IPv6 aktiviert? Grundsätzliche IPv6-Konnektivität gegeben? Port 25 frei in der Firewall für IPv6 (IP6Tables)?
    Ich weiß aus Erfahrung (meinen Logs), dass Microsoft Mails nur per IPv4 empfängt und sendet. Ich tippe immer noch auf ein Problem mit deinem Empfang über IPv6.
    Solltest du allerdings nur IPv4 konfiguriert haben (auch im DNS) erübrigt sich mein Verdacht!

    Ich erhalte dort (auch nach Erhöhung des Loglevels - und ja, das Log ist nun deutlich detaillierter) keine Informationen zu diesen "tlds".
    Im Gegentest finde ich sämtliche Mails/Infos, welche ich mir von meiner privaten @live.de Adresse gesendet habe.


    Hast du evtl. zwei konkurrierende MX- oder A-Einträge? Scheinbar ist ja verbindungstechnisch soweit OK, wenn Mails von live.de eintreffen. Vielleicht nutzt live.de den korrekten MX/A und die anderen Provider den falschen?!
    IPv6 Verbindung mal gecheckt? Vielleicht sendet live.de über IPv4 und die anderen versuchen es über IPv6?!


    Sind wage Vermutungen, nähere Infos zu deinem System wären durchaus hilfreich, evtl. auch die anonymisierten Logs/Logabschnitte.

    Danke für dein Feedback.
    Klar ist das Skript nicht DAS Skript zur Ersteinrichtung eines Debian Servers, aber ein Grundgerüst, das man leicht optimieren kann.
    Für saubere Debian 8.7 Neuinstallationen funktioniert es ohne Probleme, daher habe ich mich noch nicht weiter mit der Optimierung befasst.
    Ich habe mal noch einen Hinweis diesbezüglich hinzugefügt.

    Was sagt denn das mail.log, wenn du es nach spezifischen Einträgen zu twitter oder cyberport durchsuchst? Normalerweise sollte dort ja ein Hinweis zu finden sein, wie die Verbindung verlaufen ist (Fehler bei Verbindung, Fehler bei Mail-Annahme, etc.).
    Führe doch mal

    Code
    grep -i twitter /var/log/mail.log


    oder

    Code
    grep -i cyberport /var/log/mail.log


    aus. Damit kannst du (hilfreich bei größeren Logs) die Zeit eingrenzen und dann einfach mal gezielt nachschauen, was bei der Verbindung passiert ist.

    Wenn die richtigen Leute an der Entwicklung beteiligt sind auch ne gute Sache, aber nicht, wenn das nicht so ist, alle Ports offen und das Standardpasswort “1234“ lautet *kopfaufdentisch*