2
Netzwerkzugriff von Host und VM über denselben WLAN-Adapter
Hallochen Gemeinde,
ein Notebook, auf dem bisher Windows 8.1, ist umgestellt auf Debian 11 und die Windows-Installation läuft nunmehr in einer VM auf der Basis von Qemu/KVM. Damit diese Windows-VM direkt auf das Netzwerk per LAN/Ethernet zugreifen kann, ist eine entsprechende Bridge ("br0") eingerichtet und die VM mit der virtuellen (LAN-)Netzwerkschnittstelle an diese Bridge gebunden. Sowohl die Windows-VM als auch Debian holen sich ihre IP-Adressen vom DHCP-Server des lokalen Netzwerks. So weit so gut - das läuft alles. Auf dem virtualisierten Windows kann so gearbeitet werden, als ob es immer noch auf der Hardware laufen würde.
Ähnlich wie bei der LAN-Verbindung möchte ich das bei der WLAN-Verbindung umsetzen, wenn das Notebook nicht per LAN, sondern per WLAN in das lokale Netzwerk eingebunden ist. Mir ist natürlich klar, dass die WLAN-Verbindung als solche nur zwischen dem WLAN-Adapter und dem Access Point aufgebaut wird und dass der Access Point nur die MAC-Adresse / IP des WLAN-Adapters akzeptieren wird. Mithin muss bei laufender Verbindung die MAC-/IP-Adresse der Windows-VM auf die MAC-/IP-Adresse des WLAN-Adapters übersetzt werden (in beiden Richtungen natürlich). Dieses Routing hat letztlich das Problem, dass die aktuelle IP-Adresse der Windows-VM beim DNS-Server eingetragen wird (beides AD-gebunden). Der Access Point ist aber nicht das Standardgateway, so dass das notwendige Routing wohl ins Leere laufen wird.
Wie kann ich dieses Problem lösen?
Als Ansatz habe ich zunächst Bridging Network Connections gefunden. Unter dem Punkt "Bridging with a wireless NIC" ist beschrieben, wie eine solche WLAN-Bridge eingerichtet werden kann. Die Bridge "br1" ist erstellt und ebtables ist bereits installiert. Aber die nachfolgenden Schritte habe ich noch nicht umgesetzt.
Daneben habe ich Anleitungen gefunden, die auf das Aktivieren von 4addr setzen. Die Aktivierung von 4addr funktioniert. Aber auch das habe ich noch nicht weiter umgesetzt.
Die Umsetzung habe ich deshalb nicht weiter vorangetrieben, weil mir das Routing und die weitere notwendige Konfiguration noch nicht ganz klar sind.
Verstehe ich die verlinkte Anleitung richtig, dass ich in dieser Konstellation der virtuellen (WLAN-)Netzwerkschnittstelle der Windows-VM eine feste interne IP-Adresse (aus einem anderen Netzwerksegment als dem lokalen Netzwerk) vergeben muss? Der Bridge selbst müsste ich dann ebenfalls eine solche feste IP-Adresse aus demselben anderen Netzwerksegment vergeben, richtig? Funktioniert das Ganze dann schon wie bei NAT? Oder müsste ich noch im lokalen Netzwerk eine Route für das andere Netzwerksegment mit der IP-Adresse der WLAN-Karte als Gateway einrichten? Wie gehe ich mit der Eintragung der IP-Adresse beim DNS-Server um?
Welche Schritte sind erforderlich im Falle des alternativen Weges über 4addr?
Im Voraus vielen Dank für Euren Input und viele Grüße
HansDampf06
ein Notebook, auf dem bisher Windows 8.1, ist umgestellt auf Debian 11 und die Windows-Installation läuft nunmehr in einer VM auf der Basis von Qemu/KVM. Damit diese Windows-VM direkt auf das Netzwerk per LAN/Ethernet zugreifen kann, ist eine entsprechende Bridge ("br0") eingerichtet und die VM mit der virtuellen (LAN-)Netzwerkschnittstelle an diese Bridge gebunden. Sowohl die Windows-VM als auch Debian holen sich ihre IP-Adressen vom DHCP-Server des lokalen Netzwerks. So weit so gut - das läuft alles. Auf dem virtualisierten Windows kann so gearbeitet werden, als ob es immer noch auf der Hardware laufen würde.
Ähnlich wie bei der LAN-Verbindung möchte ich das bei der WLAN-Verbindung umsetzen, wenn das Notebook nicht per LAN, sondern per WLAN in das lokale Netzwerk eingebunden ist. Mir ist natürlich klar, dass die WLAN-Verbindung als solche nur zwischen dem WLAN-Adapter und dem Access Point aufgebaut wird und dass der Access Point nur die MAC-Adresse / IP des WLAN-Adapters akzeptieren wird. Mithin muss bei laufender Verbindung die MAC-/IP-Adresse der Windows-VM auf die MAC-/IP-Adresse des WLAN-Adapters übersetzt werden (in beiden Richtungen natürlich). Dieses Routing hat letztlich das Problem, dass die aktuelle IP-Adresse der Windows-VM beim DNS-Server eingetragen wird (beides AD-gebunden). Der Access Point ist aber nicht das Standardgateway, so dass das notwendige Routing wohl ins Leere laufen wird.
Wie kann ich dieses Problem lösen?
Als Ansatz habe ich zunächst Bridging Network Connections gefunden. Unter dem Punkt "Bridging with a wireless NIC" ist beschrieben, wie eine solche WLAN-Bridge eingerichtet werden kann. Die Bridge "br1" ist erstellt und ebtables ist bereits installiert. Aber die nachfolgenden Schritte habe ich noch nicht umgesetzt.
Daneben habe ich Anleitungen gefunden, die auf das Aktivieren von 4addr setzen. Die Aktivierung von 4addr funktioniert. Aber auch das habe ich noch nicht weiter umgesetzt.
Die Umsetzung habe ich deshalb nicht weiter vorangetrieben, weil mir das Routing und die weitere notwendige Konfiguration noch nicht ganz klar sind.
Verstehe ich die verlinkte Anleitung richtig, dass ich in dieser Konstellation der virtuellen (WLAN-)Netzwerkschnittstelle der Windows-VM eine feste interne IP-Adresse (aus einem anderen Netzwerksegment als dem lokalen Netzwerk) vergeben muss? Der Bridge selbst müsste ich dann ebenfalls eine solche feste IP-Adresse aus demselben anderen Netzwerksegment vergeben, richtig? Funktioniert das Ganze dann schon wie bei NAT? Oder müsste ich noch im lokalen Netzwerk eine Route für das andere Netzwerksegment mit der IP-Adresse der WLAN-Karte als Gateway einrichten? Wie gehe ich mit der Eintragung der IP-Adresse beim DNS-Server um?
Welche Schritte sind erforderlich im Falle des alternativen Weges über 4addr?
Im Voraus vielen Dank für Euren Input und viele Grüße
HansDampf06
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1530506624
Url: https://administrator.de/forum/netzwerkzugriff-von-host-und-vm-ueber-denselben-wlan-adapter-1530506624.html
Ausgedruckt am: 22.12.2024 um 04:12 Uhr
2 Kommentare
Neuester Kommentar
und dass der Access Point nur die MAC-Adresse / IP des WLAN-Adapters akzeptieren wird.
Nein das ist Unsinn. Aus welchem Grunde sollte er denn NUR die Mac Adresse akzeptieren ??Ein Accesspoint arbeitet immer als einfache Bridge und akzeptiert erstmal ALLE Mac Adressen die ihn kontaktieren und eine Verbindung wollen. Das solltest du als Netzwerker schon wissen !
Die IP Adresse ist zudem völlig irrelevant, denn die spielt bei einem AP und WLAN Client keinerlei Rolle denn wie oben schon gesagt arbeitet ein AP rein auf Layer 2 Basis (Bridging) mit Mac Adressen.
Dort passiert also genau das was in deinem KVM passiert: Simples Bridging !
Die VM selber hat auch rein gar nichts damit zu tun. Einzig und allein dein Debian ist dafür zuständig. DER baut als Client mit den Credentials der wpa_supplicant Datei die WLAN Verbindung zum AP auf via Layer 2.
Es reicht also wenn du ganz einfach den WLAN Adapter des Debian auch in die KVM Bridge hängst und gut iss. Die VM holt sich dann via DHCP eine IP genauso wie sie es über das LAN Kabel macht. Dort passiert ja auch nur ein simples Bridging.
Ob also Draht oder Funk als Medium ist für die Funktion völlig Wumpe.
Kann es sein das du hier ggf. einen Denkfehler begehst ?!
Der Access Point ist aber nicht das Standardgateway,
Das ist ein Accesspoint NIE. Wie sollte das auch gehen wenn ein Gerät nur im L2 Mode (Bridging) arbeitet ?? Ein Gateway denigt immer KLayer 3 also Routing was ein AP in der Regel nie macht.Auch hier ggf. wieder ein Denkfehler ??
weil mir das Routing und die weitere notwendige Konfiguration noch nicht ganz klar sind.
Ist es dir den beim Kupfer Port klar ??Bei Funk ist das doch nichts anderes nur das das Trägermedium ein anderes ist. Wo ist denn da dein wirkliches Problem.
Vergiss also den Unsinn mit statischen IPs, NAT usw. Richte das WLAN Interface unter Debian ein das es das WLAN connectet und hänge es mit als Interface an den vSwitch (Bridge) des KVM. Fertisch...
... es ist an der Zeit, das Problem noch einmal aufzugreifen und endlich einer Lösung zuzuführen ...
@aqui: Weniger ein Denkfehler, als wohl eher etwas unpräzise ausgedrückt. Gemeint ist, um es mit anderen Worten auszudrücken:
Auch bei anderen kontextbezogenen Webseiten findet sich die gleichlautende Aussage/Erläuterung. Der Grund für dieses häufig anzutreffende Problem ist, dass bei den eingebauten WiFi-Karten die WDS-Funktionalität nicht implementiert ist. Denn mit der WDS-Funktionalität (oder 4addr) kann auch über einen WiFi-Port gebridget/geroutet/etc. werden.
Aber nun zur Problem"lösung":
Weil wir gerade bei WDS sind ...
... es ist zum aus der Haut fahren und sich die Haare raufen. Ich bin mir sehr sicher, dass ich zum Zeitpunkt der Beitragsveröffentlichung die WDS-Funktionalität des WLAN-Adapters nicht positiv feststellen konnte. Das zeigte sich bis vorgestern unter anderem darin, dass er nicht in eine brctl-Bridge eingebunden werden konnte, und was mich zu Open vSwitch führte. Nunmehr wurde ich zufällig eines Besseren belehrt. Als "Bösewicht" vermute ich connman, was im Zuge der jetzigen weiteren Suche nach einer Problemlösung gestoppt wurde.
Folge der Aktivierung ist, dass der WLAN-Adapter auch in einer brctl-Bridge als Interface eingebunden werden kann. Unter Open vSwitch war das ohnehin möglich. Unumgänglich bleibt (vorerst) nach meinem derzeitigen Stand der praktischen Austestungen, entweder den LAN-Adapter oder den WLAN-Adapter in die Bridge einzubinden. Ansonsten funktionieren beide Varianten insoweit identisch und so soll es sein.
Vorteil des "mühevollen" Aufwands bei der Lösungssuche in den letzten Tagen ist, dass ich zwangsläufig die passenden Scripte erstellt habe, um schnell wechseln etc. zu können.
Leider tut sich bei der praktischen WiFi-Nutzung ein neues praktisches Problem auf, was aber ein neues Fragethema ist.
Viele Grüße
HansDampf06
@aqui: Weniger ein Denkfehler, als wohl eher etwas unpräzise ausgedrückt. Gemeint ist, um es mit anderen Worten auszudrücken:
Q: I can’t seem to use Open vSwitch in a wireless network.
A: Wireless base stations generally only allow packets with the source MAC address of NIC that completed the initial handshake. Therefore, without MAC rewriting, only a single device can communicate over a single wireless link.
This isn’t specific to Open vSwitch, it’s enforced by the access point, so the same problems will show up with the Linux bridge or any other way to do bridging.
A: Wireless base stations generally only allow packets with the source MAC address of NIC that completed the initial handshake. Therefore, without MAC rewriting, only a single device can communicate over a single wireless link.
This isn’t specific to Open vSwitch, it’s enforced by the access point, so the same problems will show up with the Linux bridge or any other way to do bridging.
Auch bei anderen kontextbezogenen Webseiten findet sich die gleichlautende Aussage/Erläuterung. Der Grund für dieses häufig anzutreffende Problem ist, dass bei den eingebauten WiFi-Karten die WDS-Funktionalität nicht implementiert ist. Denn mit der WDS-Funktionalität (oder 4addr) kann auch über einen WiFi-Port gebridget/geroutet/etc. werden.
Aber nun zur Problem"lösung":
Weil wir gerade bei WDS sind ...
... es ist zum aus der Haut fahren und sich die Haare raufen. Ich bin mir sehr sicher, dass ich zum Zeitpunkt der Beitragsveröffentlichung die WDS-Funktionalität des WLAN-Adapters nicht positiv feststellen konnte. Das zeigte sich bis vorgestern unter anderem darin, dass er nicht in eine brctl-Bridge eingebunden werden konnte, und was mich zu Open vSwitch führte. Nunmehr wurde ich zufällig eines Besseren belehrt. Als "Bösewicht" vermute ich connman, was im Zuge der jetzigen weiteren Suche nach einer Problemlösung gestoppt wurde.
Folge der Aktivierung ist, dass der WLAN-Adapter auch in einer brctl-Bridge als Interface eingebunden werden kann. Unter Open vSwitch war das ohnehin möglich. Unumgänglich bleibt (vorerst) nach meinem derzeitigen Stand der praktischen Austestungen, entweder den LAN-Adapter oder den WLAN-Adapter in die Bridge einzubinden. Ansonsten funktionieren beide Varianten insoweit identisch und so soll es sein.
Vorteil des "mühevollen" Aufwands bei der Lösungssuche in den letzten Tagen ist, dass ich zwangsläufig die passenden Scripte erstellt habe, um schnell wechseln etc. zu können.
Leider tut sich bei der praktischen WiFi-Nutzung ein neues praktisches Problem auf, was aber ein neues Fragethema ist.
Viele Grüße
HansDampf06
