Beiträge von voja

Kennst Du Ansible Galaxy schon? Da findet man jede Menge. https://galaxy.ansible.com/

Bei Github und Co. findet man auch zu verschiedenen Themen etwas.

Zitat von miloe

* CNAME xyz.dyndns.net ist also nicht erlaubt?

@ CNAME xyz.dyndns.net ist nicht erlaubt. @ steht für die Domain selbst. Für * sollte das gehen.

Laut Google wurde die Entwicklung von POP before SMTP für Postfix/Dovecot vor ca. 6 Jahren eingestellt und die Lösung soll nicht mehr verwendet werden.

Für die aktuellen Versionen von Postfix/Dovecot finde ich auch keine Hinweise mehr auf eine solche Lösung.

POP before SMTP dürfte damit technisch komplett überholt sein und sollte nicht mehr verwendet werden.

Seit langem wird SMTP Auth eingesetzt und ich habe schon seit gefühlten Ewigkeiten von keinen Problemen mehr damit gehört.

Ich kann Icinga2 empfehlen. Die Hosts kann man z.B. auch per Ansible Playbook ins Monitoring aufnehmen. EMail Alerts und Telegram Nachrichten habe ich zur Alarmierung drin.

Dann war „bridge_ports none“ der Hauptunterschied. Dann ist die ausgehende MAC-Adresse immer die von der Haupt IP.

Du müsstest die /etc/network/interfaces vom Proxmox und von Deinem Container (von mir aus kannst Du die letzten Ziffern in den IPs z.B. durch X ersetzen) posten. Irgendwo dort würde ich das Problem vermuten, wenn die Container nicht mal den Proxmox Host erreichen können.

BTW: Proxmox Firewall ist komplett aus?

Noch als Update: der Support hat den Root-Server gestern auf ein anderes Hostsystem geschoben und das Problem dadurch für mich gelöst.

Zitat von mfnalex

Ist die Abweisung der Mail mit dem Gtube Pattern denn ein Anzeichen dafür dass Sieve überhaupt funktioniert? Ein ps aux | grep sieve liefert mir nichts, aber sieve läuft ja soweit ich das verstanden habe auch nicht immer sondern wird nur von Dovecot aufgerufen wenn eine Mail eingeht.

Schau mal in /var/log/mail.log nach, ob er die eMail weitergeleitet hat. Vielleicht sieht sieve, dass die Umleitung nicht geklappt hat und schreibt deshalb die Mail in die Inbox. Hast Du es mal mit einer normalen Mail versucht?

Können die Container die IP von Deinem Proxmox Server pingen?

Zitat von mfnalex

Hab den Pfad nochmal überprüft, müsste richtig sein:

Code

root@mail:/var/vmail/sieve/<meinedomain2.de>/mail/scripts# ls -l
insgesamt 4
-rw-r--r-- 1 vmail vmail 41 Mai 26 17:39 weiterleitung.sieve

Muss eventuell irgendein Dienst neugestartet werden wenn ich die Datei ändere?

Eigentlich nicht, da Dovecot die Sieve Files auch replizieren kann und die dann auf dem anderen Server direkt funktionieren.

KB19 Ich frage mich gerade, ob ich das einfach nur mit https://plugins.roundcube.net/packages/johndoh/sieverules verwechselt habe. In dem Fall sorry fürs Schreck einjagen.

mfnalex Deswegen hatte mich der Pfad irritiert. So sollte er das File eigentlich nehmen.

Stimmt der Pfad? Bei mir liegen die Scripte unter /var/vmail/sieve/username/scripts/

Ich manage mein Sieve mit dem roundcube Plugin, auch wenn das eingestampft wird.

Die zweite Anleitung sieht für mich genau richtig aus, Du musst nur eth0 durch ens3 ersetzen.

Einzelunternehmer führen doch soweit ich weiß den eigenen Namen im/als Firmennamen.

Ich bin da schon ne Weile raus, aber als ich Einzelunternehmer war, habe ich zum Beispiel immer „Vorname Nachname Hard- und Software“ auf die Rechnungen geschrieben. Aber auch nur der Name hat gereicht, weil Einzelunternehmer.

Der Support konnte inzwischen auch das Problem nachvollziehen, aber noch nicht die genaue Ursache finden. Sie versuchen das zu klären, es könnte mit dem Zielprovider zusammen hängen.

Edit: wobei ich nicht verstehe warum ich vom Root-Server aus den ersten Hop nicht sehe. Das passt für mich nicht ins Bild.

Ich werde unabhängig vom Internetprovider auf das CCP umgeleitet.

Hast Du ein Webhosting oder einen VServer? Wie sieht die DNS-Zone aus?

Zitat von Lukay

Hast du schon mal selbst per Rettungssystem getestet?

Ja, im Rettungssystem kann ich das Problem genau so feststellen.

root@grml ~ # ip addr add 2a03:4000:10:29c::1/64 dev ens3

root@grml ~ # /sbin/ip -6 route add default via fe80::1 dev ens3

RTNETLINK answers: File exists

D.h. ich musste die IP hinzufügen, aber die Default Route war schon gesetzt. Das Problem tritt auf genau wie vorher:

root@grml ~ # traceroute6 2001:4178:2:1113::42

traceroute to (2001:4178:2:1113::42) from 2a03:4000:10:29c::1, 30 hops max, 24 byte packets

1 * * *

2 * * *

3 * * *

^C

Gegenprobe Google, die auch vom Support angewendet wurde:

root@grml ~ # traceroute6 google.de

traceroute to (2a00:1450:4001:816::2003) from 2a03:4000:10:29c::1, 30 hops max, 24 byte packets

1 2a03:4000:10::3 (2a03:4000:10::3) 0.715 ms 2.094 ms 1.121 ms

2 2a00:11c0:47:3::1e (2a00:11c0:47:3::1e) 0.49 ms 0.495 ms 0.339 ms

3 2a00:11c0:47:1:47::141 (2a00:11c0:47:1:47::141) 3.6 ms 3.779 ms 3.596 ms

4 2001:4860:1:1::6bc (2001:4860:1:1::6bc) 3.786 ms 3.906 ms 3.785 ms

5 2001:4860:0:11e0::1 (2001:4860:0:11e0::1) 4.019 ms 3.985 ms 3.9 ms

6 2001:4860:0:1::6f9 (2001:4860:0:1::6f9) 4.075 ms 3.927 ms 3.924 ms

7 fra16s07-in-x03.1e100.net (2a00:1450:4001:816::2003) 3.528 ms 3.483 ms 3.543 ms

Der Support meinte auch schon die Netze werden jeweils korrekt announced und sollten erreichbar sein. Sind sie aber nicht.

Ein schneller Test mit tshark ergibt das selbe Fehlerbild. Zum Beispiel:

Externer Server sieht den ping ausgehend.

Netcup Server sieht den ping eingehend.

Netcup Server sieht den ping ausgehend.

Die Antwort kommt aber nicht an.

br0 ist eine Bridge über die Container mit public IPs versorgt werden.

lxdbr0 ist die Default Bridge von LXD.

Edit: bridge_ports ist jeweils none

Die veth Interfaces gehören zu den lxc Containern. Zwei hängen an br0, einer an lxdbr0.

Ob ich wirklich alle Bridges abgedreht kriege müsste ich mal gucken.

tshark werde ich mir später mal anschauen.