Rootserver VMs mit IPV4 nicht mehr erreichbar

[etron770]

Debian Buster Proxmox

Nach einem Neustart funktionieren die VMs nur noch auf IPV6
Rootserver ist mit IPV4 erreichbar
IPV4 und IPV6 Pings gehen vom Rootserver auf die VM und zurück
IPV4 Ping von extern geht nicht, IPV4 Pings von der VM in s Internet gehen auch nicht.
Forwarding ist an


Oder habe ich irgendwie mich unabsichtlich vertippt und schaue immer wieder an die falsche Stelle?
Ich wüsste auch nicht, was ich vor dem Neustart verändert habe und auch auf den Snapshots sind die Netzwerkeinstellungen gleich.

Code: Alles auswählen

auto lo
iface lo inet loopback

iface lo inet6 loopback

auto enp6s0
iface enp6s0 inet static
        address  xx.yy.zz.18
        netmask  255.255.255.192
        gateway  xx.yy.zz.1
        pointopoint xx.yy.zz.1
iface enp6s0 inet6 static
        address  xx.yy.zz:ww::2
        netmask  64
        gateway  fe80::1
        up sysctl -p 
# -------------------------

Code: Alles auswählen

auto vmbr0
iface vmbr0 inet static
        address  xx.yy.zz.18
        netmask  255.255.255.255
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        up ip route add xx.yy.zz.32/32 dev vmbr0
   .....
        up ip route add xx.yy.zz.62/32 dev vmbr0

iface vmbr0 inet6 static
        address  xx.yy.zz:ww::3
        netmask  64
        up ip -6 route add  xx.yy.zz:ww::32 dev vmbr0
       ...
        up ip -6 route add  xx.yy.zz:ww::69 dev vmbr0

Code: Alles auswählen

root@srv2 ~ # route -n

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         xx.yy.zz.1        0.0.0.0         UG    0      0        0 enp6s0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
10.8.0.110      0.0.0.0         255.255.255.255 UH    0      0        0 vmbr111
10.8.0.111      0.0.0.0         255.255.255.255 UH    0      0        0 vmbr111
10.8.0.112      0.0.0.0         255.255.255.255 UH    0      0        0 vmbr111
10.8.0.113      0.0.0.0         255.255.255.255 UH    0      0        0 vmbr111
10.8.0.114      0.0.0.0         255.255.255.255 UH    0      0        0 vmbr111
10.8.0.115      0.0.0.0         255.255.255.255 UH    0      0        0 vmbr111
10.8.0.116      0.0.0.0         255.255.255.255 UH    0      0        0 vmbr111
xx.yy.zz.1        0.0.0.0         255.255.255.255 UH    0      0        0 enp6s0
xx.yy.zz.32       0.0.0.0         255.255.255.255 UH    0      0        0 vmbr0
xx.yy.zz.55       0.0.0.0         255.255.255.255 UH    0      0        0 vmbr0
xx.yy.zz.57       0.0.0.0         255.255.255.255 UH    0      0        0 vmbr0
xx.yy.zz.59       0.0.0.0         255.255.255.255 UH    0      0        0 vmbr0
xx.yy.zz.60       0.0.0.0         255.255.255.255 UH    0      0        0 vmbr0
xx.yy.zz.62       0.0.0.0         255.255.255.255 UH    0      0        0 vmbr0

[etron770]

TShark zeigt mir

auf den Rootserver bei Pings: ping request und ping reply
auf die VMs nur ping request und keine ping reply
also werden die IPS wohl auf dem Server geroutet und nicht zur VM weitergegeben

[mludwig]

Zwei Dinge fallen auf: das Interface enps0 und vmbr0 haben nach deinen Angaben die gleiche IP. Und die Bridge vmbr0 hat keine Member-Interfaces. Vermutlich sollte hier vmbr0 mit enps0 in eine Bridge, und dann brauchts die IP bei enps0 nicht nochmal?

[etron770]

Ist ein Hetzner Server, angeblich etwas kompliziert ..
https://docs.hetzner.com/robot/dedicate ... ian-ubuntu

Code: Alles auswählen

auto eth0
iface eth0 inet static
   address (Main IP)
   netmask 255.255.255.255
   pointopoint (Gateway IP)
   gateway (Gateway IP)
#
iface eth0 inet6 static
  address 2001:db8:1234::1
  netmask 128
  gateway fe80::1
#
auto virbr1
iface virbr1 inet static
   address (Main IP)
   netmask 255.255.255.255
   bridge_ports none
   bridge_stp off
   bridge_fd 0
   pre-up brctl addbr virbr1
   up ip route add (Additional IP)/32 dev virbr1
   down ip route del (Additional IP)/32 dev virbr1
 #
 iface virbr1 inet6 static
   address 2a01:4f8:XX:YY::1
   netmask 64

Ich sehe da keinen Unterschied - ich suche auch schon seit gestern Abend und trau meinen Augen nicht mehr ...

[etron770]

Und wenn ich von der VM einen Ping auf google.de mache (DNS vorher gelöscht)

ping -4 google.de

PING google.de (142.250.185.99) 56(84) bytes of data.

Kann ich auf der Hardwareschnittstelle sehen, dass die VM google anpingt, aber es kommt auch nichts zurück
aber der die URL wird aufgelöst.

Tshark auf der Netzwerkkarte:

1258 1270 7.922401652 xx.yy.zz.55 → 142.250.186.35 ICMP 98 Echo (ping) request id=0x3277, seq=19/4864, ttl=63

1289 1295 8.946433455 xx.yy.zz.55 → 142.250.186.35 ICMP 98 Echo (ping) request id=0x3277, seq=20/5120, ttl=63

[heisenberg]

Zwei Dinge fallen auf: das Interface enps0 und vmbr0 haben nach deinen Angaben die gleiche IP. Und die Bridge vmbr0 hat keine Member-Interfaces. Vermutlich sollte hier vmbr0 mit enps0 in eine Bridge, und dann brauchts die IP bei enps0 nicht nochmal?

Das ist absolut richtig. Das Interface enp6s0 darf keine IPs zugewiesen bekommen; nur das Interface vmbr0. Zusätzlich muss enp6s0 dem vmbr0 via bridge-ports zugeordnet werden.

[bluestar]

Zwei Dinge fallen auf: das Interface enps0 und vmbr0 haben nach deinen Angaben die gleiche IP.

Das ist bei gerouteten Bridge Setups vollkommen normal.

@TE: Check mal dein IP-Forwarding und deine Iptables-Regeln.

[etron770]

Vielen Dank für die Antworten.

Ich habe zum Testen firewall aus, file2ban aus.
arp zeigt auch die richtigen MAC Adressen ...

Aber zum Verständnis eine Frage, nachdem ich nach zwei Tagen nicht mehr weiß was ich schon alles gesucht und probiert habe:

Ich starte tshark |grep "Echo (ping)" auf der VM und auf dem Server
Auf dem Server lauscht tshark dann auf enp6s0 in der VM eth0

ping -4 eine-domain.com vom Arbeitsplatz extern
sehe ich auf dem Root nur ping requests auf dem client nichts

Ich starte tshark |grep "Echo (ping)" auf der VM und auf dem Server tshark -i vmbr0 |grep "Echo (ping)"
Auf dem Server lauscht tshark dann auf vmbr0 in der VM eth0
ping -4 eine-domain.com vom root server
Dann sehe ich bei beiden die Ping request und den repeat

Wo ist der Fehler, wenn also der Ping von außen auf dem Rootserver ankommt dort aber nicht zur VM geroutet wird.
Vom Rootserver auf die VM aber funktioniert


Was braucht, ihr um das irgendwie einzugrenzen.
Mein Hirn ist echt leer, es wäre schön wenn ihr bitte gleich den/die Konsolenbefehle sagen würdet die weiter helfen könnten
- ich mache das und höre auf zu grübeln
--------------------------
Was funktioniert:
Und ein ipv6 Ping von extern wird auf VM eth0, enp6s0, und vmbr0 gezeigt.
Und die Webseiten funktionieren auch auf IPV6 und nicht auf IPV4 - das ist bei allen VMs so

[heisenberg]

Zwei Dinge fallen auf: das Interface enps0 und vmbr0 haben nach deinen Angaben die gleiche IP.

Das ist bei gerouteten Bridge Setups vollkommen normal.

Das entspricht nicht meiner Kenntnis der Netzwerkkonfiguration. In Anleitungen wird dies auch so nicht ausgeführt. Z. B. hier: https://wiki.debian.org/BridgeNetworkConnections

Was ist der Unterschied zwischen der Zuweisung nur auf dem Bridge-Interface und der Zuweisung an beide Interfaces?

[bluestar]

Was ist der Unterschied zwischen der Zuweisung nur auf dem Bridge-Interface und der Zuweisung an beide Interfaces?

Den Unterschied siehst du auf ARP Ebene. Wenn du das physikalische Interface als Port in die Bridge packst, dann sieht dein Provider ARP Anfragen für die gerouteten IPs und das ist bei gerouteten IPs einfach falsch.

Normalerweise packst du auf die Bridge dein geroutetes Netz - allerdings verlierst du dabei natürlich drei nutzbare IPs(Netz, 1. IP für Host, letzte IP als Broadcast) um deine IPs effizient nutzen zu können, verzichtest du auf dieses klassische Netz-Setup und legst für jede IP deines Netzes eine /32 Route an, so verschwendest du keine drei IPs und baust je IP ein Pointopoint-Setup auf, hierbei dienst die IP auf dem Bridge-Device als Default-Gateway für die VMs. Du kannst natürlich jede x-beliebige öffentliche und/oder private IP auf der Bridge als Default-Gateway für die VM nutzen.

[heisenberg]

Danke bluestar. Ich denke, ich hab's halbwegs gerafft.

[etron770]

Irgendwie komme ich nicht weiter ...

Kann dieses Setup die Probleme verursachen die hier auftreten? - Hetzner verlangt das aber, also müsste es gehen.
Kann Hetzner im Hintergrund was verändert haben, dass das (früher) vorgegebene Routing nicht mehr funktioniert?
Kann die Netzwerkkarte für IPV4 defekt sein?
Wo kann man noch suchen ...

[bluestar]

Kann dieses Setup die Probleme verursachen die hier auftreten? - Hetzner verlangt das aber, also müsste es gehen.

Dein Setup sieht auf den ersten Blick richtig aus.

Kann Hetzner im Hintergrund was verändert haben, dass das (früher) vorgegebene Routing nicht mehr funktioniert?

Dann hätte ich wohl auch die Probleme

Kann die Netzwerkkarte für IPV4 defekt sein?

Dann könntest du den ganzen Server wohl nicht mehr per IPv4 erreichen.

Wo kann man noch suchen ...

Poste doch mal die Ausgaben der folgenden Befehle:

Code: Alles auswählen

uname -a

Code: Alles auswählen

sysctl net.ipv4.ip_forward

Code: Alles auswählen

iptables-leagcy-save

Code: Alles auswählen

iptables-nft-save

Code: Alles auswählen

brctl show

[etron770]

Danke für die Antworten - so dachte ich mir das ...

Code: Alles auswählen

root@srv2 ~ # uname -a 
Linux srv2.myserver.de 5.4.189-2-pve #1 SMP PVE 5.4.189-2 (Mon, 13 Jun 2022 09:39:53 +0200) x86_64 GNU/Linux

root@srv2 ~ # sysctl net.ipv4.ip_forward 
net.ipv4.ip_forward = 1

root@srv2 ~ # iptables-legacy-save 
# Generated by iptables-save v1.8.2 on Fri Jun 17 10:04:01 2022 
*mangle 
:PREROUTING ACCEPT [1453044:3883886025] 
:INPUT ACCEPT [106289:298938597] 
:FORWARD ACCEPT [1346576:3584914060] 
:OUTPUT ACCEPT [102156:40114760] 
:POSTROUTING ACCEPT [1448732:3625028820] 
COMMIT 
# Completed on Fri Jun 17 10:04:01 2022 
# Generated by iptables-save v1.8.2 on Fri Jun 17 10:04:01 2022 
*raw 
:PREROUTING ACCEPT [1453367:3884001020] 
:OUTPUT ACCEPT [102463:40235144] 
COMMIT 
# Completed on Fri Jun 17 10:04:01 2022 
# Generated by iptables-save v1.8.2 on Fri Jun 17 10:04:01 2022 
*nat 
:PREROUTING ACCEPT [33847:1925465] 
:INPUT ACCEPT [15708:757830] 
:OUTPUT ACCEPT [1617:100610] 
:POSTROUTING ACCEPT [3971:242458] 
-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 46.4.5.18 
-A POSTROUTING -s 10.8.0.0/24 -o enp6s0 -j MASQUERADE 
-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 46.4.5.18 
-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 46.4.5.18 
-A POSTROUTING -s 192.168.2.0/24 -o enp6s0 -j MASQUERADE 
-A POSTROUTING -s 10.8.0.0/24 -o enp6s0 -j MASQUERADE 
-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 46.4.5.18 
COMMIT 
# Completed on Fri Jun 17 10:04:01 2022 
# Generated by iptables-save v1.8.2 on Fri Jun 17 10:04:01 2022 
*filter 
:INPUT ACCEPT [105749:298901764] 
:FORWARD ACCEPT [1346579:3584914240] 
:OUTPUT ACCEPT [102547:40264299] 
:f2b-sshd - [0:0] 
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd 
-A INPUT -p udp -m udp --dport 8194 -j ACCEPT 
-A f2b-sshd -j RETURN 
COMMIT
# Completed on Fri Jun 17 10:04:01 2022

root@srv2 ~ # iptables-nft-save 
# Warning: iptables-legacy tables present, use iptables-legacy-save to see them
root@srv2 ~ # brctl show 
bridge name     bridge id               STP enabled     interfaces 
fwbr104i0               8000.82200f28118f       no              fwln104i0 
                                                       veth104i0 
vmbr0           8000.fe00cb265833       no              fwpr104p0 
                                                       veth101i0 
                                                       veth102i0 
                                                       veth103i0 
                                                       veth106i0 
                                                       veth1102i0 
vmbr111         8000.fed8566bafbf       no              veth502i0 
                                                       veth505i0 
                                                       veth506i0

[bluestar]

Dann bleibt eig. nur noch deine Netzwerkkonfiguration in deiner VM. Wirf die mal in die Runde

[etron770]

das ist die von Proxmox:

Code: Alles auswählen

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address xx.yy.zz.55/26
        gateway xx.yy.zz.18

iface eth0 inet6 static
        address xxx:yyy:zzz:516e::55/64
        gateway xxx:yyy:zzz:516e::3

[bluestar]

das ist die von Proxmox:

Code: Alles auswählen

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address xx.yy.zz.55/26
        gateway xx.yy.zz.18

iface eth0 inet6 static
        address xxx:yyy:zzz:516e::55/64
        gateway xxx:yyy:zzz:516e::3

Und die ist leider falsch, das muss so aussehen:

Code: Alles auswählen

auto eth0
iface eth0 inet static
        address xx.yy.zz.55/32
        pointopoint xx.yy.zz.18
        gateway xx.yy.zz.18

[etron770]

... das habe ich schon in den verschiedensten Versionen ausprobiert ..
am dritten tag weiß ich zwar nicht mehr genau was alles, bzw, was nicht

gebe ich in proxmox xx.yy.zz.57/32 ein macht Proxmox das draus:

Code: Alles auswählen

auto lo
iface lo inet loopback
iface lo inet6 loopback


auto eth0
iface eth0 inet static
        address xx.yy.zz.57/32
# --- BEGIN PVE ---
        post-up ip route add xx.yy.zz.18 dev eth0
        post-up ip route add default via xx.yy.zz.18 dev eth0
        pre-down ip route del default via xx.yy.zz.18 dev eth0
        pre-down ip route del xx.yy.zz.18 dev eth0
# --- END PVE ---
        pointopoint xx.yy.zz.18

im Robot steht für die Adresse:

Code: Alles auswählen

Gateway: xx.yy.zz.1
Netmask: 255.255.255.192
Broadcast: xx.yy.zz.63

also /26
Aber auch damit bekomme ich keinen Ping auf die VM

nehme ich bei proxmox xx.yy.zz.57/26 ist das obige Setup drin:

Code: Alles auswählen

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address xx.yy.zz.55/26
        gateway xx.yy.zz.18

und mit pointopoint funktioniert es auch nicht

Code: Alles auswählen

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address xx.yy.zz.55/26
        gateway xx.yy.zz.18
        pointopoint xx.yy.zz.18

[bluestar]

Leider wird's schwierig dein Setup tiefgreifender zu verstehen, wenn du deine IPs zensiert. Also dein Host hat eine IP und du hast von Hetzner ein geroutetes Subnetz? Falls ja: Welche Netzmaske? Oder hast du von Hetzner Einzel-IPs?

Dann wäre die unzensierte /etc/network/interfaces Konfiguration deines Proxmox Host-Systems und ein unzensierte Konfiguration einer VM mal hilfreich, gerne auch per PM.

[etron770]

zum Verständniss für andere

Es sind Einzel IPs von Heztner
xx.yy.zz sind immer die selben Bereiche also immer z.B 12.34.55.32
habe ich mit xx.yy.zz.32 geschrieben.

[bluestar]

zum Verständniss für andere

Es sind Einzel IPs von Heztner
xx.yy.zz sind immer die selben Bereiche also immer z.B 12.34.55.32
habe ich mit xx.yy.zz.32 geschrieben.

Einzel-IPs bei Hetzner sind umständlicher... Da musst du deine VM exakt nach dem Beispiel hier konfigurieren:
(Netzwerkkonfiguration Gastsystem Bridged) https://community.hetzner.com/tutorials ... xmox_ve/de

Code: Alles auswählen

auto ens18
iface ens18 inet static
  address <Zusatz-IP>
  netmask 255.255.255.255
  pointopoint <Gateway der Zusatz-IP>
  gateway <Gateway der Zusatz-IP>

Das solltest du am besten über einen Editor direkt in deiner VM in der Datei machen und nicht via Proxmox machen lassen.

Und noch eine Frage am Rande - hast du bei Hetzner für die Zusatz-IPs MAC Adressen im Robot aktiviert?

[etron770]

ja die mac sind aktivert

was gebe ich dann im proxmox ein, wen ich was in der in /etc/network/interface
ändere setzt proxmox das immer wieder zurück...

[etron770]

Nachdem Proxmox alles immer überschreibt hat hatte ich eth0 aus proxmox herausgelöscht

danach war die VM nicht zu erreichen trotz der config in /etc/network/interfaces
dann wieder eingefügt und nun habe ich

Code: Alles auswählen

RTNETLINK answers: File exists
ifup: failed to bring up eth0
ifdown: interface eth0 not configured

da habe ich mit ip link set eth0 down und ip link set eth0 up wieder gerichtet
Aber egal, was ich in der VM eingebe es funktioniert nicht

[etron770]

Am 13.06 hatte ich ein update upgrade mit (neuem Kernel 5.4.189-2-pve) durchgeführt und am Freitag hat der reboot das Problem scheinbar aktiviert ..

Wenn man eine virtuelle Bridge auf eine inaktive IP erstellt, kommen schon vom Kernel keine Pakete außer der Haupt IP an

Code: Alles auswählen

ifconfig enp6s0:1 xx.yy.zz.57 netmask 255.255.255.255 broadcast 0.0.0.0

Da braucht man dann nicht weiter oben suchen oder?

Ich werde mal spät in der Nacht auf der Rettungskonsole das Selbe probieren ...

[etron770]

tja ... auf der Rettungskonsole kommt der Ping request von außerhalb an, aber kein ping reply
von der Rettungskonsole direkt auf die virtuelle Bridge kommt der reply