Ce soir on a galéré dans notre soirée d’adminsys pour mettre du net sur une VM proxmox
c’est dans le cadre d’une migration ganeti → proxmox
On aimerait que ça marche avec le fichier suivant côté abonné⋅e:
auto eth0
iface eth0 inet static
pre-up /sbin/ip link set $IFACE up
pre-up /sbin/ip route add 169.254.42.1 dev $IFACE
address <votre_IPv4>/32
gateway 169.254.42.1
(c’est ce qu’il y a actuellement pour les vm du cluster ganeti
On a même pas réussi à ping 169.254.42.1
(c’est pour ARN)
(on est pas bon en réseau) Bref si vous avez des docs de vos FAI qui ont fait des migrations ganeti → proxmox on prends
Côté proxmox hôte
cat /etc/network/interfaces
auto lo
iface lo inet loopback
#auto enp2s0f0
iface enp2s0f0 inet manual
iface enp2s0f0 inet6 manual
auto vmbr0
iface vmbr0 inet static
# pre-up /sbin/ip link set $IFACE up
# pre-up /sbin/ip route add 169.254.43.1 dev $IFACE
address 89.234.141.133/32
gateway 169.254.43.1
bridge_ports enp2s0f0
bridge_stp off
bridge_fd 0
iface vmbr0 inet6 static
address 2a00:5881:8100::133/128
gateway fe80::43:1
accept_ra 0
autoconf 0
dad-attemps 0
iface enp2s0f1 inet manual
iface enp3s0f0 inet manual
iface enp3s0f1 inet manual
# ip a s vmbr0
6: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:26:55:30:e2:a4 brd ff:ff:ff:ff:ff:ff
inet 89.234.141.133/32 brd 89.234.141.133 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 2a00:5881:8100::133/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::226:55ff:fe30:e2a4/64 scope link
valid_lft forever preferred_lft forever
# ip a s tap102i0
14: tap102i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr102i0 state UNKNOWN group default qlen 1000
link/ether 8a:c4:9f:62:bb:65 brd ff:ff:ff:ff:ff:ff
inet 169.254.42.1/24 scope global tap102i0
valid_lft forever preferred_lft forever
# ip r s
default via 169.254.43.1 dev vmbr0 onlink
89.234.141.81 dev tap100i0 scope link src 89.234.141.133
89.234.141.82 dev tap102i0 proto kernel scope link src 89.234.141.133
169.254.42.0/24 dev tap100i0 proto kernel scope link src 169.254.42.1
169.254.42.0/24 dev tap102i0 proto kernel scope link src 169.254.42.1
A ce stade on se demande si c’est une histoire de parefeu ou de forwarding.
Jeltz
et il est bien activé du coup le forwarding en v4 ?
mais même, c’est pas censé être utile en principe
si c’est juste pour ping l’hyperviseur depuis la vm
et des tcpdump sur les différentes interfaces ça donne quoi ? et en désactivant le firewall proxmox (celui qui fait les interfacesfwbr
) ?
ljf
Jeltz
et il est bien activé du coup le forwarding en v4 ?
](https://matrix.to/#/!fnTxwWXZhFNjEkasqJ:matrix.fdn.fr/$xGxDrE7ViALlffmA2a5cQcOKE6R-ndDSynAuQIMpY0Y?via=matrix.org&via=matrix.fdn.fr&via=sans-nuage.fr)
Je viens d’essayer mais non c’est pas (juste) ça
Jeltz
et des tcpdump sur les différentes interfaces ça donne quoi ? et en désactivant le firewall proxmox (celui qui fait les interfacesfwbr
) ?
](https://matrix.to/#/!fnTxwWXZhFNjEkasqJ:matrix.fdn.fr/$fcM9Lk8j6xMfL3VR1Im_NgQpQTRx98cAsErZfG4I93w?via=matrix.org&via=matrix.fdn.fr&via=sans-nuage.fr)
Ça donne quelques paquets ARP et c’est tout ARP, Request who-has recursif.arn-fai.net tell 89.234.141.81, length 28
par contre je peux pas vérifier facilement dans la vm car j’ai pas tcpdump (et elle a pas le net)