Soluzione 1:
Per collegare il Wi-Fi puoi usare iw strumento per abilitare 4addr allo stesso modo:
# iw dev <wifiInterface> set 4addr on
vale a dire:
# brctl addif <bridgename> <wifiInterface>
can't add <wifiInterface> to bridge <bridgename>: Operation not supported
# iw dev <wifiInterface> set 4addr on
# brctl addif <bridgename> <wifiInterface>
Ora dovrebbe funzionare. Puoi mostrare i ponti usando:
# brctl show
Soluzione 2:
AGGIORNA
Non è possibile eseguire il bridge tra le interfacce wireless (client a.k.a. station mode) e cablate secondo questo thread su linux-ath5k-devel.
Imposta NAT
Si dovrebbe invece impostare NAT:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
Assegnazione di un IP
Quindi devi assegnare gli indirizzi IP a te stesso:
ifconfig eth0 10.0.0.1 netmask 255.255.255.0 up
Installa il demone dhcp
Installa un server dhcp e aggiungi il seguente testo al suo file di configurazione (in /etc/dhcpd.conf o qualcosa di simile)
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.100 10.0.0.120;
option routers 10.0.0.1;
option domain-name-servers the-ip-address-you-have-in-etc-resolv.conf;
}
Avvia dhcpd
Quindi avvialo /etc/init.d/dhcpd start
E questo è tutto!
Leggi di seguito solo se sei interessato alla configurazione del bridging non funzionante
brctl addbr mybridge
brctl addif mybridge eth0
brctl addif mybridge wlan0
Per prima cosa crei un'interfaccia bridge, scelgo un nome arbitrario mybridge quindi aggiungi le interfacce ad esso.
Dovresti richiedere un nuovo indirizzo IP (questo è necessario solo se desideri ottenere un IP valido per il dispositivo di bridging stesso):
dhclient -d mybridge
Soluzione 3:
Bridge wlan e 4addr:
Il bridging di wlan0 è un problema. Normalmente non è possibile aggiungerlo a un'interfaccia bridge (brctl restituisce "Operazione non consentita") e l'utilizzo del filtro "bridged" di VirtualBox si traduce in un gran casino di conflitti ARP e DHCP. La causa di ciò è che i frame 802.11 contengono solo tre indirizzi per impostazione predefinita:gli indirizzi MAC di entrambi i dispositivi wireless (laptop e AP) e del destinatario finale (come in Ethernet). Si presuppone sempre che esista un solo possibile creatore.
802.11 può trasportare il quarto indirizzo MAC dell'originatore e questo viene utilizzato in modalità WDS dai ripetitori. Questa funzione può essere abilitata anche su Linux, utilizzando iw, e l'abilitazione di questa modalità consentirà l'utilizzo di wlan0 nelle interfacce bridge, nonché con il networking bridge di VirtualBox:
iw dev wlan0 set 4addr on
Tuttavia, con 4addr abilitato, è probabile che tu venga completamente ignorato dall'AP:l'associazione riesce ma tutti i frame di dati scompaiono nell'etere. Questo potrebbe essere per motivi di sicurezza (perché è dannatamente difficile falsificare l'indirizzo MAC di origine. Sì.) Nel mio router (che esegue OpenRG), è necessario abilitare la modalità "WDS" per l'interfaccia AP wireless, aggiungere un dispositivo WDS limitato al mio l'indirizzo MAC del laptop e aggiungerlo al bridge LAN. I pacchetti 4addr ora funzionano.
C'è un altro problema con questo, però:il router ora rifiuta i pacchetti a tre indirizzi dal laptop, il che può essere piuttosto scomodo (dovendo attivare 4addr ogni volta che la rete WLAN viene cambiata). La soluzione consiste nell'aggiungere, sul laptop, una seconda interfaccia wireless collegata allo stesso dispositivo, ma con un indirizzo MAC diverso. Per prima cosa annulla la configurazione precedente:
iw dev wlan0 set 4addr off
Quindi, aggiungi una seconda interfaccia (il nome è stato scelto arbitrariamente) con un indirizzo MAC diverso:
iw dev wlan0 interface add wds.wlan0 type managed 4addr on
ip link set dev wds.wlan0 addr <addr>
ip link set dev wds.wlan0 up
Qui deve corrispondere l'indirizzo del dispositivo WDS configurato nel router; a parte questo, può essere qualsiasi indirizzo MAC valido. Il MAC originale di wlan0 rimane quindi per un utilizzo "normale".
È possibile utilizzare sia wlan0 che wds.wlan0 contemporaneamente, anche se ho testato l'associazione allo stesso AP solo due volte, non ad AP diversi. Immagino che dovrebbero almeno essere sullo stesso canale.
Alcune persone hanno chiesto perché usarlo quando VirtualBox può collegare il WiFi "bene". La risposta è che VirtualBox non invia gli indirizzi MAC delle macchine virtuali; piuttosto, esegue NAT anche a livello MAC. – 22-08-2014
Ponte wlan diretto
In determinate circostanze, potresti anche utilizzare wlan_kabel. Utilizza i socket dei pacchetti per collegare direttamente i dispositivi wlan* con i dispositivi ethernet. Tuttavia, puoi collegare un solo MAC alla volta con wlan_kabel. Non ha l'inconveniente di essere bloccato dai punti di accesso, perché viene utilizzato solo il MAC originale del dispositivo WLAN. Nel tuo caso ciò significherebbe che wlan0 potrebbe essere utilizzato solo da una VM e nemmeno dall'host. Puoi ottenere wlan_kabel qui. È simile alla soluzione macvlans.
Bridging con ipvlan
IP Vlan non ha la limitazione di un bridge, potrebbe essere utilizzato per collegare una rete, i dettagli su come utilizzarlo possono essere trovati qui
Alternativa mascherata
L'instradamento Linux può essere utilizzato invece con iptables-masquerade e ip_forward per ottenere un bridge, ma come detto ciò richiede di abilitare ip_forward e farà in modo che Linux si comporti come un router, questo deve essere configurato con attenzione perché potrebbe introdurre qualche problema di sicurezza.
# bridge setup
brctl addbr br0
ifconfig br0 10.10.20.1/24 up
# enable ipv4 forwarding
echo "1" > /proc/sys/net/ipv4/ip_forward
# netfilter cleanup
iptables --flush
iptables -t nat -F
iptables -X
iptables -Z
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
# netfilter network address translation
iptables -t nat -A POSTROUTING -o wlan0 -s 10.10.20.0/24 -j MASQUERADE
L'interfaccia br0 avrà quindi accesso alla rete wlan0
Importante e correlato
Inoltre, cosa molto importante, non dovresti usare comandi obsoleti e deprecati come ifconfig, brctl , e così via. La suite iproute2 contiene comandi per tutto questo, inclusa la configurazione di interfacce virtuali (qualcosa per cui una volta dovevamo usare openvpn) e la creazione di bridge. Se non sai come impostare un bridge con ip, eccoci qua
ip tuntap add tap0 mode tap user root
ip link set tap0 up
ip link add br0 type bridge
ip link set tap0 master br0
ip link set eth0 master br0
ip addr add 10.173.10.1/24 dev br0
ip link set br0 up
Con questo set di comandi, creiamo un'interfaccia virtuale chiamata tap0, quindi un bridge chiamato br0, quindi asserviamo eth0 e tap0 al bridge, a cui assegniamo un indirizzo IP di 10.173.10.1, quindi portiamo tutto su. Sono necessarie le tre istanze separate di attivazione delle interfacce (per tap0, eth0 e br0).
Il trucco per farlo funzionare è utilizzare proxy.arp, che consente al tuo PC (non al tuo contenitore VM/Linux/spazio dei nomi di rete) di rispondere alle query ARP al loro posto.
In altre parole, utilizzando l'inoltro IPv4 tra la tua interfaccia hardware e la tua interfaccia virtuale, pensi di poter connettere la tua VM/LXC/NNS alla tua LAN come se fosse un'interfaccia fisica, ma questo non è vero:stai dimenticando l'assolutamente traffico ARP fondamentale, che è ciò che consente veramente alla LAN di funzionare. Quindi, il problema è:se inoltro correttamente il traffico IPv4, come posso inoltrare anche il traffico ARP, in modo che la mia VM/LXC/NNS funzioni? Il trucco è usare proxy-arp.
La risposta completa è nel blog di Bohdi Zazen, dal titolo rivelatore:Bridge wireless cards. Usa un pacchetto obsoleto, uml-utilities, per creare un'interfaccia virtuale tramite il comando tunctl:questo è l'unico comando per il quale usa uml-utilities, quindi puoi tranquillamente trascurare di scaricare il pacchetto, e usare il comando I scritto sopra per creare un'interfaccia tap o tun, qualunque cosa tu voglia, basta modificare il comando di conseguenza. quindi crea una coppia veth per il tuo LXC e ora crea un ponte tra tap0 e veth0. Questo bridge, chiamato br0, è ciò per cui devi eseguire il proxy-arp, invece della semplice interfaccia tap0 descritta da Bohdi Zazen.
Fonti:askubuntu.com, nullroute.eu.org, firejail.wordpress.com, superuser.com
Soluzione 4:
Dipende da quanto è cattivo per te l'AP:
1) Potrebbe voler vedere solo i pacchetti provenienti da te, con il tuo indirizzo di livello di collegamento noto (e quindi non di pacchetti con bridge) 2) Potrebbe effettivamente essere ancora più intelligente e sapere quale indirizzo IP dovrebbe appartenere a quale indirizzo di livello di collegamento (causa conosce il DHCP e lo ispeziona)
Se 1+2 sono entrambi veri, hai davvero bisogno di qualcosa come IP NAT, DHCP, ..
Ma se solo 1) è il caso, puoi falsificare l'indirizzo del livello di collegamento e mapparlo al contrario su quello giusto nell'altra direzione come descritto qui:
https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC
Soluzione 5:
4addr come descritto in altre risposte è sicuramente il modo migliore se supportato dall'adattatore/driver, ma non tutti lo fanno. NAT potrebbe funzionare per alcune cose, ma ottenere una comunicazione corretta in entrambe le direzioni sulla lan diventerà problematico (ad esempio, collegare una stampante o accedere ad altri dispositivi IoT dall'altra parte del NAT). Tutto ciò che si basa su broadcast/multicast (ad es. auto-discovery, bonjour) fallirà attraverso il NAT.
L'alternativa è usare un proxy ARP (parprouted) come descritto in https://wiki.debian.org/BridgeNetworkConnectionsProxyArp. L'ho configurato su un Raspberry Pi per una stampante e funziona a meraviglia (ho aggiunto 10 secondi di sospensione nel post-up comandi per fargli ottenere prima un indirizzo IP, potrebbe avere a che fare con la lentezza del mio vecchio RPi...)