Beiträge von voja

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.

Zitat von gunnarh

Ad-Hoc sehe ich das Problem auch nicht.

Das macht mich gerade auch verrückt, ich weiß nicht mehr was ich noch probieren soll.

Ping6/Traceroute6 zu Google geht auch. Ich kann ja bis auf dieses Netz alles erreichen, was ich probiert habe.

Danke schonmal fürs Anschauen. Ich sehe den Wald vor lauter Bäumen nicht mehr.

route -6 -n

Kernel IPv6 routing table

Destination Next Hop Flag Met Ref Use If

2a03:4000:10:29c::1/128 :: U 256 0 0 ens3

2a03:4000:10:29c::/64 :: U 256 2 17013 br0

fd8e:8f27:59d5:1ddc::/64 :: U 256 1 1 lxdbr0

fe80::/64 :: U 256 2 17 ens3

fe80::/64 :: U 256 0 0 br0

fe80::/64 :: U 256 1 1 lxdbr0

fe80::/64 :: U 256 0 0 veth4S6HJA

fe80::/64 :: U 256 0 0 veth59NTP6

fe80::/64 :: U 256 0 0 veth13K20P

::/0 fe80::1 UG 1024 2 24871 ens3

::/0 :: !n -1 1 41976 lo

::1/128 :: Un 0 3 86 lo

2a03:4000:10:29c::/128 :: Un 0 1 0 lo

2a03:4000:10:29c::1/128 :: Un 0 3 188 lo

2a03:4000:10:29c::1/128 :: Un 0 3 43 lo

fd8e:8f27:59d5:1ddc::/128 :: Un 0 1 0 lo

fd8e:8f27:59d5:1ddc::1/128 :: Un 0 2 3 lo

fe80::/128 :: Un 0 1 0 lo

fe80::/128 :: Un 0 1 0 lo

fe80::/128 :: Un 0 1 0 lo

fe80::/128 :: Un 0 1 0 lo

fe80::/128 :: Un 0 1 0 lo

fe80::/128 :: Un 0 1 0 lo

fe80::1471:e8ff:fe1f:6882/128 :: Un 0 3 25 lo

fe80::74c5:d6ff:fe45:3817/128 :: Un 0 3 461 lo

fe80::8c48:2cff:fe01:ef2c/128 :: Un 0 2 2 lo

fe80::fc59:84ff:fef5:7a99/128 :: Un 0 1 0 lo

fe80::fcb2:16ff:fed4:fbe0/128 :: Un 0 1 0 lo

fe80::fce4:beff:fee0:60cf/128 :: Un 0 1 0 lo

ff00::/8 :: U 256 2 7360 ens3

ff00::/8 :: U 256 2 22 br0

ff00::/8 :: U 256 2 24 lxdbr0

ff00::/8 :: U 256 0 0 veth4S6HJA

ff00::/8 :: U 256 0 0 veth59NTP6

ff00::/8 :: U 256 0 0 veth13K20P

::/0 :: !n -1 1 41976 lo

So sieht das aus wenn das Ziel nicht erreicht werden kann:

traceroute6 www.voja.de

traceroute to www.voja.de(2001:4178:2:1113::42) from 2a03:4000:10:29c::1, port 33434, from port 34477, 30 hops max, 60 bytes packets

1 * * *

2 * * *

^C

So sieht es bei Zielen aus die gehen (habe jetzt einen Netcup internen Host genommen um keine Konkurenten Name im traceroute zu haben):


traceroute6 thor.voja.de

traceroute to thor.voja.de (2a03:4000:1d:424::1) from 2a03:4000:10:29c::1, port 33434, from port 34243, 30 hops max, 60 bytes packets

1 2a03:4000:10::3 (2a03:4000:10::3) 0.328 ms 0.220 ms 0.205 ms

2 thor.voja.de (2a03:4000:1d:424::1) 0.218 ms 0.173 ms 0.309 ms

Edit: besser formatiert kriege ich es im Moment (mobil) nicht hin.

Edit 2: es gibt eine Firewall direkt vor dem Ziel, die UDP Pakete an unbekannte Ports dropped.

Zitat von mlohr

Woher weißt du, dass die Pakete den Server verlassen, aber den Netcup-Router nicht erreichen?

Im traceroute6 kommen nur Sterne und tcpdump sieht das Datenpaket auf der primären Netzwerkkarte.