NAT Netzwerk für VMs

[Simon Moon]

Hi

Ich probier gerade meine VMs in Debian online zu kriegen, aber irgendwie will es einfach nicht. Als Anleitung kam dieses Tutorial zum einsatz https://jamielinux.com/docs/libvirt-networking-handbook/custom-nat-based-network.html

Verwendet wird der Virtmanager mit KVM. Auf dem System kommt dhcpcd als DHCP Client zum Einsatz. OS ist Debian 9 stable mit xcfe4 Desktop.

Die interfaces Datei sieht dann wie folgt aus:
[]
# loopback no Internet
auto lo
iface lo inet loopback


auto virbr10-dummy
iface virbr10-dummy inet manual
pre-up /sbin/ip link add virbr10-dummy type dummy
up /sbin/ip link set virbr10-dummy address 52:54:00:c8:5f:8c

auto virbr10
iface virbr10 inet static
bridge_ports virbr10-dummy
bridge_stp on
bridge_fd 2
address 192.168.123.1
netmask 255.255.255.0


# Normaler Ethernet Controller
allow-hotplug enp1s0


# Android Smartphone via USB
allow-hotplug enp0s21f0u1
#gateway 192.168.142.1
#broadcast 192.168.42.255


# WLAN Interface
allow-hotplug wlp2s0
#gateway 192.168.143.1
#broadcast 192.168.43.255
[]
iptables sehen so aus:
[]

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i virbr10 -p udp -m udp -m multiport --dports 53,67 -j ACCEPT
-A INPUT -i virbr10 -p tcp -m tcp -m multiport --dports 53,67 -j ACCEPT
-A FORWARD -d 192.168.123.0/24 -o virbr10 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.123.0/24 -i virbr10 -j ACCEPT
-A FORWARD -i virbr10 -o virbr10 -j ACCEPT
-A FORWARD -i virbr10 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -o virbr10 -j REJECT --reject-with icmp-port-unreachable

[]
dnsmasq@virbr10 sieht der status so aus
[]● dnsmasq@virbr10.service - DHCP and DNS caching server for virbr10.
Loaded: loaded (/etc/systemd/system/dnsmasq@.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2018-11-05 09:53:40 CET; 38min ago
Main PID: 835 (dnsmasq)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/system-dnsmasq.slice/dnsmasq@virbr10.service
└─835 /usr/sbin/dnsmasq -k --conf-file=/var/lib/dnsmasq/virbr10/dnsmasq.conf

Nov 05 09:53:40 debian dnsmasq[835]: Benutze Namensserver 192.168.42.129#53
Nov 05 09:53:40 debian dnsmasq[835]: /etc/hosts gelesen - 5 Adressen
Nov 05 09:53:40 debian dnsmasq-dhcp[835]: /var/lib/dnsmasq/virbr10/hostsfile gelesen
Nov 05 09:53:40 debian dnsmasq[835]: lese /etc/resolv.conf
Nov 05 09:53:40 debian dnsmasq[835]: Benutze Namensserver 87.118.100.175#53
Nov 05 09:53:40 debian dnsmasq[835]: Benutze Namensserver 127.0.0.1#53
Nov 05 09:54:26 debian dnsmasq-dhcp[835]: DHCPDISCOVER(virbr10) 192.168.123.112 52:54:00:4b:00:94
Nov 05 09:54:26 debian dnsmasq-dhcp[835]: DHCPOFFER(virbr10) 192.168.123.112 52:54:00:4b:00:94
Nov 05 09:54:26 debian dnsmasq-dhcp[835]: DHCPREQUEST(virbr10) 192.168.123.112 52:54:00:4b:00:94
Nov 05 09:54:26 debian dnsmasq-dhcp[835]: DHCPACK(virbr10) 192.168.123.112 52:54:00:4b:00:94 erisvirt
[]
ip a spuckt dann das aus:

[]1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 54:ee:75:cb:f3:6d brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:e0:4c:81:92:81 brd ff:ff:ff:ff:ff:ff
4: enp0s21f0u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 6a:41:27:0c:05:4e brd ff:ff:ff:ff:ff:ff
inet 192.168.42.172/24 brd 192.168.42.255 scope global enp0s21f0u1
valid_lft forever preferred_lft forever
inet6 fe80::d721:5880:f59b:dd03/64 scope link
valid_lft forever preferred_lft forever
5: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 4a:73:22:ad:a6:7a brd ff:ff:ff:ff:ff:ff
inet6 fe80::f282:6092:ef69:7426/64 scope link
valid_lft forever preferred_lft forever
6: virbr10-dummy: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr10 state UNKNOWN group default qlen 1000
link/ether 52:54:00:c8:5f:8c brd ff:ff:ff:ff:ff:ff
7: virbr10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 52:54:00:c8:5f:8c brd ff:ff:ff:ff:ff:ff
inet 192.168.123.1/24 brd 192.168.123.255 scope global virbr10
valid_lft forever preferred_lft forever
inet6 fe80::a5d3:9769:ca3c:3b8a/64 scope link
valid_lft forever preferred_lft forever
9: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr10 state UNKNOWN group default qlen 1000
link/ether fe:54:00:4b:00:94 brd ff:ff:ff:ff:ff:ff
inet 192.168.123.112/24 brd 192.168.123.255 scope global vnet0
valid_lft forever preferred_lft forever
inet6 fe80::4758:b5e:200b:203e/64 scope link
valid_lft forever preferred_lft forever
[]
Wenn ich mit Wireshark den Traffic anschau, dann kommt die VM auch bis zur Bridge - doch da bleibts dann stecken und wird nicht weiter gerouted. Es muss also wohl irgendws mit der Bridge zu tun haben, denn aus irgendeinem Grund wird bei jedem Systemstart dann auch ein "dummy0" kreiert, bei dem ich aber nicht versteh, was der nun eigentlich tut bzw. woher der kommt. Auch ist der Status von vnet0 und virbr10-dummy immer unknown - ich kann den nicht auffahren.



Hat jemand irgendeine idee, was da falsch konfiguriert ist?


Edit: Ich seh grad, mit dem installierten Alpine Linux hab ich kein Problem im Netzwerk. Liegt also offenbar an der Debian VM? Die ist ber eigentlich ganz frisch.. o.O


Und irgendwie stimmt da was trotzdem nicht. Wenn ich in der Alpine VM schau, hab ich eine IP 192.168.123.238 - auf dem Host ist die IP jeoch wie folgt angezeift:

10: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr10 state UNKNOWN group default qlen 1000
link/ether fe:54:00:d5:36:44 brd ff:ff:ff:ff:ff:ff
inet 169.254.136.164/16 brd 169.254.255.255 scope global vnet1
valid_lft forever preferred_lft forever
inet6 fe80::faa4:41b:f0e7:8099/64 scope link
valid_lft forever preferred_lft forever


Ok, das muss wohl so sein, kaum lass ich die IP von dhcpcd nicht mehr fixieren für vnet0 bekommt der auch so eine 169er IP zugewiesen und kommt dann nach draussen. Aberk kann mir da jemand erklären, wieso das so ist? Ich finde da meist nur irgendwelche Tutorials, die einfach sagen, was man einstellen soll - aber was der Hintergrund ist und wieso bleibt da meist unklar.

[Lokadamus]

Ok, das muss wohl so sein, kaum lass ich die IP von dhcpcd nicht mehr fixieren für vnet0 bekommt der auch so eine 169er IP zugewiesen und kommt dann nach draussen. Aberk kann mir da jemand erklären, wieso das so ist? Ich finde da meist nur irgendwelche Tutorials, die einfach sagen, was man einstellen soll - aber was der Hintergrund ist und wieso bleibt da meist unklar.Der IP Bereich 169. nennt sich Apipa. Dabei konfigurieren sich die Systeme mit dem IP Bereich, wenn kein DHCP Server ihnen antwortet.
https://de.wikipedia.org/wiki/Zeroconf

Dein Regelwerk für IPTables scheint ein bischen krumm zu sein. Normalerweise blockiert bzw. droppt man alles und erlaubt nur das, was wirklich raus soll.

Am besten solltest du iptables für deine VMs testweise öffnen und schauen, ob dann dein 192.168.123er Netz funktioniert.

[HeldImZelt]

aus irgendeinem Grund wird bei jedem Systemstart dann auch ein "dummy0" kreiert, bei dem ich aber nicht versteh, was der nun eigentlich tut bzw. woher der kommt.
Beim erstellen der Bridge wird das Interface "verschlungen", es verschwindet (und muss auch in den promiscuous Mode versetzt werden). Statt das eigene, primäre Interface zu opfern, nimmt man einen Dummy und routet den Traffic zwischen Brücke und primärem Interface. Deshalb ist es auch wichtig, dass auf dem Host "ip_forward" aktiviert ist. (sysctl net.ipv4.ip_forward).

kaum lass ich die IP von dhcpcd nicht mehr fixieren für vnet0 bekommt der auch so eine 169er IP zugewiesen und kommt dann nach draussen. Aberk kann mir da jemand erklären, wieso das so ist?
Das Interface vnet0 hat zwei Seiten. Eine Seite auf dem Host, die andere im Guest. Die Guestseite kannst Du konfigurieren wie Du willst (sollte aber im Subnet der Brücke sein). Die Hostseite hingegen sollte nicht angefasst werden (hast Du ja schon gemerkt). Die wird von der Virtualisierungsschicht selbst verwaltet. Dass die IP nicht wirklich Sinn macht ist egal, da die Brücke eh auf Layer2 arbeitet und alles in eine IP stopft.

[Simon Moon]

Beim erstellen der Bridge wird das Interface "verschlungen", es verschwindet (und muss auch in den promiscuous Mode versetzt werden). Statt das eigene, primäre Interface zu opfern, nimmt man einen Dummy und routet den Traffic zwischen Brücke und primärem Interface. Deshalb ist es auch wichtig, dass auf dem Host "ip_forward" aktiviert ist. (sysctl net.ipv4.ip_forward).

Gibts da irgendwelche Fachliteratur die mir das genauer erklärt?


Das Interface vnet0 hat zwei Seiten. Eine Seite auf dem Host, die andere im Guest. Die Guestseite kannst Du konfigurieren wie Du willst (sollte aber im Subnet der Brücke sein). Die Hostseite hingegen sollte nicht angefasst werden (hast Du ja schon gemerkt). Die wird von der Virtualisierungsschicht selbst verwaltet. Dass die IP nicht wirklich Sinn macht ist egal, da die Brücke eh auf Layer2 arbeitet und alles in eine IP stopft.


Bedeutet dass dann, dass mein PC üver die 169er Ports ansprechbar ist von aussen? Zumindest intern kann ich so auf mich selbst sshen o.O




Am besten solltest du iptables für deine VMs testweise öffnen und schauen, ob dann dein 192.168.123er Netz funktioniert.


Die hab ich ja extra aufgemacht. Aber die Forwarding Regeln sind dann ja notwendig für das NAT. Was es nun auch nicht wirklich leichter macht, da nun wieder die iptables FW zu integrieren.



Btw. sollte es nicht auch möglich ein, die iptables mit dhcpcd und wpasupplicant in einen eigenen namespace auszulagern, der sich dann um die Verbindungen kümmert und der Host eigetlich nur noch ein Tun/Tap Interface sieht?

[HeldImZelt]

Gibts da irgendwelche Fachliteratur die mir das genauer erklärt?
Vielleicht noch das: https://wiki.alpinelinux.org/wiki/LXC#Creating_a_LXC_container_without_modifying_your_network_interfaces

Wobei ich mir mittlerweile nicht mehr sicher bin, in wieweit sich die beiden Netzwerktopologien (LXC<>KVM) wirklich überschneiden. Vielleicht verwechsle ich da auch gerade was.

Bedeutet dass dann, dass mein PC üver die 169er Ports ansprechbar ist von aussen? Zumindest intern kann ich so auf mich selbst sshen o.O
Das mit vnet0 kommt mir spanisch vor. Nach meinem Verständnis (bzw. deinem verlinkten Tutorial oben) wird das Netzwerk der VM mit "--network bridge=virbr10" eingerichtet. Normalerweise muss dafür (auf der Hostseite) kein extra Interface eingerichtet werden. Bist Du sicher, dass da nicht noch irgendwo in deiner VM Konfiguration ein expliziter Eintrag zur Erstellung von vnet0 vorhanden ist?

[Lokadamus]

Gibts da irgendwelche Fachliteratur die mir das genauer erklärt? Was genau willst du den wissen?
IP Forward sorgt dafür, dass Linux den Netzwerkverkehr wie ein Router weiterleitet.
Oder die Sache mit der Brücke?
https://wiki.ubuntuusers.de/Netzwerkbr%C3%BCcke/

[Simon Moon]

Vielleicht noch das: https://wiki.alpinelinux.org/wiki/LXC#Creating_a_LXC_container_without_modifying_your_network_interfaces

Wobei ich mir mittlerweile nicht mehr sicher bin, in wieweit sich die beiden Netzwerktopologien (LXC<>KVM) wirklich überschneiden. Vielleicht verwechsle ich da auch gerade was.

Container sind soweit ich verstehe für den Host noch einiges transparenter. Z.b. kannst du da mit wireguard ziemlich einfach ein Interface herstellen, indem du das einfach in den Namepace des Containers definierst ( https://www.wireguard.com/netns/ ).. Soweit ich also verstehe, ist ein Container in erster Linie nur ein anderer Namensraum für die Prozesse - während eine Virtualisierung das ganze System abstrahiert.

Mit der Topologie hat aber beides nur bedingt zu tun - wenn ich lustig bin, kann ich mir intern auch einen Bus kreieren, der die VMs miteinander verbindet. Mit wireguard und dieser geilen Alpine Linux Version, die nur 32MB gross ist, hab ich jedenfalls ein lustiges Spielzeug entdeckt zum rumbasteln :D


Das mit vnet0 kommt mir spanisch vor. Nach meinem Verständnis (bzw. deinem verlinkten Tutorial oben) wird das Netzwerk der VM mit "--network bridge=virbr10" eingerichtet. Normalerweise muss dafür (auf der Hostseite) kein extra Interface eingerichtet werden. Bist Du sicher, dass da nicht noch irgendwo in deiner VM Konfiguration ein expliziter Eintrag zur Erstellung von vnet0 vorhanden ist?

Virbr10 ist ja nur die Bridge - die VM selber benötigen ja auch noch einen NIC und das ist dann eben dieser vnetx offenbar. Da wird dann auch pro Guest den ich einschalte dynamisch ein neuer vnet generiert und die verbinden sich dann alle mit der virtuellen Bride virbr10. Das andere wäre dann wohl Tun/Tab, wo mein physischer NIC mehr als eine IP zuegeordnet bekommt und jeder Guest direkt darauf zugreifen kann.

[HeldImZelt]

Ja, scheint schon richtig zu sein. Bei LXC heißen die veth statt vnet. Ich dachte die gehören zu etwas anderem. Die Brücke (brctl show) zeigt die aber an.

Bei mir haben die nur IPv6 Adressen, obwohl der Adapter ausschließlich mit IPv4 Traffic genutzt wird. Jede Brücke hat ein eigenes IPv4 Subnetz und eine entsprechende IPv4 Route auf dem Host. Die Pakete werden quasi blind in die Brücke gelenkt. Die Gastseite (dessen IP auch ausschließlich auf der Gastseite konfiguriert werden kann) sollte entsprechend eine IP aus dem Subnetz der Brücke haben. Dann kann man vom Host diese IP ansprechen, obwohl man sie eigentlich nicht sehen kann.

[Acid-Beatz]

Mach mal bitte einen arp -a auf Deinem Host, einer Debian VM und einer Alpine VM.

thx

[Simon Moon]

Mach mal bitte einen arp -a auf Deinem Host, einer Debian VM und einer Alpine VM.

thx


In welchem Paket ist das schon wieder? :redface:


Bisher bin ich eigentlich immer ganz gut mit nmap sL ausgekommen, wenn ich mal einen arp cache auslesen wollte. Ip route geht glaub auch in dieselbe Richtung.

[HeldImZelt]

Alpine:
https://pkgs.alpinelinux.org/contents?file=arp&path=&name=&branch=edge&arch=x86_64

Debian:
https://packages.debian.org/search?suite=stretch&arch=amd64&mode=exactfilename&searchon=contents&keywords=arp

Mach auch mal 'route -n' oder 'ip route' auf dem Host und in den Guests.

Das sind deine Umgebungen? Ist das richtig?
Debian Stretch (Host) -> Debian Stretch (Guest) + Alpine (Guest)

Edit: Nebenbei... könnt ihr die CODE Blöcke im ersten Post in den Spoilern sehen? Bei mir im Firefox63.0.1 erscheinen verschachtelte Spoiler nicht (ich muss den Beitrag erst zitieren um an den Text zu kommen). Wäre nett, wenn Du den Parent Spoiler raus nehmen könntest.

[Simon Moon]

Mittlerweile sieht das Netzwerk schon wieder ganz anders aus. Zu dem oben geposteten lokalen VMs auf dem Lappi hab ich nun noch den Desktop als Server aufgesetzt, dass ich dort nun vom Lappi aus VMs über den Virt-Manager / virsh aufsetzen kann. Die VMs von dort connecten dann via Tun/Tap auf den Lappi welcher dieser über enp21f1s0 ins Internet bridgen soll. So langsam wird das unübersichtlich mit den Netzwerken bzw. ich bin mir irgendwie noch unschlüssig nach was ich das im Endeffekt genau gliedern soll von den Hierarchien.

[Lokadamus]

Edit: Nebenbei... könnt ihr die CODE Blöcke im ersten Post in den Spoilern sehen? Bei mir im Firefox63.0.1 erscheinen verschachtelte Spoiler nicht (ich muss den Beitrag erst zitieren um an den Text zu kommen). Wäre nett, wenn Du den Parent Spoiler raus nehmen könntest.Nein, funktionieren auch nicht im veralteten FF 52 ESR. Dachte, es liegt am alten FF.

Simon,
was willst du den machen oder üben? VLans?

[Simon Moon]

Nein, funktionieren auch nicht im veralteten FF 52 ESR. Dachte, es liegt am alten FF.

Simon,
was willst du den machen oder üben? VLans?


So klar ist das eben auch noch nicht. Ein Anwendungszweck ist sicherlich mal dass ich auf meinem i5/16GB Desktop VMs für meinem Celeron/4GB Lappi laufen lassen kann, damit ich uch auf dem Lappi quasi mehr Leistung hab. Dann soll sicher noch die ein oder andere Alpine oder sonst eine Bastler VM laufen, wo ich mich einfach mal austoben kann. Das ganze soll dann idealerweise automatisch mit dem Internet verbunden sein - wobei ich hier mein Android als Modem nutze und das mal m lappi mal am Desktop oder mal an der Steckdose angeschlossen ist - die verbindung also je nachdem über USB Thetering oder Wifi Thetering abläuft.



bzw- wieso können Gäste die per Tun/Tap angeschlossen sind eignetlich nicht mit dem Hot kommunzieren? Aktuell ist es so, dass meine Manjaro VM per ethernet den Lappi anpingen kann, aber nicht den eigenen Host - dabei wird das alles ja über den Lappi gebridget. o.O

btw2: Wie kann ich am besten den Lag zur VM auf dem Remote Host minimieren? Der Ping liegt bei ~0,2ms, ist auch direkt angeschlossen ohne Router dazwischen - da müsste man den Lag doch eigentlich nicht spüren?

[Acid-Beatz]

In welchem Paket ist das schon wieder? :redface:


Bisher bin ich eigentlich immer ganz gut mit nmap sL ausgekommen, wenn ich mal einen arp cache auslesen wollte. Ip route geht glaub auch in dieselbe Richtung.

Ja Grüzzi :smile:

Sorry, wollt Dir eigentlich zwischenzeitlich noch mal schreiben, habs dann aber übersehen: Unter Centos müsste es in net-tools sein, wenn ich mich gerade richtig erinnere.

Besteht Dein Problem noch? Ansonsten wäre mein plan gewesen, dass Du Dir die ARP Einträge auf dem Host anzeigen lässt. Sieht er zumindest die MACs, musst Du in der VM noch irgendwas an der IP herumbasteln, DHCP oder was weiß ich.
Wenn er die Einträge schon nicht sieht, liegts evtl doch an der VM-Netzwerk Konfiguration (falscher "Adapter"/VLAN). Zumindest mal als grober Wegweißer, das Beste wäre jetzt, Du siehst die ganzen MACs ;)

Greez

[Simon Moon]

Thx, mittlerweil hab ich ganz andere Hürden. Aber wie erwähnt, ist ja auch ein gewolltes rumbasteln. Das Routing ist z.t. aber wirklich noch zu bedenken, wie ich nun spätestens mit dem zweiten VM Server merke. Beide sind nämlich (Lappi und Server) über den WLAN Hotspot vom Handy mit dem Internet verbunden bzw. haben da eine Route zum verbinden. Dazu kommt aber noch eine LAN Verbindung per Ethernet - und da wirds dann schon ziemlich chaotisch - der Server kann dann nämlich über den Lappi ins Internet naten oder direkt über den Android Hotspot, genauso wie teils Software scheinbar lieber über WLAN verindet, als das schnellere Kabel zum Host zu nehmen. Aktuell verbindet der Server aus was für Gründen auch immer nur per WLAN zum DNS Server - connected danach aber normal den Lappi für die Verbindung. ... Da bin ich noch gar nicht dazu gekommen, das mal genauer anzuschauen.

Alles in allem sind die Verbindungen schon relativ komplex find ich - da ja intern noch die virbr10 bridge ist. Auf dem Lan Kabel sind dann auch noch mehrere IPs, da ich das Netzwerk mit ein paar MS VMs noch etwas heterogener machen will und die VMs lieber in ihrem eigenen Subnetz belass.

Aktuell wär da ein komfortabler IPtables Editor recht praktisch. Er müsste da nicht gross selber regeln erstellen oder eine eigene Scriptsprache mitbringen, einfach nur die iptables etwas prraktisch darstellen und editieren lassen. Eine ncurses Darstellung wär da ausreichend.

[Acid-Beatz]

Aktuell wär da ein komfortabler IPtables Editor recht praktisch. Er müsste da nicht gross selber regeln erstellen oder eine eigene Scriptsprache mitbringen, einfach nur die iptables etwas prraktisch darstellen und editieren lassen. Eine ncurses Darstellung wär da ausreichend.
Trotz mehrmaligem Durchlesen bin ich mir zwar noch nicht sicher, was Du genau machen willst aber gibt es unter Deinem Linux evtl. nmcli und firewall-cmd? Die Beiden fand ich irgendwie ganz intuitiv.

Darf man fragen, was genau Du machst - hört sich bisschen nach Home-Lab und lernen an, stimmt das?


Greez

[Tech_FREAK_2000|GS]

[...]
bzw- wieso können Gäste die per Tun/Tap angeschlossen sind eignetlich nicht mit dem Hot kommunzieren? Aktuell ist es so, dass meine Manjaro VM per ethernet den Lappi anpingen kann, aber nicht den eigenen Host - dabei wird das alles ja über den Lappi gebridget. o.O
[...]


Wenn ich das richtig in Erinnerung habe (aus der Richtung Qemu Macvtap bridging), ist dies "by design" wenn das interface im Bridge Modus betrieben wird.

Die Datenpakete werden vom Kernel direkt auf das physikalische Netzwerkinterface geschickt, von dort aus können die nicht mehr vom Kernel "transparent" zurückgeleitet werden.

Eine Lösung u.A war wohl der Einsatz eines sogenannten Softwareswitches (openvSwitch) oder ein separates (virtuelles) Netzwerkinterface welches den Host mit dem Gast verbindet.

[Simon Moon]

Trotz mehrmaligem Durchlesen bin ich mir zwar noch nicht sicher, was Du genau machen willst aber gibt es unter Deinem Linux evtl. nmcli und firewall-cmd? Die Beiden fand ich irgendwie ganz intuitiv.


Den Networkmanager (nmcli) hab ich bewusst nicht installiert. Der macht prinzipiell mal was er will, ausser man verbietet es ihm explizit. Daher ist er imo nicht so geeignet in einer experimentellen Umgebung, wo ich genau nachvollziehen möchte, was nun wieso geschieht. Ich verwende aktuell dhcpcd für die Verbindung vom Laptop zum Internet und dnsmasq für den dhcp service der VMs.


Die Firewall geht schon mit iptables-save / restore - aber mit dem NAT für virbr und ethernet wird es halt etwas unübersichtlich. Irgend ein Tool, welches die Reglen anzeigt und leicht bearbeiten lässt, wäre cool - aktuell mach ich das halt via Kate.


Darf man fragen, was genau Du machst - hört sich bisschen nach Home-Lab und lernen an, stimmt das?


Jo, ist eigentlich aus reiner Neugier.



itches (openvSwitch) oder ein separates (virtuelles) Netzwerkinterface welches den Host mit dem Gast verbindet.


Hmm, das bringt mich jetzt auf eine Idee. Wenn ich virbr10 nun ein virbr10:1 mit ip im Subnet des Servers zuweis, bridget der dann den Traffic auch ins "alte" Subnet der lokalen Laptop VMs? hmm....

[Acid-Beatz]

Den Networkmanager (nmcli) hab ich bewusst nicht installiert. Der macht prinzipiell mal was er will, ausser man verbietet es ihm explizit. Daher ist er imo nicht so geeignet in einer experimentellen Umgebung, wo ich genau nachvollziehen möchte, was nun wieso geschieht.
Wie genau meinst Du, "Er macht, was er will" :smile:
Also meiner Beobachtung nach macht er genau das, was man ihm sagt. Auf der anderen Seite verstehe ich natürlich auch, dass es einfacher geht etwas z.B in resolv.conf direkt zu schreiben. Aber war nur ein Vorschlag, deshalb hab ich ihn eben genannt.


Die Firewall geht schon mit iptables-save / restore - aber mit dem NAT für virbr und ethernet wird es halt etwas unübersichtlich. Irgend ein Tool, welches die Reglen anzeigt und leicht bearbeiten lässt, wäre cool - aktuell mach ich das halt via Kate.
Ich hab zwar selber noch nicht damit gearbeitet aber wär evtl. das Firewall-Configuration-Tool was für Dich: Gui für firewall-cmd eben.


Greez

[Simon Moon]

Wie genau meinst Du, "Er macht, was er will" :smile:



Der NM ist prinzipiell so konfigueriert, dass er zuerst mal alles unternimmt, was du ihm nicht explizit verboten hast. Zudem startet systemd das Teil auch liebend gerne, kurz nachdem du ihn beendete hast, wieder neu. Zuverlässig abstellen konnte ich den nur relativ radikal, indem ich den service gestoppt und den NM danach maskiert hab :freak:


Also meiner Beobachtung nach macht er genau das, was man ihm sagt. Auf der anderen Seite verstehe ich natürlich auch, dass es einfacher geht etwas z.B in resolv.conf direkt zu schreiben. Aber war nur ein Vorschlag, deshalb hab ich ihn eben genannt.



Direkt in resolv.conf zu schreiben ist meist eher eine schlechte Idee. Wenn der NetworkManager nicht läuft, wird das einfach von resolvconf überschrieben oder von dnsmasq nut widerwillig übernommen. Dhcpcd zickt da dann auch rum. Am zuverlästigsten ist es, wenn in dem Fall der DNS-Server über interfaces definiert wird - die darf man dann aber wiederum bloss nicht auf .. inet dhcp stellen, sondern muss inet manuell eintragen - ansonsten quitiert dhcpcd sinen Dienst und verteilt die IPs nicht. Alternativ geht auch dnsmasq nicht als service zu starten, sondern als normales Programm und einfach den DNS Server als Option hinten ranhängen.




Ich hab zwar selber noch nicht damit gearbeitet aber wär evtl. das Firewall-Configuration-Tool was für Dich: Gui für firewall-cmd eben.



Das Tool versteh ich irgendwie nicht. Mein Problem ist so auch weniger, dass ich die iptables nicht verstehen würde, als viel mehr das ganze in mit allen Chains und Tables zu unübersichtlich wird. Aber ich muss da wohl einfach mal etwas mehr voraus planen. Aber ich brenne da jetzt nicht so drauf - gibt noch so viel, das ich grad spannender finde.