Client wird gesperrt? Heimdall Docker schuld?


LyDjane

Recommended Posts

Guten Morgen zusammen,

 

ich hatte in der Vergangenheit immer mal wieder Probleme, dass nach dem Start des PC ich nicht auf die Freigaben gekommen bin (welche im PC eingebunden sind) und auch unRAID sowie meine Docker nicht via Webbrowser aufrufen konnte.
Weiterhin konnte ich den Server auch nicht via ping erreichen. Es gab immer die Fehlermeldung "Zeitüberschreitung".


Nachdem ich den PC neu starte oder einfach eine Zeit X gewartet habe, funktionierte es plötzlich wieder problemlos.

Heute habe ich an einem Docker gearbeitet und wurde plötzlich wieder "ausgesperrt".

Sowohl mit dem Handy als auch mit dem Tablet erreiche ich alles problemlos.

Folgendes habe ich nun in den Logs entdeckt:

Oct  7 10:22:50 unRAID-Server  avahi-daemon[13014]: New relevant interface veth77cad04.IPv6 for mDNS.
Oct  7 10:22:50 unRAID-Server  avahi-daemon[13014]: Registering new address record for XXXX::XXXX:XXXX:feb2:864c on veth77cad04.*.
Oct  7 10:23:54 unRAID-Server  vsftpd[29474]: connect from XXX.XXX.XXX.49 (XXX.XXX.XXX.49)
Oct  7 10:23:54 unRAID-Server  vsftpd[29474]: [root] OK LOGIN: Client "XXX.XXX.XXX.49"
Oct  7 10:24:20 unRAID-Server kernel: veth64c6cd8: renamed from eth0
Oct  7 10:24:20 unRAID-Server kernel: docker0: port 10(veth77cad04) entered disabled state
Oct  7 10:24:20 unRAID-Server  avahi-daemon[13014]: Interface veth77cad04.IPv6 no longer relevant for mDNS.
Oct  7 10:24:20 unRAID-Server  avahi-daemon[13014]: Leaving mDNS multicast group on interface veth77cad04.IPv6 with address XXXX::XXXX:XXXX:feb2:864c.
Oct  7 10:24:20 unRAID-Server kernel: docker0: port 10(veth77cad04) entered disabled state
Oct  7 10:24:20 unRAID-Server kernel: device veth77cad04 left promiscuous mode
Oct  7 10:24:20 unRAID-Server kernel: docker0: port 10(veth77cad04) entered disabled state
Oct  7 10:24:20 unRAID-Server  avahi-daemon[13014]: Withdrawing address record for XXXX::XXXX:XXXX:feb2:864c on veth77cad04.
Oct  7 10:24:28 unRAID-Server kernel: docker0: port 10(vetha188847) entered blocking state
Oct  7 10:24:28 unRAID-Server kernel: docker0: port 10(vetha188847) entered disabled state
Oct  7 10:24:28 unRAID-Server kernel: device vetha188847 entered promiscuous mode
Oct  7 10:24:28 unRAID-Server kernel: docker0: port 10(vetha188847) entered blocking state
Oct  7 10:24:28 unRAID-Server kernel: docker0: port 10(vetha188847) entered forwarding state
Oct  7 10:24:28 unRAID-Server kernel: docker0: port 10(vetha188847) entered disabled state
Oct  7 10:24:29 unRAID-Server kernel: eth0: renamed from veth90b18bf
Oct  7 10:24:29 unRAID-Server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vetha188847: link becomes ready
Oct  7 10:24:29 unRAID-Server kernel: docker0: port 10(vetha188847) entered blocking state
Oct  7 10:24:29 unRAID-Server kernel: docker0: port 10(vetha188847) entered forwarding state
Oct  7 10:24:31 unRAID-Server  avahi-daemon[13014]: Joining mDNS multicast group on interface vetha188847.IPv6 with address XXXX::XXXX:XXX:fef1:e898.
Oct  7 10:24:31 unRAID-Server  avahi-daemon[13014]: New relevant interface vetha188847.IPv6 for mDNS.
Oct  7 10:24:31 unRAID-Server  avahi-daemon[13014]: Registering new address record for XXXX::XXXX:XXX:fef1:e898 on vetha188847.*.
Oct  7 10:26:03 unRAID-Server kernel: docker0: port 10(vetha188847) entered disabled state
Oct  7 10:26:03 unRAID-Server kernel: veth90b18bf: renamed from eth0
Oct  7 10:26:03 unRAID-Server  avahi-daemon[13014]: Interface vetha188847.IPv6 no longer relevant for mDNS.
Oct  7 10:26:03 unRAID-Server  avahi-daemon[13014]: Leaving mDNS multicast group on interface vetha188847.IPv6 with address XXXX::XXXX:XXX:fef1:e898.
Oct  7 10:26:03 unRAID-Server kernel: docker0: port 10(vetha188847) entered disabled state
Oct  7 10:26:03 unRAID-Server kernel: device vetha188847 left promiscuous mode
Oct  7 10:26:03 unRAID-Server kernel: docker0: port 10(vetha188847) entered disabled state
Oct  7 10:26:03 unRAID-Server  avahi-daemon[13014]: Withdrawing address record for XXXX::XXXX:XXX:fef1:e898 on vetha188847.
Oct  7 10:26:03 unRAID-Server kernel: docker0: port 10(veth2984986) entered blocking state
Oct  7 10:26:03 unRAID-Server kernel: docker0: port 10(veth2984986) entered disabled state
Oct  7 10:26:03 unRAID-Server kernel: device veth2984986 entered promiscuous mode
Oct  7 10:26:03 unRAID-Server kernel: docker0: port 10(veth2984986) entered blocking state
Oct  7 10:26:03 unRAID-Server kernel: docker0: port 10(veth2984986) entered forwarding state
Oct  7 10:26:03 unRAID-Server kernel: eth0: renamed from veth6ea744c
Oct  7 10:26:03 unRAID-Server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth2984986: link becomes ready
Oct  7 10:26:05 unRAID-Server  avahi-daemon[13014]: Joining mDNS multicast group on interface veth2984986.IPv6 with address XXXX::XXXX:XXXX:XXXX:d0c8.
Oct  7 10:26:05 unRAID-Server  avahi-daemon[13014]: New relevant interface veth2984986.IPv6 for mDNS.
Oct  7 10:26:05 unRAID-Server  avahi-daemon[13014]: Registering new address record for XXXX::XXXX:XXXX:XXXX:d0c8 on veth2984986.*.
Oct  7 10:26:34 unRAID-Server kernel: veth6ea744c: renamed from eth0
Oct  7 10:26:34 unRAID-Server kernel: docker0: port 10(veth2984986) entered disabled state
Oct  7 10:26:34 unRAID-Server  avahi-daemon[13014]: Interface veth2984986.IPv6 no longer relevant for mDNS.
Oct  7 10:26:34 unRAID-Server  avahi-daemon[13014]: Leaving mDNS multicast group on interface veth2984986.IPv6 with address XXXX::XXXX:XXXX:XXXX:d0c8.
Oct  7 10:26:34 unRAID-Server kernel: docker0: port 10(veth2984986) entered disabled state
Oct  7 10:26:34 unRAID-Server kernel: device veth2984986 left promiscuous mode
Oct  7 10:26:34 unRAID-Server kernel: docker0: port 10(veth2984986) entered disabled state
Oct  7 10:26:34 unRAID-Server  avahi-daemon[13014]: Withdrawing address record for XXXX::XXXX:XXXX:XXXX:d0c8 on veth2984986.
Oct  7 10:26:34 unRAID-Server kernel: docker0: port 10(vethcbac438) entered blocking state
Oct  7 10:26:34 unRAID-Server kernel: docker0: port 10(vethcbac438) entered disabled state
Oct  7 10:26:34 unRAID-Server kernel: device vethcbac438 entered promiscuous mode
Oct  7 10:26:34 unRAID-Server kernel: docker0: port 10(vethcbac438) entered blocking state
Oct  7 10:26:34 unRAID-Server kernel: docker0: port 10(vethcbac438) entered forwarding state
Oct  7 10:26:34 unRAID-Server kernel: eth0: renamed from vethf54458d

 

unter Port 10 vom Docker läuft Heimdall (https://hub.docker.com/r/linuxserver/heimdall).
Entsteht der Fehler durch diesen Docker? Und wenn ja wieso sperrt er mich aus?

Die IP von meinem PC ist immer die gleiche, wieso klappt es nach einem Neustart sofort problemlos?

 

Viele Grüße und vielen Dank vorab!

Edited by LyDjane
Link to comment
  • LyDjane changed the title to Client wird gesperrt? Heimdall Docker schuld?
  • 1 month later...

Sorry für die späte Rückmeldung, ich war selbst sehr lange noch auf der Suche nach dem Fehler, aber bin mit meinem Latein am Ende.

 

Folgendes habe ich herausfinden können in der Zwischenzeit:

  • mein ESET meldet regelmäßig, dass im Netzwerk eine IP-Adresse doppelt vergeben ist.
  • die doppelte IP-Adresse stammt anscheinend vom unRAID-Server (Screenshot aus der Frizbox)
    image.thumb.png.392cbf42954749d904c66a2755d7dcd7.png
  • der unRAID-Server selbst hat in den Netzwerkeinstellungen die MAC-Adresse XYZ, diese stimmt auch mit der in der Fritzbox unter unRAID-Server überein.
  • die IP-Adresse .41 (also die zweite) hat allerdings eine völlig andere MAC-Adresse, die ich nicht zuordnen kann.

Ich bin alle Docker durchgegangen, welche auf dem unRAID-Server laufen und habe die MAC Adressen kontrolliert, es ist kein Docker. Ich habe zur Vorsicht auch alle Docker deaktiviert und dann die Fritzbox neu gestartet, ohne einen laufenden Docker war die doppelte IP-Adresse trotzdem wieder vorhanden.

 

In der Fritzbox ist der unRAID-Server als statisch mit der .41 hinterlegt. In den unRAID Einstellungen als "automatisch".

Die zweite .41 IP-Adresse kann ich auch nicht auf eine andere ändern in der Fritzbox.

Viele Grüße

Edited by LyDjane
Link to comment
13 minutes ago, LyDjane said:

die doppelte IP-Adresse stammt anscheinend vom unRAID-Server (Screenshot aus der Frizbox)

wenn du host access in den docker Einstellungen aktiviert hast, ist der doppelte Eintrag normal und kein Fehler.

 

dann wäre noch zu beachten, wie dein docker Netzwerk setup steht

 

macvlan verträgt die Fritz

ipvlan nicht ... da spielt alles verrückt wegen den mac adressen

 

image.thumb.png.382c1c238a274879b643f7ae4456dde4.png

Link to comment
2 minutes ago, LyDjane said:

Heißt die zweite "IP" ist der Docker Host access dann an der Stelle?

 

genau so in etwa ;)

 

schalte den host access aus und der 2. Eintrag (shim bridge) ist inaktiv.

 

53 minutes ago, mgutt said:

Gilt das auch für die Laborversion? Ich habe jetzt mittlerweile die, weil mir diverse Bugs rund um IPv6 und VPN Tunnel auf den Keks gegangen sind. Jetzt bin ich wieder zufrieden.

sprich, du hast es getestet und die Geräte "springen" nicht mehr wild umher oder war die Frage an mich gemünzt ob ich das nochmals getestet habe ? wenn, Nope, den Spaß tue ich mir nicht mehr an da ich mit macvlan keine Probleme habe ... und ja, ich hab die labor drauf ;) nur wie geschrieben, danach wieder alles sauber zuordnen macht mir keinen Spaß ;)

  • Like 1
Link to comment
4 hours ago, alturismo said:
4 hours ago, LyDjane said:

Heißt die zweite "IP" ist der Docker Host access dann an der Stelle?

 

genau so in etwa ;)

 

schalte den host access aus und der 2. Eintrag (shim bridge) ist inaktiv.

Bedeutet aber auch, dass die Docker die als "host" laufen, dann nicht mehr funktionieren?

Link to comment
11 minutes ago, LyDjane said:

Bedeutet aber auch, dass die Docker die als "host" laufen, dann nicht mehr funktionieren?

wieso, das hat nichts damit zu tun ... und host würde ich eh vermeiden, aber wie gesagt, shim br0 (docker host access) hat nichts mit docker host zu tun und dadurch ist auch der 2. Eintrag in der Fritz normal.

 

ich wollte damit nur klar machen dass dies nicht das Problem ist wenn ...

Link to comment
  • 6 months later...
On 11/13/2022 at 1:17 PM, alturismo said:

macvlan verträgt die Fritz

ipvlan nicht ... da spielt alles verrückt wegen den mac adressen

 

Moin zusammen,

 

ich weiß nicht ob ihr mittlerweile ipvlan mit einer Fritzbix ausprobiert habt, aber ich habe eine FRITZ!Box 6591 Cable von Vodafone und nutze damit ipvlan.

 

Ich hatte in Unraid bis vor kurzem macvlan in den Dockereinstellungen. Ich habe 6 Dockercontainer, jeder hat seine eigene feste IP-Adresse bekommen. Dann gab es vor ein paar Tagen eine Warnung in Unraid, dass ich lieber ipvlan verwenden soll. Warum weiß ich leider nicht mehr genau. Ich habe daher auf ipvlan umgestellt. In den Dockercontainer selbst habe ich nichts geändert, alle haben ihre jeweiligen IP-Adressen behalten.

 

Ergebnis:

Ich kann weiterhin alle Dockercontainer via IP-Adresse erreichen. Der einzige Unterschied ist, dass ich die IP-Adressen der Dockercontainer nicht mehr in er Fritzbox sehen kann, was mit macvlan vorher der Fall war. Ansonsten kann ich bisher nichts negatives berichten.

 

Als FritzOS nutze ich Version 07.29

Link to comment
9 hours ago, HGWBLN said:

Ergebnis:

Ich kann weiterhin alle Dockercontainer via IP-Adresse erreichen. Der einzige Unterschied ist, dass ich die IP-Adressen der Dockercontainer nicht mehr in er Fritzbox sehen kann, was mit macvlan vorher der Fall war. Ansonsten kann ich bisher nichts negatives berichten.

 

Als FritzOS nutze ich Version 07.29

dann hoffe dass dies so bleibt ;)

 

IP Adressen ... jetzt haben alle Geräte (Dockers im IPVlan) die gleiche mac Adresse und damit hat die Fritz Probleme, bei mir sah ich alle geräte, jedoch "sprangen" die wild durch ... Beispiel, swag hat die IP 192.168.1.80, guacamole .....90, usw ... mit IPVLAN springen die jetzt durch weil die Fritz unter der mac alle anspricht, mal geht etwas, mal dauert es etwas länger da ja die IP gerade wohin auch immer will ... ich schätze du wirst es merken wenn es ab und an etwas dauert bis sich ein webui eines Dockers öffnet, oder du aktualiseren müsstest usw usw ...

 

Nachfrage bei AVM ergab auch dass dies klar ist und seitens AVM jetzt aber auch keine Änderung geben wird, was ich verstehe ... die bauen auf mac und da ist 1 x mac für xxx Geräte nun mal nicht förderlich ... ich hatte dies auch mit der 7.29 getestet und einmalig noch mit einer 7.39 Labor (heute 7.5).

 

Ebenfalls auf einer 6591 und einer 6660, denke bei einem Neustart Router, Server, Docker ... kann es passieren das dann nicht mehr alles so wirklich will, nur dann bitte zuerst ipvlan deaktivieren bevor hier Anfragen dazu kommen ...

  • Thanks 1
Link to comment
8 hours ago, HGWBLN said:

Wäre es dann aber nicht sinnvoll bei macvaln zu bleiben? Wie gesagt, hatte ich das dursprünglich auch, bis Unraid selber meinte, ich solle lieber ipvlan verwenden.

Limetech ist sich bewusst dass dies kritisch ist ... daher die Empfehlung zu IPVlan zu wechseln "wo es geht" ...

 

Fritz ist halt ein Szenario wo es nicht so toll ist ... und es gibt sicherlich noch mehr Szenarien ;)

 

kannst Dich ja hier mal einlesen ... mit 6.12 war/ist aktuell hier halt Ende mit macvlan ...

 

https://forums.unraid.net/bug-reports/prereleases/6120-rc4-macvlan-call-traces-found-but-not-on-r2379/page/3/?tab=comments#comment-23852

 

  • Thanks 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.