☰

Theoretisch: TAP-Schnittstelle mit übergeordneter WIFI-Schnittstelle

tag-icon • tag-icon wifi networkmanager dhcp bridge tap
Theoretisch: TAP-Schnittstelle mit übergeordneter WIFI-Schnittstelle

Ich versuche, mehrere Linux-TAP-Schnittstellen zu erstellen und ihnen das Senden/Empfangen von Paketen über einen einzigen WLAN-Adapter zu ermöglichen. Im Grunde möchte ich, dass die TAP-Schnittstellen als vollwertige Netzwerkadapter fungieren. Sie sollten in der Lage sein, ihre eigenen DHCP-Adressen anzufordern und im lokalen Netzwerk zu interagieren, wie es jeder andere Netzwerkadapter tun würde.

Ich habe es geschafft, dies mit einem Ethernet-Adapter zum Laufen zu bringen, aber ich habe gehört, dass WiFi ein ganz anderes Kaliber ist. Ich kann mich nicht an die genaue Begründung erinnern, aber es hatte etwas mit „1 IP-Adresse pro Radio-Broadcast-Adresse“ zu tun.

Ist es mithilfe von TAP-Schnittstellen möglich, Bridged Networking über eine WLAN-Verbindung zu betreiben? Kann ich die Konfiguration mit dem Netzwerkmanager vornehmen? Kann mir jemand einen oder zwei Artikel verlinken? Ich habe Schwierigkeiten, etwas dazu zu finden.

Antwort1

Dieser Network Engineering SE-LinkVier Layer-2-Adressen im 802.11-Frame-Headererklärt ganz gut den Unterschied zwischen Ethernet und WLAN.

WLAN erfordert zusätzliche MAC-Adressen für die Kommunikation: Zusätzlich zur Absenderadresse (SA) und Zieladresse (DA), die mit den Quell- und Ziel-MACs von Ethernet identisch sind, benötigt WLAN eine Senderadresse (TA) und eine Empfängeradresse (RA), um zu funktionieren: das ergibt insgesamt 4 MAC-Adressen. Da im Normalfall gilt, dass TA = SA ist, wenn der Client (STA) sendet, und DA = RA ist, wenn der Access Point (AP) an den STA sendet, werden normalerweise nur 3 Adressen benötigt, und so werden APs konfiguriert: um nur 3 der 4 möglichen Adressen zu verwenden.

Ein Client im Bridge-Modus bedeutet, dass über TA != SA oder DA != RA und alle 4 Adressen benötigt werden, während der AP nur für 3 konfiguriert ist. Deshalb ist es in gängigen Konfigurationen nicht möglich, WLAN zu überbrücken. Der 4-Adressen-Modus muss sowohl auf dem AP als auch auf der STA aktiviert sein, damit das Client-Bridging funktioniert. Dies wird normalerweise alsDrahtloses Verteilungssystem (WDS), aber es gibt wahrscheinlich mehrere inkompatible Implementierungen. AP und alle STA müssen eine kompatible Implementierung verwenden.

Also:

  • Wenn die Systemüberbrückung der AP ist, können Sie WLAN problemlos überbrücken: Das machen alle APs im Standardmodus mit 3 Adressen.

  • Wenn das System, das die Verbindung herstellen möchte, ein einfacher Client (STA) ist, funktioniert es nicht. Neuere Treiber verhindern sogar die Einstellung der drahtlosen Schnittstelle als Bridge-Port mit dieser Art von Fehler:

    # ip link set wlan0 master bridge0
Error: Device does not allow enslaving to a bridge.

  • wenn Sie konfigurieren könnenbeideden AP und die STA in ein kompatibles WDS, z. B. wenn auf allen Linux mit Treibern ausgeführt wird, die mit mac80211 kompatibel sind, kann dies auf der STA wie folgt aktiviert werden:

    # iw dev wlan0 set 4addr on

Dann kann es versklavt werden:

    # ip link set wlan0 master bridge0
    # ip link show wlan0
    3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue master bridge0 state DOWN mode DEFAULT group default qlen 1000
    [...]

Einige Dokumentationen zum 4-Adressmodus mit dem Befehl iw finden Sie im Linux Wireless-Wiki:Verwenden von 4-Adressen für AP- und Client-Modus

Die Konfiguration des APs liegt hier außerhalb des Geltungsbereichs. Bei VerwendungHostapd, muss eine spezielle Einstellung aktiviert werden:

# WDS (4-address frame) mode with per-station virtual interfaces
# (only supported with driver=nl80211)
# This mode allows associated stations to use 4-address frames to allow layer 2
# bridging to be used.
#wds_sta=1

Es gibt noch einen Workaround, der es erlaubt, mehrere Container oder VMs gleichzeitig mit unterschiedlichen IPs über eine einzige WLAN-Verbindung im Standardmodus (3-Adressen-Modus) zu verwenden, aber nureinsMAC-Adresse (die als STA verwendete): es ist alsonormalerweise nicht mit DHCP kompatibeldie standardmäßig auf der MAC-Adresse basiert (es sei denn, der DHCP-Server akzeptiert dieDHCP-Client-KennungMöglichkeit). Es heißtIPVLAN(normalerweise für Container) und sein TAP-Gegenstück (normalerweise für VMs) heißtIPVTAP. Bei Verwendung im L2-Modus bietet es etwas, das wie eine Standard-Ethernet-Schnittstelle aussieht.

Für eine (einfacheIP-NetzeNetzwerk) Container könnte dies wie folgt verwendet werden, nachdem bereits eine WLAN-Verbindung im IP-LAN 192.0.2.0/24 mit Gateway 192.0.2.1 auf dem Host über die Schnittstelle hergestellt wurdewlan0:

# ip netns add testwifi
# ip link add link wlan0 name ipvl0 type ipvlan mode l2
# ip link set dev ipvl0 netns testwifi up
# ip -n testwifi address add 192.0.2.99/24 dev ipvl0
# ip -n testwifi route add default via 192.0.2.1
# ip netns exec testwifi ping -q -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.372/5.372/5.372/0.000 ms

Ich bezweifle ernsthaft, dass NetworkManager eine Option für den 4-Adressen-Modus hat. WasIPVLAN/IPVTAPDies muss von der Container-/Virtualisierungsanwendung unterstützt werden, wieLXCoder libvirt (das IPVTAP anscheinend nicht nativ unterstützt), nicht wirklich von NetworkManager.

verwandte Informationen