merkwürtiges Netzwerkproblem beim Zugriff auf PVE

[garfield2008]

Moin,

ich habe hier folgende Konstellation

Cluster
Open vSwitch
vmbr0 für Management
an vmbr0 bond0 untagget an Switch
keine weiteren vlans
vmbr1 für VMs
van vmbr1 band1 vlan1 untagget und vlan 10 bis vlan30 tagget an Switch

das Netz für die Operators ist das vlan1
das Management Netz ist das vlan99
zwischen vlan1 und vlan99 ist am Switch eine Firewall (im Moment allow all)

Und nun das merkwürdige.

Von einen PC aus kann man im vlan1 den Proxmox Cluster per HTTPs und SSH verwalten.
Von einer VM an vmbr1 vlan1 kann man den Proxmox Cluster anpingen aber SSH und HTTPs ergeben nur einen Timeout. Die VM erreicht aber per SSH oder HTTPs alle anderen Geräte (z.B. Switche) im vlan99

Irgendwer eine Idee

 

[Bu66as]

Hallo @garfield2008,

Zwei Sachen zum Eingrenzen:

1. Kann die VM den PVE-Node erreichen, auf dem sie NICHT läuft?
Also wenn die VM auf Node1 liegt: kommt sie per SSH/HTTPS auf Node2 und Node3? Das würde klären, ob es ein Hairpin-Problem ist (Traffic geht über bond1 raus zum Switch und müsste über bond0 wieder auf denselben Host zurück).

2. Ist die PVE-Firewall aktiv?

pve-firewall status

Falls ja: Die PVE-Firewall greift auch auf Host-Ebene und könnte TCP von bestimmten Interfaces/Netzen blocken, während ICMP durchgelassen wird.

3. tcpdump auf dem PVE-Host:

tcpdump -ni vmbr0 host <VM-IP> and port 8006

Damit siehst du, ob die TCP-SYN-Pakete überhaupt auf vmbr0 ankommen und ob SYN-ACKs rausgehen. Wenn SYN ankommt aber kein SYN-ACK → Firewall/iptables auf dem Host. Wenn SYN-ACK rausgeht aber nie ankommt → Switch-Firewall oder Rückweg-Problem.

4. Direkt auf dem Host prüfen ob nftables/iptables Regeln greifen:

nft list ruleset | grep -i drop
iptables -L -n -v

Mein Verdacht geht Richtung PVE-Firewall oder Hairpin-Problem mit OVS — Ping funktioniert weil ICMP stateless ist, TCP scheitert weil die Rückroute anders läuft als der Hinweg.

 

[garfield2008]

zu 1.
nein. Und es wird noch verrückter. Gerade eben erreiche ich von der VM aus alle PVE und PBS im besagte Netz per SSH, aber nicht per HTTPs oder SFTP.

zu 2.
PVE Firewall ist aus

zu 3.

192.168.20.175 ist die VM und befindet sich auf pve01

root@pve11:~# tcpdump -ni mgnt0 host 192.168.20.175 and port 8006
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on mgnt0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:42:44.208755 IP 192.168.20.175.49574 > 192.168.99.121.8006: Flags [.], seq 3447363900:3447363901, ack 1673786765, win 8400, length 1
21:42:44.208775 IP 192.168.99.121.8006 > 192.168.20.175.49574: Flags [.], ack 1, win 61, options [nop,nop,sack 1 {0:1}], length 0
21:42:46.593411 IP 192.168.99.121.8006 > 192.168.20.175.49587: Flags [F.], seq 1693906237, ack 367888851, win 62, length 0
21:42:46.594817 IP 192.168.20.175.49587 > 192.168.99.121.8006: Flags [.], ack 1, win 1050, length 0
21:42:46.595183 IP 192.168.20.175.49587 > 192.168.99.121.8006: Flags [F.], seq 1798, ack 1, win 1050, length 0
21:42:46.595193 IP 192.168.99.121.8006 > 192.168.20.175.49587: Flags [.], ack 1, win 62, options [nop,nop,sack 1 {1798:1799}], length 0
21:42:47.807952 IP 192.168.20.175.49588 > 192.168.99.121.8006: Flags [S], seq 28745070, win 62720, options [mss 8960,nop,wscale 8,nop,nop,sackOK], length 0
21:42:47.807974 IP 192.168.99.121.8006 > 192.168.20.175.49588: Flags [S.], seq 3972412763, ack 28745071, win 62720, options [mss 8960,nop,nop,sackOK,nop,wscale 10], length 0
21:42:47.809771 IP 192.168.20.175.49588 > 192.168.99.121.8006: Flags [.], ack 1, win 1050, length 0
21:42:47.812705 IP 192.168.20.175.49589 > 192.168.99.121.8006: Flags [S], seq 2259450715, win 62720, options [mss 8960,nop,wscale 8,nop,nop,sackOK], length 0
21:42:47.812716 IP 192.168.99.121.8006 > 192.168.20.175.49589: Flags [S.], seq 1760271645, ack 2259450716, win 62720, options [mss 8960,nop,nop,sackOK,nop,wscale 10], length 0
21:42:47.814147 IP 192.168.20.175.49589 > 192.168.99.121.8006: Flags [.], ack 1, win 1050, length 0
21:42:52.811352 IP 192.168.99.121.8006 > 192.168.20.175.49588: Flags [F.], seq 1, ack 1, win 62, length 0
21:42:52.812804 IP 192.168.20.175.49588 > 192.168.99.121.8006: Flags [.], ack 2, win 1050, length 0

zu 4.

root@pve11:~# nft list ruleset | grep -i drop
root@pve11:~# iptables -L -n -v
Chain INPUT (policy ACCEPT 326M packets, 575G bytes)
 pkts bytes target     prot opt in     out     source               destination       

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination       

Chain OUTPUT (policy ACCEPT 312M packets, 308G bytes)
 pkts bytes target     prot opt in     out     source               destination       
root@pve11:~#

Ich weis, das die ganze Sache noch vor einem halben Jahr problemlos funktioniert hat. Damals liefen die PVE alle mit 8.3. Inzwischen sind alle PVE und der PBS geupdatet b.z.w. neu Installiert, aber der Fehler ist immer das selbe.

 

[Bu66as]

@garfield2008,

Der tcpdump verrät es: Der TCP-Handshake klappt einwandfrei (SYN → SYN-ACK → ACK), aber danach kommt keine Daten-Übertragung zustande — der Server schickt nach 5 Sekunden ein FIN.

Das ist ein klassisches MTU-Problem. Schau dir die MSS im tcpdump an: mss 8960 — das bedeutet MTU 9000 (Jumbo Frames) auf beiden Seiten.

Der Ablauf ist:

• TCP-Handshake: kleine Pakete (~60 Bytes) → passt durch
• TLS ClientHello nach dem Handshake: großes Paket (bis zu 8960 Bytes Payload) → wird auf dem Weg gedroppt
• Server wartet auf Daten, bekommt nichts, schließt nach Timeout die Verbindung

Der Traffic geht von der VM über bond1 → Switch VLAN 1 → Switch-Firewall → Switch VLAN 99 → bond0 zum Host. Wenn irgendein Hop auf diesem Pfad nur MTU 1500 kann (typischerweise die Switch-Firewall zwischen den VLANs), werden die großen Pakete still gedroppt.

Zum Verifizieren von der VM aus:

ping -M do -s 8000 192.168.99.121

Das wird vermutlich fehlschlagen. Dann schrittweise runter:

ping -M do -s 1472 192.168.99.121

Damit findest du die tatsächliche Path-MTU.

SSH funktioniert wahrscheinlich weil der SSH-Handshake deutlich kleinere Pakete schickt als TLS und die Daten dann in der bereits ausgehandelten kleineren Window-Size fließen.

Fix: Entweder Jumbo Frames konsistent auf dem gesamten Pfad (inkl. Switch-Firewall) konfigurieren, oder die MTU auf den OVS-Bridges/Bonds auf 1500 setzen. Prüf mal:

ip link show bond0
ip link show bond1
ovs-vsctl list interface | grep -E 'name|mtu'

 

[garfield2008]

Ich glaub ich habe die Lösung.

Habe gerade mal bei der VM die MTU auf 1500 begrenzt und siehe da, ich komme mit allen Protokollen auf alle PVE/PBS. Bleibt also die Frage, was hat sich vor einem halben Jahr geändert?

 

[Bu66as]

@garfield2008 ,

Gut, damit ist die Ursache bestätigt.

Was sich geändert hat: Vermutlich haben bei der Neuinstallation/dem Update die OVS-Bridges oder Bonds die MTU 9000 von den NICs übernommen (OVS negotiiert die MTU automatisch anhand der darunterliegenden Interfaces). Vorher war die MTU vermutlich explizit oder implizit auf 1500 — nach der Neuinstallation nicht mehr.

Die MTU nur in der VM auf 1500 zu begrenzen ist ein Workaround, aber nicht sauber — jede neue VM hätte das gleiche Problem. Besser: die MTU dort fixen wo sie tatsächlich hingehört:

• Option A: Jumbo Frames konsistent auf dem gesamten Pfad aktivieren — also auch auf der Switch-Firewall zwischen VLAN 1 und VLAN 99. Das ist die performantere Variante.
• Option B: MTU auf den OVS-Bridges/Bonds explizit auf 1500 setzen, wenn Jumbo Frames nicht durchgängig benötigt werden. In /etc/network/interfaces bei den Bonds/Bridges mtu 1500 setzen.

Prüf mal die aktuelle Konfiguration:

ovs-vsctl list interface | grep -E 'name|mtu'
ip link show bond0
ip link show bond1

Damit siehst du wo die 9000 herkommt und kannst gezielt korrigieren.