[SOLVED] routes falsch, wie am Besten aufräumen?

dekiesel

Member
Apr 30, 2023
48
4
8
Hi,

Mein Proxmox-Host hat die IP 192.168.178.12 (/24, vlan=1), während meine LXCs in 10.1.101.0 (/24, vlan=101) sitzen.

Die LXCs können sich untereinander ohne Problem erreichen, allerdings kann der Host die LXCs nicht erreichen.

Beispiel:
Code:
root@pve:~# ping 10.1.101.113
PING 10.1.101.113 (10.1.101.113) 56(84) bytes of data.
From 10.1.101.132 icmp_seq=1 Destination Host Unreachable
From 10.1.101.132 icmp_seq=2 Destination Host Unreachable
From 10.1.101.132 icmp_seq=3 Destination Host Unreachable
^C
--- 10.1.101.113 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3080ms
pipe 3
root@pve:~#

Obowhl 10.1.101.113 gepingt wird, wird versucht 10.1.101.132 zu pingen. Ich denke es liegt an dieser route, aber ich bin mir nicht sicher wie sich das beheben lässt, bzw wie man das beheben sollte.

Code:
root@pve:~# ip route
default via 192.168.178.1 dev vmbr0 proto kernel onlink
default via 192.168.178.1 dev eno1 proto dhcp src 192.168.178.203 metric 1002
default via 10.1.101.1 dev fwln110i1 proto dhcp src 10.1.101.132 metric 1021 <----------Das scheint die erste passende route zu sein.
default via 10.1.101.1 dev fwln115i1 proto dhcp src 10.1.101.216 metric 1025
default via 10.1.101.1 dev fwln116i1 proto dhcp src 10.1.101.144 metric 1029
default via 10.1.101.1 dev fwln117i1 proto dhcp src 10.1.101.205 metric 1033
default via 10.1.101.1 dev fwln118i1 proto dhcp src 10.1.101.59 metric 1037
default via 10.1.101.1 dev fwln121i0 proto dhcp src 10.1.101.173 metric 1042
default via 10.1.101.1 dev fwln122i1 proto dhcp src 10.1.101.178 metric 1046
default via 10.1.101.1 dev fwln124i1 proto dhcp src 10.1.101.179 metric 1050
default via 10.1.101.1 dev fwln106i1 proto dhcp src 10.1.101.125 metric 1059
default via 10.1.101.1 dev fwln107i1 proto dhcp src 10.1.101.84 metric 1063
10.1.101.0/24 dev fwln110i1 proto dhcp scope link src 10.1.101.132 metric 1021
10.1.101.0/24 dev fwln115i1 proto dhcp scope link src 10.1.101.216 metric 1025
10.1.101.0/24 dev fwln116i1 proto dhcp scope link src 10.1.101.144 metric 1029
10.1.101.0/24 dev fwln117i1 proto dhcp scope link src 10.1.101.205 metric 1033
10.1.101.0/24 dev fwln118i1 proto dhcp scope link src 10.1.101.59 metric 1037
10.1.101.0/24 dev fwln121i0 proto dhcp scope link src 10.1.101.173 metric 1042
10.1.101.0/24 dev fwln122i1 proto dhcp scope link src 10.1.101.178 metric 1046
10.1.101.0/24 dev fwln124i1 proto dhcp scope link src 10.1.101.179 metric 1050
10.1.101.0/24 dev fwln106i1 proto dhcp scope link src 10.1.101.125 metric 1059
10.1.101.0/24 dev fwln107i1 proto dhcp scope link src 10.1.101.84 metric 1063
169.254.0.0/16 dev veth102i1 scope link src 169.254.180.166 metric 1004
169.254.0.0/16 dev veth103i1 scope link src 169.254.158.231 metric 1005
169.254.0.0/16 dev veth105i1 scope link src 169.254.104.225 metric 1006
169.254.0.0/16 dev veth123i1 scope link src 169.254.166.36 metric 1011
169.254.0.0/16 dev veth104i1 scope link src 169.254.229.120 metric 1013
169.254.0.0/16 dev veth110i1 scope link src 169.254.251.44 metric 1018
169.254.0.0/16 dev fwpr110p1 scope link src 169.254.195.90 metric 1020
169.254.0.0/16 dev veth115i1 scope link src 169.254.223.112 metric 1022
169.254.0.0/16 dev fwpr115p1 scope link src 169.254.162.139 metric 1024
169.254.0.0/16 dev veth116i1 scope link src 169.254.224.101 metric 1026
169.254.0.0/16 dev fwpr116p1 scope link src 169.254.134.127 metric 1028
169.254.0.0/16 dev veth117i1 scope link src 169.254.155.244 metric 1030
169.254.0.0/16 dev fwpr117p1 scope link src 169.254.239.90 metric 1032
169.254.0.0/16 dev veth118i1 scope link src 169.254.241.140 metric 1034
169.254.0.0/16 dev fwpr118p1 scope link src 169.254.248.2 metric 1036
169.254.0.0/16 dev veth119i1 scope link src 169.254.138.43 metric 1038
169.254.0.0/16 dev veth121i0 scope link src 169.254.217.138 metric 1039
169.254.0.0/16 dev fwpr121p0 scope link src 169.254.30.40 metric 1041
169.254.0.0/16 dev veth122i1 scope link src 169.254.73.171 metric 1043
169.254.0.0/16 dev fwpr122p1 scope link src 169.254.119.164 metric 1045
169.254.0.0/16 dev veth124i1 scope link src 169.254.192.131 metric 1047
169.254.0.0/16 dev fwpr124p1 scope link src 169.254.253.168 metric 1049
169.254.0.0/16 dev veth125i1 scope link src 169.254.94.53 metric 1051
169.254.0.0/16 dev veth106i1 scope link src 169.254.179.179 metric 1056
169.254.0.0/16 dev fwpr106p1 scope link src 169.254.157.57 metric 1058
169.254.0.0/16 dev veth107i1 scope link src 169.254.61.27 metric 1060
169.254.0.0/16 dev fwpr107p1 scope link src 169.254.169.128 metric 1062
192.168.178.0/24 dev vmbr0 proto kernel scope link src 192.168.178.12
192.168.178.0/24 dev eno1 proto dhcp scope link src 192.168.178.203 metric 1002

Ich habe diese routes nicht manuell erstellt und weiss daher nicht ob sie so aussehen sollen und ich woanders etwas falsch gemacht habe. Würde mich über Hilfe sehr freuen!
 
Last edited:
Hi,
da scheint etwas falsch zu laufen. Bitte poste die Netzwerk-Konfiguration cat /etc/network/interfaces sowie die config des containers der vom Host aus gepingt werden soll pct config <VMID>. Auch der output von iptables-save ist eventuell von Interesse.
 
Danke schon mal für deine Hilfe, Chris!

interfaces
Code:
root@pve:~# cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!


auto lo
iface lo inet loopback


iface eno1 inet manual


auto vmbr0
iface vmbr0 inet static
        address 192.168.178.12/24
        gateway 192.168.178.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094


root@pve:~#

config

Code:
root@pve:~# pct config 125
arch: amd64
cores: 1
description: # Alpine-Docker LXC%0A  ### https%3A//tteck.github.io/Proxmox/%0A  <a href='https%3A//ko-fi.com/D1D7EP4GF'><img src='https%3A//img.shields.io/badge/%E2%98%95-Buy me a coffee-red' /></a>%0A
features: keyctl=1,nesting=1
hostname: pvehostbackup
memory: 512
net1: name=eth101,bridge=vmbr0,hwaddr=B2:D0:A3:CC:1A:1F,ip=dhcp,tag=101,type=veth
onboot: 1
ostype: alpine
rootfs: local-lvm:vm-125-disk-0,size=3G
swap: 0
tags: prod
unprivileged: 1
root@pve:~#


iptables-save
Code:
root@pve:~# iptables-save
# Generated by iptables-save v1.8.9 on Thu Oct 12 06:38:54 2023
*raw
:PREROUTING ACCEPT [14526156:16061113223]
:OUTPUT ACCEPT [6772294:3738637585]
COMMIT
# Completed on Thu Oct 12 06:38:54 2023
# Generated by iptables-save v1.8.9 on Thu Oct 12 06:38:54 2023
*filter
:INPUT ACCEPT [2147:113372]
:FORWARD ACCEPT [498329:86979872]
:OUTPUT ACCEPT [4212:1235785]
:PVEFW-Drop - [0:0]
:PVEFW-DropBroadcast - [0:0]
:PVEFW-FORWARD - [0:0]
:PVEFW-FWBR-IN - [0:0]
:PVEFW-FWBR-OUT - [0:0]
:PVEFW-HOST-IN - [0:0]
:PVEFW-HOST-OUT - [0:0]
:PVEFW-INPUT - [0:0]
:PVEFW-OUTPUT - [0:0]
:PVEFW-Reject - [0:0]
:PVEFW-SET-ACCEPT-MARK - [0:0]
:PVEFW-logflags - [0:0]
:PVEFW-reject - [0:0]
:PVEFW-smurflog - [0:0]
:PVEFW-smurfs - [0:0]
:PVEFW-tcpflags - [0:0]
:veth107i1-IN - [0:0]
:veth107i1-OUT - [0:0]
-A INPUT -j PVEFW-INPUT
-A FORWARD -j PVEFW-FORWARD
-A OUTPUT -j PVEFW-OUTPUT
-A PVEFW-Drop -j PVEFW-DropBroadcast
-A PVEFW-Drop -p icmp -m icmp --icmp-type 3/4 -j ACCEPT
-A PVEFW-Drop -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A PVEFW-Drop -m conntrack --ctstate INVALID -j DROP
-A PVEFW-Drop -p udp -m multiport --dports 135,445 -j DROP
-A PVEFW-Drop -p udp -m udp --dport 137:139 -j DROP
-A PVEFW-Drop -p udp -m udp --sport 137 --dport 1024:65535 -j DROP
-A PVEFW-Drop -p tcp -m multiport --dports 135,139,445 -j DROP
-A PVEFW-Drop -p udp -m udp --dport 1900 -j DROP
-A PVEFW-Drop -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A PVEFW-Drop -p udp -m udp --sport 53 -j DROP
-A PVEFW-Drop -m comment --comment "PVESIG:83WlR/a4wLbmURFqMQT3uJSgIG8"
-A PVEFW-DropBroadcast -m addrtype --dst-type BROADCAST -j DROP
-A PVEFW-DropBroadcast -m addrtype --dst-type MULTICAST -j DROP
-A PVEFW-DropBroadcast -m addrtype --dst-type ANYCAST -j DROP
-A PVEFW-DropBroadcast -d 224.0.0.0/4 -j DROP
-A PVEFW-DropBroadcast -m comment --comment "PVESIG:NyjHNAtFbkH7WGLamPpdVnxHy4w"
-A PVEFW-FORWARD -m conntrack --ctstate INVALID -j DROP
-A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PVEFW-FORWARD -m physdev --physdev-in fwln+ --physdev-is-bridged -j PVEFW-FWBR-IN
-A PVEFW-FORWARD -m physdev --physdev-out fwln+ --physdev-is-bridged -j PVEFW-FWBR-OUT
-A PVEFW-FORWARD -m comment --comment "PVESIG:qnNexOcGa+y+jebd4dAUqFSp5nw"
-A PVEFW-FWBR-IN -m conntrack --ctstate INVALID,NEW -j PVEFW-smurfs
-A PVEFW-FWBR-IN -m physdev --physdev-out veth107i1 --physdev-is-bridged -j veth107i1-IN
-A PVEFW-FWBR-IN -m comment --comment "PVESIG:WgLYybofQfrfKJUmXuR+YjlYS00"
-A PVEFW-FWBR-OUT -m physdev --physdev-in veth107i1 --physdev-is-bridged -j veth107i1-OUT
-A PVEFW-FWBR-OUT -m comment --comment "PVESIG:6fDzkx6xArpuvbvt/iV+sFhSKvE"
-A PVEFW-HOST-IN -i lo -j ACCEPT
-A PVEFW-HOST-IN -m conntrack --ctstate INVALID -j DROP
-A PVEFW-HOST-IN -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PVEFW-HOST-IN -m conntrack --ctstate INVALID,NEW -j PVEFW-smurfs
-A PVEFW-HOST-IN -p igmp -j RETURN
-A PVEFW-HOST-IN -d 192.168.178.12/32 -i vmbr0 -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 8007 -j RETURN
-A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 8006 -j RETURN
-A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 5900:5999 -j RETURN
-A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 3128 -j RETURN
-A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 22 -j RETURN
-A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 60000:60050 -j RETURN
-A PVEFW-HOST-IN -j PVEFW-Drop
-A PVEFW-HOST-IN -j DROP
-A PVEFW-HOST-IN -m comment --comment "PVESIG:nxlgHDGYl+iKBwKydUqSBfcje8Q"
-A PVEFW-HOST-OUT -o lo -j ACCEPT
-A PVEFW-HOST-OUT -m conntrack --ctstate INVALID -j DROP
-A PVEFW-HOST-OUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PVEFW-HOST-OUT -p igmp -j RETURN
-A PVEFW-HOST-OUT -d 192.168.178.0/24 -p tcp -m tcp --dport 8006 -j RETURN
-A PVEFW-HOST-OUT -d 192.168.178.0/24 -p tcp -m tcp --dport 22 -j RETURN
-A PVEFW-HOST-OUT -d 192.168.178.0/24 -p tcp -m tcp --dport 5900:5999 -j RETURN
-A PVEFW-HOST-OUT -d 192.168.178.0/24 -p tcp -m tcp --dport 3128 -j RETURN
-A PVEFW-HOST-OUT -j RETURN
-A PVEFW-HOST-OUT -m comment --comment "PVESIG:8kxbCk6iQ0RJcmbPoyVjFXDUeEc"
-A PVEFW-INPUT -j PVEFW-HOST-IN
-A PVEFW-INPUT -m comment --comment "PVESIG:+5iMmLaxKXynOB/+5xibfx7WhFk"
-A PVEFW-OUTPUT -j PVEFW-HOST-OUT
-A PVEFW-OUTPUT -m comment --comment "PVESIG:LjHoZeSSiWAG3+2ZAyL/xuEehd0"
-A PVEFW-Reject -j PVEFW-DropBroadcast
-A PVEFW-Reject -p icmp -m icmp --icmp-type 3/4 -j ACCEPT
-A PVEFW-Reject -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A PVEFW-Reject -m conntrack --ctstate INVALID -j DROP
-A PVEFW-Reject -p udp -m multiport --dports 135,445 -j PVEFW-reject
-A PVEFW-Reject -p udp -m udp --dport 137:139 -j PVEFW-reject
-A PVEFW-Reject -p udp -m udp --sport 137 --dport 1024:65535 -j PVEFW-reject
-A PVEFW-Reject -p tcp -m multiport --dports 135,139,445 -j PVEFW-reject
-A PVEFW-Reject -p udp -m udp --dport 1900 -j DROP
-A PVEFW-Reject -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A PVEFW-Reject -p udp -m udp --sport 53 -j DROP
-A PVEFW-Reject -m comment --comment "PVESIG:h3DyALVslgH5hutETfixGP08w7c"
-A PVEFW-SET-ACCEPT-MARK -j MARK --set-xmark 0x80000000/0x80000000
-A PVEFW-SET-ACCEPT-MARK -m comment --comment "PVESIG:Hg/OIgIwJChBUcWU8Xnjhdd2jUY"
-A PVEFW-logflags -j DROP
-A PVEFW-logflags -m comment --comment "PVESIG:MN4PH1oPZeABMuWr64RrygPfW7A"
-A PVEFW-reject -m addrtype --dst-type BROADCAST -j DROP
-A PVEFW-reject -s 224.0.0.0/4 -j DROP
-A PVEFW-reject -p icmp -j DROP
-A PVEFW-reject -p tcp -j REJECT --reject-with tcp-reset
-A PVEFW-reject -p udp -j REJECT --reject-with icmp-port-unreachable
-A PVEFW-reject -p icmp -j REJECT --reject-with icmp-host-unreachable
-A PVEFW-reject -j REJECT --reject-with icmp-host-prohibited
-A PVEFW-reject -m comment --comment "PVESIG:Jlkrtle1mDdtxDeI9QaDSL++Npc"
-A PVEFW-smurflog -j DROP
-A PVEFW-smurflog -m comment --comment "PVESIG:2gfT1VMkfr0JL6OccRXTGXo+1qk"
-A PVEFW-smurfs -s 0.0.0.0/32 -j RETURN
-A PVEFW-smurfs -m addrtype --src-type BROADCAST -g PVEFW-smurflog
-A PVEFW-smurfs -s 224.0.0.0/4 -g PVEFW-smurflog
-A PVEFW-smurfs -m comment --comment "PVESIG:HssVe5QCBXd5mc9kC88749+7fag"
-A PVEFW-tcpflags -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -g PVEFW-logflags
-A PVEFW-tcpflags -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -g PVEFW-logflags-A PVEFW-tcpflags -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -g PVEFW-logflags
-A PVEFW-tcpflags -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -g PVEFW-logflags
-A PVEFW-tcpflags -p tcp -m tcp --sport 0 --tcp-flags FIN,SYN,RST,ACK SYN -g PVEFW-logflags
-A PVEFW-tcpflags -m comment --comment "PVESIG:CMFojwNPqllyqD67NeI5m+bP5mo"
-A veth107i1-IN -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A veth107i1-IN -j ACCEPT
-A veth107i1-IN -j PVEFW-Drop
-A veth107i1-IN -j DROP
-A veth107i1-IN -m comment --comment "PVESIG:16M2Hc/7Z9bfWyvgVsUfUb2jAhA"
-A veth107i1-OUT -p udp -m udp --sport 68 --dport 67 -g PVEFW-SET-ACCEPT-MARK
-A veth107i1-OUT -m mac ! --mac-source 16:09:17:f7:ec:34 -j DROP
-A veth107i1-OUT -j MARK --set-xmark 0x0/0x80000000
-A veth107i1-OUT -p udp -m udp --dport 53 -g PVEFW-SET-ACCEPT-MARK
-A veth107i1-OUT -p tcp -m tcp --dport 53 -g PVEFW-SET-ACCEPT-MARK
-A veth107i1-OUT -d 10.1.101.5/32 -p tcp -m tcp --dport 8883 -g PVEFW-SET-ACCEPT-MARK
-A veth107i1-OUT -d 10.1.101.5/32 -p tcp -m tcp --dport 1883 -g PVEFW-SET-ACCEPT-MARK
-A veth107i1-OUT -j DROP
-A veth107i1-OUT -g PVEFW-SET-ACCEPT-MARK
-A veth107i1-OUT -m comment --comment "PVESIG:OrCCY3pfo8qgzdGs04gmL4C0/s8"
COMMIT
# Completed on Thu Oct 12 06:38:54 2023
root@pve:~#
 
Die Netzwerkkonfiguration schaut soweit schon mal nicht so schlecht aus. Allerdings haben host und container laut dieser 2 verschiedene private subnetze, in welche per default nicht gerouted wird. Nun wurden aber (vermultich vom dhcp client am PVE host?) all diese Routen eingetragen? Hat der PVE host auch via dhcp eine IP im 10.1.101.0/24 subnetz erhalten? ip addr sollte darüber Aufschluss geben. Ich vermute mal das war so nicht beabsichtigt.

Eventuell macht es mehr Sinn für das container Netzwerk eine dedizierte bridge einzurichten und dort auch explizit die IP des hosts statisch zu setzen sowie den DHCP client am host zu entfernen.

Die Routen kann man zunächst mal via ip route del ..., e.g. ip route del default via 10.1.101.1 dev fwln110i1 ecc. entfernen. Falls der dhcp client am host entfernt wurde, sollten auch nach einem reboot die Routen nicht mehr eingetragen werden.
 
Die Netzwerkkonfiguration schaut soweit schon mal nicht so schlecht aus. Allerdings haben host und container laut dieser 2 verschiedene private subnetze, in welche per default nicht gerouted wird. Nun wurden aber (vermultich vom dhcp client am PVE host?) all diese Routen eingetragen? Hat der PVE host auch via dhcp eine IP im 10.1.101.0/24 subnetz erhalten? ip addr sollte darüber Aufschluss geben. Ich vermute mal das war so nicht beabsichtigt.

Eventuell macht es mehr Sinn für das container Netzwerk eine dedizierte bridge einzurichten und dort auch explizit die IP des hosts statisch zu setzen sowie den DHCP client am host zu entfernen.

Die Routen kann man zunächst mal via ip route del ..., e.g. ip route del default via 10.1.101.1 dev fwln110i1 ecc. entfernen. Falls der dhcp client am host entfernt wurde, sollten auch nach einem reboot die Routen nicht mehr eingetragen werden.
Der Container hat keine IP im 10.1.101.0/24 Netz, er soll eine IP im 10.1.100.0/24 (100 statt 101) Netz bekommen sobald ich mit den Umbauarbeiten fertig bin.
Als ich Proxmox aufgesetzt hab kam mir der Gedanke, dass jetzt eine gute Gelegenheit wäre das Netz auf verschiedene VLANs zu verteilen. Das 192.168.178.1/24 Netz soll dann nicht mehr benutzt werden.

Ich dachte es würde am meisten Sinn machen den Containern keinen Zugriff auf den Host zu geben, heisst Host und Container in getrennten VLANs zu halten. Anders herum soll natürlich funktionieren. Oder macht das keinen Sinn?

Momentan bekommt der Host seine IP über den Router statisch zugewiesen. Auf die Art kennt der Router die Hostnames und kann die Auflösung (.lan) selbst machen.

Sollte ich also zwei dedizierte bridges anlegen (eine für den Host und eine für die Container)?
 
Der Container hat keine IP im 10.1.101.0/24 Netz, er soll eine IP im 10.1.100.0/24 (100 statt 101) Netz bekommen sobald ich mit den Umbauarbeiten fertig bin.
Als ich Proxmox aufgesetzt hab kam mir der Gedanke, dass jetzt eine gute Gelegenheit wäre das Netz auf verschiedene VLANs zu verteilen. Das 192.168.178.1/24 Netz soll dann nicht mehr benutzt werden.

Ich dachte es würde am meisten Sinn machen den Containern keinen Zugriff auf den Host zu geben, heisst Host und Container in getrennten VLANs zu halten. Anders herum soll natürlich funktionieren. Oder macht das keinen Sinn?

Momentan bekommt der Host seine IP über den Router statisch zugewiesen. Auf die Art kennt der Router die Hostnames und kann die Auflösung (.lan) selbst machen.

Sollte ich also zwei dedizierte bridges anlegen (eine für den Host und eine für die Container)?
WIe gesagt, erster schritt sollte meiner Meinung nach sein dhcp client am PVE host zu entfernen und die notwendigen IPs statisch zu hinterlegen, dann sollten auch nicht die ganzen Routen eingetragen werden. Es sollte nur ein default gateway vorhanden sein
 
WIe gesagt, erster schritt sollte meiner Meinung nach sein dhcp client am PVE host zu entfernen und die notwendigen IPs statisch zu hinterlegen, dann sollten auch nicht die ganzen Routen eingetragen werden. Es sollte nur ein default gateway vorhanden sein
Vielen Dank! Ich werde mir das nötige anlesen und mich mit hoffentlich positivem Ergebnis melden. Leider erst Ende nächster Woche da ich unterwegs bin.
 
WIe gesagt, erster schritt sollte meiner Meinung nach sein dhcp client am PVE host zu entfernen und die notwendigen IPs statisch zu hinterlegen, dann sollten auch nicht die ganzen Routen eingetragen werden. Es sollte nur ein default gateway vorhanden sein
Nach viel lesen bin ich hierauf gekommen für /etc/network/interfaces:

Code:
auto lo
iface lo inet loopback


auto eno1
iface eno1 inet static
    address 192.168.178.12
    netmask 255.255.255.0
    gateway 192.168.178.1




auto vmbr0
iface vmbr0 inet static
        address 10.1.101.12/24
        gateway 10.1.101.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

War das so gemeint? Ich möchte vermeiden den Host abzuschiessen, daher die Nachfrage. Danke nochmal für die Hilfe!
 
Nach viel lesen bin ich hierauf gekommen für /etc/network/interfaces:

Code:
auto lo
iface lo inet loopback


auto eno1
iface eno1 inet static
    address 192.168.178.12
    netmask 255.255.255.0
    gateway 192.168.178.1




auto vmbr0
iface vmbr0 inet static
        address 10.1.101.12/24
        gateway 10.1.101.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

War das so gemeint? Ich möchte vermeiden den Host abzuschiessen, daher die Nachfrage. Danke nochmal für die Hilfe!
Wurde DHCP am host deaktiviert? Es sollte nur ein default gateway konfiguriert werden. Mir ist nicht ganz klar wie das Netzwerk ausschaut, vielleicht ist ein NAT eher das, was du konfigurieren möchtest? Ein Beispiel dafür ohne vlans findest du z.B. hier https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_network_masquerading
 
Wurde DHCP am host deaktiviert? Es sollte nur ein default gateway konfiguriert werden. Mir ist nicht ganz klar wie das Netzwerk ausschaut, vielleicht ist ein NAT eher das, was du konfigurieren möchtest? Ein Beispiel dafür ohne vlans findest du z.B. hier https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_network_masquerading
Ich dachte iface eno1 inet static deaktiviert dhcp am host? Der Router weist dem Host auch keine IP zu (Die DHCP Client Liste enthält den Host nicht).

NAT möchte ich nicht verwenden, da ich dann den Traffic am Router nicht in die jeweiligen Firewall Zones einordnen kann.

1697622047915.png
Ich hoffe dieses Diagramm drückt aus was ich bisher aufgesetzt habe. Der Pve Host ist unten links und hat aktuell die IP 192.168.178.12 (soll zukünftig in VLAN 100 und IP 10.1.100.12 bekommen, aber das hat mit dem aktuellen Problem nichts zu tun, ich wollte es nur erwähnen.

Um Firewall Regeln am Router erstellen zu können sind die Netze jeweils in Firewall Zones zusammengefasst. "IOT" und "No Internet" sind zb in einer Zone die ich LessSafe genannt habe und die beispielsweise VLAN1 und VLAN100 nicht erreichen dürfen.

Pve Host soll Mitglied in VLAN1 (irgendwann 100) sein, während alle VMs und LXCs in VLAN 101 sein sollen.
 
Ich habe interfaces folgendermassen geändert:

Code:
auto lo
iface lo inet loopback


iface eno1 inet manual


auto vmbr0.100
iface vmbr0.100 inet static
        address  10.1.100.12/24
        gateway  10.1.100.1


auto vmbr0
iface vmbr0 inet static
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Ich kann den Host auf dieser Adresse erreichen, aber das Problem bleibt bestehen, nur in der Range 10.1.100.0/24

Code:
root@pve:/etc/network# ip route
default via 10.1.100.1 dev vmbr0.100 proto dhcp src 10.1.100.58 metric 1004
default via 10.1.101.1 dev fwln107i1 proto dhcp src 10.1.101.84 metric 1011
default via 10.1.101.1 dev fwln106i1 proto dhcp src 10.1.101.125 metric 1018
default via 10.1.101.1 dev fwln110i1 proto dhcp src 10.1.101.132 metric 1022
default via 10.1.101.1 dev fwln115i1 proto dhcp src 10.1.101.216 metric 1026
default via 10.1.101.1 dev fwln116i1 proto dhcp src 10.1.101.144 metric 1030
default via 10.1.101.1 dev fwln117i1 proto dhcp src 10.1.101.205 metric 1034
default via 10.1.101.1 dev fwln118i1 proto dhcp src 10.1.101.59 metric 1038
default via 10.1.101.1 dev fwln121i0 proto dhcp src 10.1.101.173 metric 1043
default via 10.1.101.1 dev fwln122i1 proto dhcp src 10.1.101.178 metric 1047
default via 10.1.101.1 dev fwln124i1 proto dhcp src 10.1.101.179 metric 1051
10.1.100.0/24 dev vmbr0.100 proto dhcp scope link src 10.1.100.58 metric 1004
10.1.101.0/24 dev fwln107i1 proto dhcp scope link src 10.1.101.84 metric 1011
10.1.101.0/24 dev fwln106i1 proto dhcp scope link src 10.1.101.125 metric 1018
10.1.101.0/24 dev fwln110i1 proto dhcp scope link src 10.1.101.132 metric 1022
10.1.101.0/24 dev fwln115i1 proto dhcp scope link src 10.1.101.216 metric 1026
10.1.101.0/24 dev fwln116i1 proto dhcp scope link src 10.1.101.144 metric 1030
10.1.101.0/24 dev fwln117i1 proto dhcp scope link src 10.1.101.205 metric 1034
10.1.101.0/24 dev fwln118i1 proto dhcp scope link src 10.1.101.59 metric 1038
10.1.101.0/24 dev fwln121i0 proto dhcp scope link src 10.1.101.173 metric 1043
10.1.101.0/24 dev fwln122i1 proto dhcp scope link src 10.1.101.178 metric 1047
10.1.101.0/24 dev fwln124i1 proto dhcp scope link src 10.1.101.179 metric 1051
169.254.0.0/16 dev eno1 scope link src 169.254.247.108 metric 1002
169.254.0.0/16 dev veth102i1 scope link src 169.254.179.32 metric 1005
169.254.0.0/16 dev veth103i1 scope link src 169.254.22.127 metric 1006
.....snip....

Mir ist aufgefallen, dass eno1 (anscheinend) eine link-local adresse bekommt, ist das so gewünscht? Sollte ich eno1 eine statische Adresse in VLAN 100 geben? Ist das das was du mit "DHCP deaktivieren" gemeint hast?

Code:
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether b0:0c:d1:62:a6:19 brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6
    inet 169.254.247.108/16 brd 169.254.255.255 scope global noprefixroute eno1
       valid_lft forever preferred_lft forever

Mir ist ausserdem aufgefallen, dass vmbr0.100 zwei Adressen bekommen hat, 10.1.100.12 und 10.1.100.58, das ist so nicht gewollt, oder?

Code:
4: vmbr0.100@vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b0:0c:d1:62:a6:19 brd ff:ff:ff:ff:ff:ff
    inet 10.1.100.12/24 scope global vmbr0.100
       valid_lft forever preferred_lft forever
    inet 10.1.100.58/24 brd 10.1.100.255 scope global secondary dynamic noprefixroute vmbr0.100
       valid_lft 84472sec preferred_lft 73672sec
 
Ich kann den Host auf dieser Adresse erreichen, aber das Problem bleibt bestehen, nur in der Range 10.1.100.0/24
Ja, es wurde ja auch nur eine IP Addresse in diesem Subnet vergeben, wenn weitere gebrauch werden müssen diese explizit ebenfalls statisch gesetzt werden.
Mir ist aufgefallen, dass eno1 (anscheinend) eine link-local adresse bekommt, ist das so gewünscht? Sollte ich eno1 eine statische Adresse in VLAN 100 geben? Ist das das was du mit "DHCP deaktivieren" gemeint hast?
Irgendwas ist da noch konfiguriert, was sowohl mit den Routen als auch mit deinen IP Adressen interferiert. Wurde eventuell systemd-networkd oder networkmanager installiert und aktiviert? Diese sollten nicht verwendet werden.
Mir ist ausserdem aufgefallen, dass vmbr0.100 zwei Adressen bekommen hat, 10.1.100.12 und 10.1.100.58, das ist so nicht gewollt, oder?
Ditto, auch das stammt nicht von der Netzwerkkonfiguration welche unter /etc/network/interfaces gemacht wurde.
 
Code:
Irgendwas ist da noch konfiguriert, was sowohl mit den Routen als auch mit deinen IP Adressen interferiert. Wurde eventuell systemd-networkd oder networkmanager installiert und aktiviert?

So weit ich sehen kann sind weder systemd-networkd noch networkmanager installiert:

Code:
root@pve:~# systemctl --type=service |grep -i netw
  lxc-net.service                                                                           loaded active exited  LXC network bridge setup
  networking.service                                                                        loaded active exited  Network initialization
  pvenetcommit.service                                                                      loaded active exited  Commit Proxmox VE network changes
root@pve:~#

Laut syslog bestellt dhcpcd das lease und die routes:

Code:
root@pve:/var/lib/dhcpcd# grep dhcpcd /var/log/syslog
...snip...
2023-10-19T17:41:42.687037+02:00 pve dhcpcd[1011]: eno1: pid 97920 deleted IP address 169.254.220.225/16
2023-10-19T17:41:42.687318+02:00 pve dhcpcd[1011]: eno1: deleting route to 169.254.0.0/16
2023-10-19T17:41:42.697433+02:00 pve dhcpcd[1011]: eno1: probing for an IPv4LL address
2023-10-19T17:41:43.014355+02:00 pve dhcpcd[1011]: vmbr0.100: pid 97920 deleted IP address 10.1.100.58/24
2023-10-19T17:41:43.014416+02:00 pve dhcpcd[1011]: vmbr0.100: deleting route to 10.1.100.0/24
2023-10-19T17:41:43.014479+02:00 pve dhcpcd[1011]: vmbr0.100: deleting default route via 10.1.100.1
2023-10-19T17:41:43.026518+02:00 pve dhcpcd[1011]: vmbr0.100: rebinding lease of 10.1.100.58
2023-10-19T17:41:43.045826+02:00 pve dhcpcd[1011]: vmbr0.100: probing address 10.1.100.58/24
2023-10-19T17:41:48.070019+02:00 pve dhcpcd[1011]: vmbr0.100: leased 10.1.100.58 for 86400 seconds
2023-10-19T17:41:48.070301+02:00 pve dhcpcd[1011]: vmbr0.100: adding route to 10.1.100.0/24
2023-10-19T17:41:48.070556+02:00 pve dhcpcd[1011]: vmbr0.100: adding default route via 10.1.100.1
2023-10-19T17:41:48.104090+02:00 pve dhcpcd[1011]: eno1: using IPv4LL address 169.254.32.214
2023-10-19T17:41:48.104467+02:00 pve dhcpcd[1011]: eno1: adding route to 169.254.0.0/16
...snip...

Hier ist die dhcpcd.conf

Code:
root@pve:~# cat /etc/dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.


# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel


# Inform the DHCP server of our hostname for DDNS.
#hostname


# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid


# Persist interface configuration when dhcpcd exits.
persistent


# vendorclassid is set to blank to avoid sending the default of
# dhcpcd-<version>:<os>:<machine>:<platform>
vendorclassid


# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu


# Request a hostname from the network
option host_name


# Most distributions have NTP support.
#option ntp_servers


# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit


# A ServerID is required by RFC2131.
require dhcp_server_identifier


# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

dhcpcd soll installiert sein so weit ich lesen kann, korrekt?

Was interessant ist, die eigentliche IP tauch nur wegen des Knotennames in syslog auf:

Code:
root@pve:~# grep 10.1.100.12 /var/log/syslog
2023-10-19T16:25:25.754537+02:00 pve pmxcfs[1290]: [main] notice: resolved node name 'pve' to '10.1.100.12' for default node IP address
2023-10-19T16:25:25.754593+02:00 pve pmxcfs[1290]: [main] notice: resolved node name 'pve' to '10.1.100.12' for default node IP address
root@pve:~#

dhcpcd scheint wirklich der Übeltäter zu sein

Code:
root@pve:/var/lib/dhcpcd# cat vmbr0.100.lease |dhcpcd -U -4
ip_address=10.1.100.58
subnet_cidr=24
network_number=10.1.100.0
subnet_mask=255.255.255.0
routers=10.1.100.1
domain_name_servers=10.1.99.2 10.1.99.3
domain_name=lan
broadcast_address=10.1.100.255
dhcp_lease_time=86400
dhcp_message_type=5
dhcp_server_identifier=10.1.100.1
dhcp_renewal_time=43200
dhcp_rebinding_time=75600
root@pve:/var/lib/dhcpcd#

Die Frage ist wie kann ich dhcpcd überzeugen hier keine IP zu leasen?
 
Last edited:
Aller guten Dinge sind 100. Wie es scheint soll dhcpcd doch nicht installiert sein. Nach einem

Code:
systemctl stop dhcpcd.service
systemctl disable dhcpcd.service

sieht die routing tabelle jetzt so aus


Code:
root@pve:~# ip r
default via 10.1.100.1 dev vmbr0.100 proto kernel onlink
10.1.100.0/24 dev vmbr0.100 proto kernel scope link src 10.1.100.12
root@pve:~#


So weit scheint alles zu funktionieren, ich werde die nächsten Tage die Dienste testen, aber bisher kann ich vom host alle LCXs/VMs erreichen und die Dienste scheinen auch zu tun was sie sollen.

Danke für deine geduldige Hilfe, @Chris !!!!!!
 
Last edited:
  • Like
Reactions: Chris
Aller guten DInge sind 100. Wie es scheint soll dhcpcd doch nicht installiert sein. Nach einem

Code:
systemctl stop dhcpcd.service
systemctl disable dhcpcd.service

sieht die routing tabelle jetzt so aus

Code:
root@pve:~# ip r
default via 10.1.100.1 dev vmbr0.100 proto kernel onlink
10.1.100.0/24 dev vmbr0.100 proto kernel scope link src 10.1.100.12
root@pve:~#
[ICODE]

So weit scheint alles zu funktionieren, ich werde die nächsten Tage die Dienste testen, aber bisher kann ich vom host alle LCXs/VMs erreichen und die Dienste scheinen auch zu tun was sie sollen.

Danke für deine geduldige Hilfe, [USER=65524]@Chris[/USER] !!!!!!
Freut mich zu hören, dass nun alles funktioniert! Also doch wie initial bereits vermutet der DHCP client. Bitte den thread als solved markieren, sodass andere schneller zu einer Lösung finden können, danke.
 
  • Like
Reactions: dekiesel

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!

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!