LXC/VM Netzwerk Problem mit default Config

R

R2D2

Member
Aug 9, 2021
10
0
6
Hallo zusammen,

bin neu hier im Forum und freue mich auf die zusammen Arbeit:).

Ich habe mir ein kleines HomeLab aufgebaut, das bisher über ein NAT in Proxmox funktioniert hat um einen Problem zu umgehen das schon seit Anfang an bestand. Nun wollte ich auf VLAN umbaun, im Zuge dessen ist mir das Problem jetzt wieder auf die Füße gefallen.

Da die Default Config schon nicht funktioniert, möchte ich erstmal das Grundproblem finden bevor ich auf VLAN umbaue.

Das Problem stellt sich fogendermaßen dar:

Host -> Router Extern im Netzwerk (ping ok) (OpenWRT o. FritzBox)

Host -> LXC (ping ok)
LXC -> Host (ping ok)

Host -> VM (ping ok)
VM -> Host (ping ok)

VM/LXC untereinander auch kein Problem

LXC oder VM haben eine feste IP, da DHCP auch nicht funktioniert. Der Ping geht raus und wird auch vom PC beantwortet, aber kommt nicht mehr zurück (siehe unten).

Firewall ist im moment aus.

Vielleicht hattet ihr so ein Problem schon mal, ich hab bisher für dieses Problem sowohl im deutschen als auch im englischen nichts gefunden.

Danke fürs lesen und ich wünsche euch allen einen schönen Wochenstart.



Im anschluss noch ein Paar Config Dateien:


Code: 
root@server01:~# cat /etc/network/interfaces

auto lo
iface lo inet loopback

iface enp5s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.5.254/24
        gateway 192.168.5.1
        bridge-ports enp5s0
        bridge-stp off
        bridge-fd 0



Code: 
root@server01:~# cat /etc/pve/lxc/105.conf 
arch: amd64
cores: 1
hostname: test5
memory: 512
net0: name=eth0,bridge=vmbr0,gw=192.168.5.1,hwaddr=76:48:97:DE:AE:EC,ip=192.168.5.105/24,ip6=auto,type=veth
ostype: ubuntu
rootfs: local-zfs:subvol-105-disk-0,size=8G
swap: 512


Code: 
root@server01:~# 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 
       valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
    link/ether XX:XX:XX:XX:36:7e brd ff:ff:ff:ff:ff:ff
3: wlo1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether XX:XX:XX:XX:b2:ee brd ff:ff:ff:ff:ff:ff
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether XX:XX:XX:XX:36:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.254/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::1ac0:4dff:fe81:367e/64 scope link 
       valid_lft forever preferred_lft forever
5: tap204i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
    link/ether 36:92:1c:24:b0:81 brd ff:ff:ff:ff:ff:ff
6: veth105i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether fe:76:fb:a9:16:d6 brd ff:ff:ff:ff:ff:ff link-netnsid 0



Code: 
root@test5:~# ping 192.168.5.21
PING 192.168.5.21 (192.168.5.21) 56(84) bytes of data.
From 192.168.5.105 icmp_seq=9 Destination Host Unreachable
From 192.168.5.105 icmp_seq=10 Destination Host Unreachable
From 192.168.5.105 icmp_seq=11 Destination Host Unreachable
^C
--- 192.168.5.21 ping statistics ---
12 packets transmitted, 0 received, +3 errors, 100% packet loss, time 11270ms
pipe 3


Code: 
root@XX(192.168.5.21):~# tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:47:08.809719 IP 192.168.5.105 > XX.lan: ICMP echo request, id 6, seq 1, length 64
22:47:08.809892 IP XX.lan > 192.168.5.105: ICMP echo reply, id 6, seq 1, length 64
22:47:09.839271 IP 192.168.5.105 > XX.lan: ICMP echo request, id 6, seq 2, length 64
22:47:09.839341 IP XX.lan > 192.168.5.105: ICMP echo reply, id 6, seq 2, length 64
22:47:10.862759 IP 192.168.5.105 > XX.lan: ICMP echo request, id 6, seq 3, length 64
22:47:10.862823 IP XX.lan > 192.168.5.105: ICMP echo reply, id 6, seq 3, length 64
22:47:11.886286 IP 192.168.5.105 > XX.lan: ICMP echo request, id 6, seq 4, length 64
22:47:11.886354 IP XX.lan > 192.168.5.105: ICMP echo reply, id 6, seq 4, length 64
22:47:12.909734 IP 192.168.5.105 > XX.lan: ICMP echo request, id 6, seq 5, length 64
22:47:12.909802 IP XX.lan > 192.168.5.105: ICMP echo reply, id 6, seq 5, length 64
22:47:13.933225 IP 192.168.5.105 > XX.lan: ICMP echo request, id 6, seq 6, length 64
22:47:13.933288 IP XX.lan > 192.168.5.105: ICMP echo reply, id 6, seq 6, length 64
22:47:14.956714 IP 192.168.5.105 > XX.lan: ICMP echo request, id 6, seq 7, length 64
22:47:14.956782 IP XX.lan > 192.168.5.105: ICMP echo reply, id 6, seq 7, length 64
22:47:15.980193 IP 192.168.5.105 > XX.lan: ICMP echo request, id 6, seq 8, length 64
22:47:15.980256 IP XX.lan > 192.168.5.105: ICMP echo reply, id 6, seq 8, length 64
^C
16 packets captured
16 packets received by filter
0 packets dropped by kernel
 
Ich habe in deiner Beschreibung nicht genau verstanden, wer zwischen den VLANs routet. Der Router (Fritz Box) muss natürlich auch die Netze der VLANs kennen und das entsprechende Gateway.
 
Hallo SkyDriver,

vorerst geht es nicht um die VLANs, sondern das Problem an sich. Ich kann mit der default Config so wie es in der Doku steht, zwar aus dem LXC raus pingen, aber der Ping kommt nicht mehr zurück.

Das Gateway wäre eingl. OpenWRT auf einem Pi, aber zum testen habe ich eine Fritz Box(mit FritzOS) benutzt, ohne VLANs.

Hierbei ist mir aufgefallen das DHCP mit der Fritzbox funktioniert, der Ping wir auch von der gegenseite beantwortet aber kommt nicht zurück zum LXC.

Vielleicht verstehst du jetzt besser was ich meine.
 
Wenn der Ping nicht ankommt, kann ja eigentlich nur eine Firewall filtern. Hast du alle Firewalls kontrolliert?
Was mir auch schon aufgefallen ist, bei Proxmox muss man manchmal die Firewall komplett aus machen.
Ich habe das Problem bei meinem Backup Target, auch wenn die Ports für NFS frei gegeben sind funktioniert der Zugriff nicht. Erst wenn die Firewall komplett aus ist geht wieder alles.

Gruß Falk
 
Dachtet ich mir auch schon, aber Firewall steht überall auf disable

- Rechenzentrum: Firewall: no
- Knoten: Firewall: no
- LXC oder VM: Firewall: no
- Im LXC oder VM: Firewall: inactive
 
Hast du mal PVE 7.0 oder PVE 6.4 mit dem optionalem 5.11 Kernel versucht? Die Intel i225 hatte soweit ich weiß das Problem, dass die nicht mit dem Treiber vom 5.4 Kernel lief. Also prinzipiell geht die NIC schon für den Host selbst, aber die NIC kann nicht mit einer Bridge verbunden werden.
Das würde dann auch erklären, warum da ein NAT funktionierte, weil dort die Bridge ja nicht direkt mit der NIC verbunden ist sondern zu der unverbundenen Bridge nur vom Host geroutet wird.

Wenn ich da richtig liege sollte alles laufen sobald du den 5.11 Kernel installierst:
Code: 
apt update
apt install pve-kernel-5.11
reboot
 
  • Like
Reactions: R2D2
Dunuin said:
Wenn ich da richtig liege sollte alles laufen sobald du den 5.11 Kernel installierst:
Code: 
apt update
apt install pve-kernel-5.11
reboot
Click to expand...

Hallo Dunuin,

danke für die Info, das ist genau das Problem.

Ich benutze die PVE 6.4 (siehe unten).
Mit dem Kernel Update von 5.4 auf 5.11, konnte das Problem behoben werden.

Allerdings funktioniert in meinem Fall, "VLAN aware" nicht und ich muss den umweg über eine Linux Bridge gehen. Im moment habe ich für jedes VLAN eine eigene Bridge anlegt und funktioniert auch.

Wenn ich einem LXC einen VLAN Tag geben und für vmbr0 "VLAN aware" benutze, wird anschienend der Tag nicht weiter gegeben. Vielleicht ein weiterer Bug?


PVE Version vor dem Update:

Code: 
root@server01:~# pveversion
pve-manager/6.4-13/9f411e79 (running kernel: 5.4.128-1-pve)

PVE Version nach dem Update:

Code: 
root@server01:~# pveversion
pve-manager/6.4-13/9f411e79 (running kernel: 5.11.22-2-pve)
 
R2D2 said:
Wenn ich einem LXC einen VLAN Tag geben und für vmbr0 "VLAN aware" benutze, wird anschienend der Tag nicht weiter gegeben. Vielleicht ein weiterer Bug?
Click to expand...
Das könnte natürlich sein. Hast du nochmal nachgeguckt ob da auch wirklich folgendes an der Bridge in /etc/network/interfaces steht?
Code: 
        bridge-vlan-aware yes
        bridge-vids 2-4094
Erstes ist wegen vlan aware und letzteres gibt an, welche VLAN IDs die bridge denn leiten darf (im Beispiel alles an VLANs zwischen 2 und 4096).
Ich weiß nicht ob da ifupdown2 hilft, aber würde das sicherheitshalber mal installieren falls du das noch nicht getan hast und bei dir noch ifupdown läuft. Und vielleicht nochmal ein Reboot nach dem Ändern der Konfig versuchen, dass da Linux auch wirklich die neuen Konfigurationen nutzt.
 
Ifupdown2 ist schon installiert, Config passt eigl. auch + reboot. Und vor dem Update konnte ich zumindest einen Ping absetzten aber er kam nicht zurück im Container an, jetzt ist das nicht mehr möglich.

Code: 
root@server01:~# cat /etc/network/interfaces


auto lo
iface lo inet loopback

iface enp5s0 inet manual

auto vmbr0
iface vmbr0 inet manual
        bridge-ports enp5s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back