OpenVPN probleem na verhuizen VM van Virtualbox naar KVM

[Scally]

Ik heb sinds kort al mijn Virtualbox VM's (alle Ubuntu 18.04 LTS) verhuisd naar KVM/QEMU op (ook) een Ubuntu 18.04 host. Virtualbox Additions netjes gedeïnstalleerd en van alle VM's de Netplan config (YAML) file aangepast naar de nieuwe netwerk interface (enp0s3 -> ens3). Bij het aanmaken van een nieuwe VM op KVM/QEMU is dit blijkbaar gewijzigd naar een andere netwerk interface naam.

Probleem: Ik kan nog wel via VPN verbinden met mijn telefoon, maar vervolgens geen internet toegang of toegang tot interne webpagina's meer.
Voor de rest is er niks gewijzigd. Zou er een manier zijn om de originele netwerk interface naam weer terug te zetten (enp0s3) ? Volgens mij moet het iets simpels zijn. De VPN tunnel Tun0 is op 1 op andere manier gelinkt aan de reguliere netwerkkaart vermoed ik..

Óf het heeft te maken met dit probleem (zie link onder). Vanaf de host is geen enkele VM te pingen en vanaf alle VM's is de host niet te pingen.

https://wiki.libvirt.org/..._reach_host_%28macvtap%29

De oplossing voor dit issue staat onder in het artikel maar dat is me nog niet gelukt.
Iemand hier ervaring mee of een idee?


...

[Scally]

VPN probleem uiteindelijk opgelost door de netwerk interface te hernoemen naar de oorspronkelijke naam d.m.v. een /etc/udev/rules.d/70-persistent-net.rules
Andere issue (host - vm niet te pingen vice versa moet nog worden opgelost.

[ Voor 12% gewijzigd door Scally op 07-02-2020 19:22 ]

[Hero of Time]

Als je je NIC moet hernoemen, betekend dat dat je ergens een harde verwijzing in je config hebt naar de naam van een interface (denk aan routering voor de VPN clients, in je VPN server config).

Wat betreft ping issues, de netwerkstack van Qemu/KVM is anders dan die van VirtualBox. Hoe ziet je netwerk op de host er nu uit? Kan je wel naar de guest toe via ssh, of van guest naar host? Gebruik je ergens iptables of firewalld (of ufw)?

[Scally]

Hero of Time schreef op vrijdag 7 februari 2020 @ 21:40:
Als je je NIC moet hernoemen, betekend dat dat je ergens een harde verwijzing in je config hebt naar de naam van een interface (denk aan routering voor de VPN clients, in je VPN server config).

Wat betreft ping issues, de netwerkstack van Qemu/KVM is anders dan die van VirtualBox. Hoe ziet je netwerk op de host er nu uit? Kan je wel naar de guest toe via ssh, of van guest naar host? Gebruik je ergens iptables of firewalld (of ufw)?

Ja dat klopt wel denk ik. Weet alleen niet waar ik t moet zoeken dus heb t zo opgelost. Misschien dat ik nog wel es ga zoeken waar 't staat.
Mijn host krijgt netjes een DHCP adres van m'n router en vanaf mn eigen Windows 10 desktop kan ik hem overnemen met RDP. Verder niks ingericht qua netwerk van de host. Alle VM's zijn gebridged met de host via de macvtap interface. Device model staat op VirtIO.
Op de host zelf kan ik niet pingen, SSH, etc. naar de guests toe.Vanaf m'n Win10 PC wel.
Als ik een ping probeer naar 1 van de VM's dan krijg ik een timeout. SSH resulteert in een 'no route to host' melding. Omgekeerd (van guest naar host) precies hetzelfde.
Firewalls staan overal uit, geen iptables o.i.d. geconfigureerd.

Quote uit het artikel dat ik heb gevonden geeft het probleem aan:

However, once a guest has been configured to use a "type='direct'" network interface (a.k.a. macvtap), users will commonly be surprised that the guest is able to communicate with other guests, and also with other external hosts on the network, but cannot communicate with the virt host on which the guest in question lives.

This is not a bug, it is the defined behavior of macvtap - due to the way that the host's physical ethernet is attached to the macvtap bridge, traffic into that bridge from the guests that is forwarded to the physical interface cannot be bounced back up to the host's IP stack (and also, traffic from the host's IP stack that is sent to the physical interface cannot be bounced back up to the macvtap bridge for forwarding to the guests.)

Dit wilde ik oplossen door een isolated netwerk te creeëren zoals wordt gesuggereerd in het artikel. Maar daar loop ik vast op het starten van het isolated network (virsh net-start isolated):

error: Failed to start network isolated
error: internal error: Network is already in use by interface enp2s0

enp2s0 is de naam van de fysieke network interface op de host. Zit trouwens maar 1 NIC in.

In de isolated.xml heb ik trouwens de hele <dhcp> config weggelaten. Maar kan me niet voorstellen dat dit het probleem is.

[Hero of Time]

Kijk dan eens naar de klassieke bridge setup voor VMs, met brctl uit bridge-utils package. De VMs krijgen een tap interface, die hangen in de bridge samen met je fysieke NIC en gaan.

Het is een veel gebruikte manier, Xen heeft het ook lang zo gedaan (geen idee of Xen het nog steeds zo doet) en VirtualBox voor versie 2.0 werkte ook op die manier.

[Scally]

Bedankt voor de tip. Helaas ben ik niet zo goed met dit soort netwerk dingen.
Voor nu laat ik het zo, wellicht toch weer terug naar Virtualbox.

[Hero of Time]

1e hit op Google mbt KVM+bridge: http://www.linux-kvm.org/page/Networking. Staat duidelijk uitgelegd. Moet je makkelijk kunnen doen, want je hebt je boel al verhuisd van VB naar KVM.

[Scally]

Update, ik heb een script gevonden die een macvlan interface op de host aanmaakt. Die wordt bij het starten van de host gedraaid. Werkt prima. Nieuwe Ubuntu VM aangemaakt en die kan naar de host pingen, en vice versa. Echter bij het importeren van een bestaande VM en die aan dezelfde nieuw aangemaakte macvlan interface koppelen geeft nog een probleem, namelijk dat vanuit de VM gezien de link de status 'DOWN' heeft.
Bij de nieuw aangemaakte is die 'UP'.
Laatste stukje van de puzzel, maar hier moet ik wel uit komen

Update: Bij de geïmporteerde VM stond nog een oude (verkeerde) netwerkinterface naam. Aangepast naar de daadwerkelijke naam en opgelost
Hero bedankt voor het meedenken!

[ Voor 14% gewijzigd door Scally op 09-02-2020 10:41 ]