Neuer Container bekommt keine Verbindung zum Internet, bestehende funktionieren

myssv

Member
Jul 8, 2024
56
3
8
Hallo zusammen,
ich habe heute die aktuellsten Proxmox Updates installiert und wollte anschließend einen neuen Container installieren. Der bekommt aber keine Verbindung ins Internet:

Code:
root@Nextcloud:~# apt update
Ign:1 http://deb.debian.org/debian bookworm InRelease                               
Ign:2 http://deb.debian.org/debian bookworm-updates InRelease                       
Err:3 http://deb.debian.org/debian bookworm Release     
  Cannot initiate the connection to deb.debian.org:80 (2a04:4e42:8d::644). - connect (101: Network is unreachable)
Err:4 http://deb.debian.org/debian bookworm-updates Release
  Cannot initiate the connection to deb.debian.org:80 (2a04:4e42:8d::644). - connect (101: Network is unreachable)
Ign:5 http://security.debian.org bookworm-security InRelease
Ign:5 http://security.debian.org bookworm-security InRelease
Err:6 http://security.debian.org bookworm-security Release
  Cannot initiate the connection to security.debian.org:80 (2a04:4e42::644). - connect (101: Network is unreachable) Cannot initiate the connection to security.debian.org:80 (2a04:4e42:200::644). - connect (101: Network is unreachable) Cannot initiate the connection to security.debian.org:80 (2a04:4e42:400::644). - connect (101: Network is unreachable) Cannot initiate the connection to security.debian.org:80 (2a04:4e42:600::644). - connect (101: Network is unreachable)
Reading package lists... Done
E: The repository 'http://deb.debian.org/debian bookworm Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'http://deb.debian.org/debian bookworm-updates Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'http://security.debian.org bookworm-security Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
root@Nextcloud:~#

Die Netzwerkeinstellungen sind wie folgt:

1740934503102.png

alle anderen Container funktionieren.

Hier ein Beispiel der Netzwerkeinstellungen:

1740934554966.png

und da läuft es:

Code:
root@pi-hole:~# apt update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org bookworm-security InRelease
Hit:3 http://deb.debian.org/debian bookworm-updates InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
root@pi-hole:~# ^C

Pi-hole ist für alle gleich

Hat jemand eine Idee?
Ist in der aktuellen Proxmox Version ein Bug?
 
Und Deine gesamtes Netzwerk ist wie eingerichtet?
1) von Proxmox VE Hostsystem, die Textdatei bitte kopieren
2) von den LXC und VM, die Textdatei bitte kopieren

Container sind bei Dir LXC?

Proxmox SDN oder iptables im Einsatz?

Sind DNS und Domain gesetzt?

Habe ich alles in der Glaskugel gesehen...
 
Sorry, bin nicht ganz sicher was Du meinst?
Welche Textdateien soll ich kopieren?

Ich hoffe mal diese:

Host:
Code:
auto lo
iface lo inet loopback

iface enp3s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.115.13/24
        gateway 192.168.115.1
        bridge-ports enp3s0
        bridge-stp off
        bridge-fd 0


source /etc/network/interfaces.d/*

Bei den Containern finde ich die Dateien nicht

DNS Container:
1740939741382.png

DNS Host:
1740939760078.png

Beides sind Linux-Container:
1740939824753.png
 
Last edited:
Cannot initiate the connection to deb.debian.org:80 (2a04:4e42:8d::644). - connect (101: Network is unreachable)
Offenbar wird IPv6 versucht. Wenn dein lokales Netzwerk nicht vollständig korrekt eingerichtet ist, klappt das aber nicht.

Das Problem dabei ist, dass IPv6 Priorität hat und der Fallback auf IPv4 nicht immer zuverlässig funktioniert.

Ich selber habe hier nur eine kaputte IPv6 Versorgung; ich deaktivere IPv6 daher häufig komplett. (Ja, ich weiß, das ist total "§$%&"!)

Wie das dauerhaft geht findet sich per Suchmaschine, jeweils passend zur verwendeten Distribution.
 
Offenbar wird IPv6 versucht. Wenn dein lokales Netzwerk nicht vollständig korrekt eingerichtet ist, klappt das aber nicht.
Ich habe IPv6 komplett deaktiviert, weswegen die Container auch keine Adresse bekommen.

Warum soll das "§$%&" sein? Ich benötige im Heimnetz kein v6. v4 ist in meinen Augen sauber konfiguriert und läuft ja auch.

Warum kommt der Fehler aber nur bei dem neuen Container und nicht bei den Alten?
Irgendwas scheint da noch aktiv zu sein, was nicht sein sollte.
 
Wie das dauerhaft geht findet sich per Suchmaschine, jeweils passend zur verwendeten Distribution.
Ich nutze Debian und habe im Netz folgendes gefunden:

Code:
sudo nano /etc/sysctl.conf
 
Füge dieser Befhle am Ende der Datei:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.tun0.disable_ipv6 = 1

Nach einem Neustart habe ich das selbe verhalten:

Code:
Debian GNU/Linux 12 Nextcloud tty1

Nextcloud login: root
Password:
Linux Nextcloud 6.8.12-8-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-8 (2025-01-24T12:32Z) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Mar  2 18:15:32 UTC 2025 on tty1
root@Nextcloud:~# apt update
Ign:1 http://deb.debian.org/debian bookworm InRelease                                                                       
Ign:2 http://deb.debian.org/debian bookworm-updates InRelease                                                               
Err:3 http://deb.debian.org/debian bookworm Release                                                                         
  Cannot initiate the connection to deb.debian.org:80 (2a04:4e42:8e::644). - connect (101: Network is unreachable)
Err:4 http://deb.debian.org/debian bookworm-updates Release
  Cannot initiate the connection to deb.debian.org:80 (2a04:4e42:8e::644). - connect (101: Network is unreachable)
Ign:5 http://security.debian.org bookworm-security InRelease
Ign:5 http://security.debian.org bookworm-security InRelease
Err:6 http://security.debian.org bookworm-security Release
  Cannot initiate the connection to security.debian.org:80 (2a04:4e42:200::644). - connect (101: Network is unreachable) Cannot initiate the connection to security.debian.org:80 (2a04:4e42:400::644). - connect (101: Network is unreachable) Cannot initiate the connection to security.debian.org:80 (2a04:4e42:600::644). - connect (101: Network is unreachable) Cannot initiate the connection to security.debian.org:80 (2a04:4e42::644). - connect (101: Network is unreachable)
Reading package lists... Done
E: The repository 'http://deb.debian.org/debian bookworm Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'http://deb.debian.org/debian bookworm-updates Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'http://security.debian.org bookworm-security Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
 
Warum soll das "§$%&" sein? Ich benötige im Heimnetz kein v6.
Weil nicht mehr 2003 ist und IPv6 definitiv Vorteile hat, auf die ich hier (oversized Homelab) verzichten muss.

Nach einem Neustart habe ich das selbe verhalten:
Zeig mal ip address show. Wenn das "wegkonfigurieren" geklappt hat (und ja, sysctl sieht eigentlich korrekt aus), dann dürften keine IPv6-Adressen mehr aufgeführt werden.

Reboot sollte nicht notwendig sein, manuell anschubsen genügt: sysctl -p /etc/sysctl.conf.

Ich packe das immer in eine separate Datei, in /etc/sysctl.d/ipv6.conf.
 
Ich bin seit den 90er Jahren in der IT unterwegs und mit IPv4 groß geworden. IPv6 verstehe ich nicht und habe auch noch keinen Grund gefunden, wofür ich es im privaten Bereich brauche.

Code:
root@Nextcloud:~# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0@if28: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:cb:41:e3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.115.200/24 brd 192.168.115.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fdb7:34da:1195:654c:be24:11ff:fecb:41e3/64 scope global dynamic mngtmpaddr
       valid_lft 1322sec preferred_lft 1322sec
    inet6 fe80::be24:11ff:fecb:41e3/64 scope link
       valid_lft forever preferred_lft forever

Die Einträge sind aber in der /etc/sysctl.conf vorhanden

Auf dem Pi-hole sieht es ähnlich aus und da funktioniert das Update

Code:
root@pi-hole:~# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:4f:47:5e brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.115.111/24 brd 192.168.115.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fdb7:34da:1195:654c:be24:11ff:fe4f:475e/64 scope global dynamic mngtmpaddr
       valid_lft 1137sec preferred_lft 1137sec
    inet6 fe80::be24:11ff:fe4f:475e/64 scope link
       valid_lft forever preferred_lft forever
 
Last edited:
Ich habe mal den Befehl manuell ausgeführt und bekomme einen Fehler:

Code:
root@Nextcloud:~# sysctl -p /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
sysctl: cannot stat /proc/sys/net/ipv6/conf/tun0/disable_ipv6: No such file or directory
 
Tja, da sind offenbar noch IPv6 Adressen aktiv.
Auf dem Pi-hole sieht es ähnlich aus und da funktioniert das Update

Ich bezweifle das nicht. Aber irgendwas ist anscheinend nicht ganz "sauber"...


sysctl: cannot stat /proc/sys/net/ipv6/conf/tun0/disable_ipv6: No such file or directory
Ah! Dann raus damit (du hast vermutlich kein Tunneling per tun0 aktiv, oder?) und erneut versuchen :-)

(Also die letzte Zeile...)
 
Idee, was zeigen ein traceroute von innen LXC nach außen? von hop zu hop?
Ziel: 1.1
 
Last edited:
Ich bezweifle das nicht. Aber irgendwas ist anscheinend nicht ganz "sauber"...
Ich weiß zwar nicht, was Du da andeuten möchtest, aber mit IPv4 kenne ich mich aus.

traceroute von innen LXC nach außen?
Code:
root@Nextcloud:~# traceroute 192.168.115.1
traceroute to 192.168.115.1 (192.168.115.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * Nextcloud.fritz.box (192.168.115.200)  3097.543 ms !H

vom Pi-hole aus

Code:
traceroute to 192.168.115.1 (192.168.115.1), 30 hops max, 60 byte packets
 1  fritz.box (192.168.115.1)  0.472 ms  0.600 ms  0.682 ms


P.S. da gibt es noch einen Beitrag von heute, wo jemand mit einem neuen Container Netzwerkprobleme hat:
 
Last edited:
Update:
Ich habe den Container jetzt mal gesichert und auf einem 2. Host wieder hergestellt. Auch da das gleiche Verhalten. Es scheint also am Container und nicht an der Umgebung zu liegen.
Ich habe insgesamt 15 virtuelle Maschinen und nur dieser eine (neu erstellte) zeigt die Probleme!
 
Nun danke für das traceroute, aber das war nicht das, was ich angesprochen hatte. Aus dem lxc zum Ziel 1.1.
Rufe bitte noch auf innerhalb des lxc: ethtool eth0
Es kann aber sein, dass man das Paket noch nach installieren müsste, das geht man kann das über das Hostsystem herunterladen und in den lxc verschieben.
 
Ja jetzt ist es mir eingefallen, die lxs brauchen nun auf jeden Fall nesting=1 und ich betreibe meine immer als privilegierte Container.
 
OK, also auf die 1.1

Code:
root@Nextcloud:~# traceroute 1.1
traceroute to 1.1 (1.0.0.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * Nextcloud.fritz.box (192.168.115.200)  3104.300 ms !H

und

Code:
root@pi-hole:~# traceroute 1.1
traceroute to 1.1 (1.0.0.1), 30 hops max, 60 byte packets
 1  fritz.box (192.168.115.1)  0.585 ms  0.697 ms  0.942 ms
 2  bng1.w408.2prov.net (185.232.40.134)  6.617 ms  6.754 ms  6.785 ms
 3  2provide-ic-374466.ip.twelve99-cust.net (62.115.190.189)  6.672 ms  6.803 ms  6.849 ms
 4  hbg-b2-link.ip.twelve99.net (62.115.190.188)  9.592 ms  9.641 ms  9.672 ms
 5  cloudflare-ic-369090.ip.twelve99-cust.net (213.248.94.255)  9.826 ms  16.358 ms  9.867 ms
 6  one.one.one.one (1.0.0.1)  9.685 ms  8.631 ms  9.031 ms

Nesting wird automatisch gesetzt, wenn es ein privilegierter Container ist:

1740981781523.png
 
Tja, da sind offenbar noch IPv6 Adressen aktiv.

Ah! Dann raus damit (du hast vermutlich kein Tunneling per tun0 aktiv, oder?) und erneut versuchen :-)

Hat geklappt:

Code:
root@Nextcloud:~# sysctl -p /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Aber trotzdem:
Code:
root@Nextcloud:~# apt update
Ign:1 http://deb.debian.org/debian bookworm InRelease                                                                
Ign:2 http://deb.debian.org/debian bookworm-updates InRelease                                                        
Ign:1 http://deb.debian.org/debian bookworm InRelease                                                                
Ign:2 http://deb.debian.org/debian bookworm-updates InRelease
Ign:1 http://deb.debian.org/debian bookworm InRelease  
Ign:2 http://deb.debian.org/debian bookworm-updates InRelease
Ign:3 http://security.debian.org bookworm-security InRelease
Ign:3 http://security.debian.org bookworm-security InRelease
Ign:3 http://security.debian.org bookworm-security InRelease
Err:1 http://deb.debian.org/debian bookworm InRelease
  Could not connect to debian.map.fastlydns.net:80 (146.75.118.132). - connect (113: No route to host) Unable to connect to deb.debian.org:http:
Err:2 http://deb.debian.org/debian bookworm-updates InRelease
  Unable to connect to deb.debian.org:http:
Err:3 http://security.debian.org bookworm-security InRelease
  Could not connect to debian.map.fastlydns.net:80 (146.75.118.132). - connect (113: No route to host) Could not connect to security.debian.org:80 (151.101.194.132). - connect (113: No route to host) Could not connect to security.debian.org:80 (151.101.2.132). - connect (113: No route to host) Could not connect to security.debian.org:80 (151.101.66.132). - connect (113: No route to host) Could not connect to security.debian.org:80 (151.101.130.132). - connect (113: No route to host)
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.
W: Failed to fetch http://deb.debian.org/debian/dists/bookworm/InRelease  Could not connect to debian.map.fastlydns.net:80 (146.75.118.132). - connect (113: No route to host) Unable to connect to deb.debian.org:http:
W: Failed to fetch http://deb.debian.org/debian/dists/bookworm-updates/InRelease  Unable to connect to deb.debian.org:http:
W: Failed to fetch http://security.debian.org/dists/bookworm-security/InRelease  Could not connect to debian.map.fastlydns.net:80 (146.75.118.132). - connect (113: No route to host) Could not connect to security.debian.org:80 (151.101.194.132). - connect (113: No route to host) Could not connect to security.debian.org:80 (151.101.2.132). - connect (113: No route to host) Could not connect to security.debian.org:80 (151.101.66.132). - connect (113: No route to host) Could not connect to security.debian.org:80 (151.101.130.132). - connect (113: No route to host)
W: Some index files failed to download. They have been ignored, or old ones used instead.

Code:
root@Nextcloud:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0@if40: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:c8:11:6a brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.115.200/24 brd 192.168.115.255 scope global eth0
       valid_lft forever preferred_lft forever

Code:
root@Nextcloud:~# ping 192.168.115.1
PING 192.168.115.1 (192.168.115.1) 56(84) bytes of data.
From 192.168.115.200 icmp_seq=10 Destination Host Unreachable
From 192.168.115.200 icmp_seq=11 Destination Host Unreachable
From 192.168.115.200 icmp_seq=12 Destination Host Unreachable
From 192.168.115.200 icmp_seq=13 Destination Host Unreachable
From 192.168.115.200 icmp_seq=14 Destination Host Unreachable


Auf dem Pi-hole:

Code:
root@pi-hole:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:4f:47:5e brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.115.111/24 brd 192.168.115.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fdb7:34da:1195:654c:be24:11ff:fe4f:475e/64 scope global dynamic mngtmpaddr
       valid_lft 1237sec preferred_lft 1237sec
    inet6 fe80::be24:11ff:fe4f:475e/64 scope link
       valid_lft forever preferred_lft forever

Code:
root@pi-hole:~# ping 192.168.115.1
PING 192.168.115.1 (192.168.115.1) 56(84) bytes of data.
64 bytes from 192.168.115.1: icmp_seq=1 ttl=64 time=0.564 ms
64 bytes from 192.168.115.1: icmp_seq=2 ttl=64 time=0.482 ms
64 bytes from 192.168.115.1: icmp_seq=3 ttl=64 time=0.501 ms
64 bytes from 192.168.115.1: icmp_seq=4 ttl=64 time=0.432 ms
 
Last edited:
Ich weiß zwar nicht, was Du da andeuten möchtest, aber mit IPv4 kenne ich mich aus.
Ich war immer noch beim "IPv6 ist nur halb funktionsfähig"-Ansatz, mehr nicht. Anscheinend ist das ja nicht der Grund für dein Problem...

Aber trotzdem:

Could not connect to debian.map.fastlydns.net:80 (146.75.118.132). - connect (113: No route to host)
Immerhin wird nun über IPv4 gemeckert. Für mich ist das ein Fortschritt ;-)

root@Nextcloud:~# ping 192.168.115.1 PING 192.168.115.1 (192.168.115.1) 56(84) bytes of data. From 192.168.115.200 icmp_seq=10 Destination Host Unreachable
Ich hatte auch nicht bewußt wahrgenommen, dass das Container sind. Ich verwende zu 99% VMs, die Eigenheiten der Container kenne ich nicht gut.

Irgendwelche iptables-rules oder Router mit Paketfilter sind aber nicht im Weg, ja? Irgendwo muss ja offenbar ein Unterschied zwischen den beiden Instanzen sein.

Sorry, mir fällt aus der Ferne nichts Neues ein...
 
  • Like
Reactions: news
Irgendwelche iptables-rules oder Router mit Paketfilter sind aber nicht im Weg, ja? Irgendwo muss ja offenbar ein Unterschied zwischen den beiden Instanzen sein.
Nein, es ist eigentlich alles ohne irgendwelche besonderen Einstellungen.

Mir ist gerade noch dies aufgefallen:

Code:
root@nextcloud:~# timedatectl set-timezone Europe/Berlin
Failed to set time zone: Connection timed out

Irgendwo muss ja offenbar ein Unterschied zwischen den beiden Instanzen
Die eine ist ganz neu erstellt und die funktionierende ist schon älter.

Aber mehr fällt mir leider auch nicht mehr ein ...