Solución 1:
Para puente wifi interfaz que puede usar iw herramienta para habilitar 4addr igualmente:
# iw dev <wifiInterface> set 4addr on
es decir:
# brctl addif <bridgename> <wifiInterface>
can't add <wifiInterface> to bridge <bridgename>: Operation not supported
# iw dev <wifiInterface> set 4addr on
# brctl addif <bridgename> <wifiInterface>
Ahora debería funcionar. Puede mostrar puentes usando:
# brctl show
Solución 2:
ACTUALIZAR
No es posible establecer un puente entre las interfaces inalámbricas (cliente, también conocido como modo de estación) y las interfaces cableadas de acuerdo con este hilo en linux-ath5k-devel.
Configurar NAT
Uno debería configurar NAT en su lugar:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
Asignación de una IP
Luego tienes que asignarte direcciones IP a ti mismo:
ifconfig eth0 10.0.0.1 netmask 255.255.255.0 up
Instalar demonio dhcp
Instale un servidor dhcp y agregue el siguiente texto a su archivo de configuración (en /etc/dhcpd.conf o algo similar)
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;
}
Iniciar dhcpd
Luego inícielo /etc/init.d/dhcpd start
¡Y eso es todo!
Solo lea a continuación si está interesado en la configuración de puente que no funciona
brctl addbr mybridge
brctl addif mybridge eth0
brctl addif mybridge wlan0
Primero creas una interfaz de puente. Elijo un nombre arbitrario mybridge luego agréguele interfaces.
Debe solicitar una nueva dirección IP (esto es necesario solo si desea obtener una IP válida para el propio dispositivo puente):
dhclient -d mybridge
Solución 3:
Puente wlan y 4addr:
Puente wlan0 es un dolor. Normalmente no puede agregarlo a una interfaz puente (brctl devuelve "Operación no permitida"), y el uso del filtro "puenteado" de VirtualBox da como resultado un gran lío de conflictos ARP y DHCP. La causa de esto es que las tramas 802.11 contienen solo tres direcciones por defecto:las direcciones MAC de ambos dispositivos inalámbricos (laptop y AP) y del destinatario final (como en Ethernet). Siempre se asume que solo hay un posible originador.
802.11 puede transportar la cuarta dirección MAC del originador, y los repetidores la utilizan en modo WDS. Esta función también se puede habilitar en Linux, usando iw, y habilitar este modo permitirá que wlan0 se use en las interfaces de puente, así como con las redes en puente de VirtualBox:
iw dev wlan0 set 4addr on
Sin embargo, con 4addr habilitado, es probable que el AP lo ignore por completo:la asociación tiene éxito, pero todos los marcos de datos desaparecen en el éter. Esto podría deberse a razones de seguridad (porque es muy difícil falsificar la dirección MAC de origen. Sí). En mi enrutador (que ejecuta OpenRG), es necesario habilitar el modo "WDS" para la interfaz AP inalámbrica, agregue un dispositivo WDS restringido a mi dirección MAC de la computadora portátil y agréguela al puente LAN. Los paquetes 4addr ahora funcionan.
Sin embargo, hay otro problema con esto:el enrutador ahora rechaza los paquetes de tres direcciones de la computadora portátil, lo que puede ser bastante inconveniente (tener que alternar 4addr cada vez que se cambia la red WLAN). La solución es agregar, en la computadora portátil, una segunda interfaz inalámbrica vinculada al mismo dispositivo, pero con una dirección MAC diferente. Primero deshaga la configuración anterior:
iw dev wlan0 set 4addr off
Luego, agregue una segunda interfaz (el nombre fue elegido arbitrariamente) con una dirección MAC diferente:
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
Aquí debe coincidir la dirección del dispositivo WDS configurada en el enrutador; aparte de eso, puede ser cualquier dirección MAC válida. El MAC original de wlan0 permanece para uso "normal".
Es posible usar wlan0 y wds.wlan0 al mismo tiempo, aunque solo probé la asociación al mismo AP dos veces, no a diferentes AP. Supongo que al menos tendrían que estar en el mismo canal.
Algunas personas han preguntado por qué usar esto cuando VirtualBox puede conectar WiFi "bien". La respuesta es que VirtualBox no envía las direcciones MAC de las máquinas virtuales; más bien, también realiza NAT en la capa MAC. – 2014-08-22
Puente wlan directo
En determinadas circunstancias, también podría utilizar wlan_kabel. Utiliza sockets de paquetes para unir directamente dispositivos wlan* con dispositivos ethernet. Sin embargo, solo puede conectar un solo MAC a la vez con wlan_kabel. No tiene el inconveniente de estar bloqueado por puntos de acceso, ya que solo se utiliza la MAC original del dispositivo wlan. En su caso, esto significaría que wlan0 solo podría ser utilizado por una VM y ni siquiera por el host. Puede obtener wlan_kabel aquí. Esto es similar a la solución macvlans.
Conexión con ipvlan
IP Vlan no tiene la limitación de un puente, podría usarse para conectar una red. Los detalles sobre cómo usarlo se pueden encontrar aquí
Alternativa a la mascarada
El enrutamiento de Linux se puede usar en su lugar con iptables-masquerade e ip_forward para lograr un puente, pero como se mencionó, esto requiere habilitar ip_forward y hará que Linux actúe como un enrutador. Esta debe configurarse con cuidado porque podría presentar algún problema de seguridad.
# 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
La interfaz br0 tendrá entonces acceso a la red wlan0
Importante y relacionado
Además, y muy importante, no debe usar comandos obsoletos y obsoletos como ifconfig, brctl , y así. La suite iproute2 contiene comandos para todo esto, incluida la configuración de interfaces virtuales (algo para lo que alguna vez tuvimos que usar openvpn) y la creación de puentes. Si no sabes cómo configurar un puente con ip, aquí vamos
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 este conjunto de comandos, creamos una interfaz virtual llamada tap0, luego un puente llamado br0, luego esclavizamos eth0 y tap0 al puente, al que asignamos una dirección IP de 10.173.10.1, luego lo activamos todo. Se requieren las tres instancias separadas para activar las interfaces (para tap0, eth0 y br0).
El truco para hacer que esto funcione es usar proxy.arp, que permite que su PC (no su VM/contenedor Linux/espacio de nombres de red) responda consultas ARP en su lugar.
En otras palabras, al usar el reenvío de IPv4 entre su interfaz de hardware y su interfaz virtual, cree que puede conectar su VM/LXC/NNS a su LAN como si fuera una interfaz física, pero esto no es cierto:se está olvidando absolutamente tráfico ARP fundamental, que es lo que verdaderamente permite operar a la LAN. Entonces, el problema es:si reenvío correctamente el tráfico IPv4, ¿cómo puedo reenviar también el tráfico ARP para que mi VM/LXC/NNS funcione? El truco es usar proxy-arp.
La respuesta completa a eso está en el Blog de Bohdi Zazen, con el título revelador:Tarjetas inalámbricas puente. Utiliza un paquete obsoleto, uml-utilities, para crear una interfaz virtual mediante el comando tunctl:este es el único comando para el que utiliza uml-utilities, por lo que puede olvidarse de descargar el paquete y utilizar el comando I escribió anteriormente para crear una interfaz de tocar o sintonizar, lo que quiera, simplemente modifique el comando en consecuencia. luego cree un par veth para su LXC, y ahora cree un puente entre tap0 y veth0. Este puente, llamado br0, es para lo que debe usar proxy-arp, en lugar de la simple interfaz tap0 descrita por Bohdi Zazen.
Fuentes:askubuntu.com, nullroute.eu.org, firejail.wordpress.com, superuser.com
Solución 4:
Depende de lo malo que sea el AP para ti:
1) Es posible que solo quiera ver los paquetes que provienen de usted, con su dirección de capa de enlace conocida (y, por lo tanto, no de paquetes en puente) 2) En realidad, podría ser incluso más inteligente y saber qué dirección IP debe pertenecer a qué dirección de capa de enlace (porque conoce DHCP y lo inspecciona)
Si 1+2 son ambos verdaderos, de hecho necesita algo como IP NAT, DHCP, ..
Pero si solo 1) es el caso, puede falsificar la dirección de la capa de enlace e invertirla en el mapa correcto en la otra dirección como se describe aquí:
https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC
Solución 5:
4addr como se describe en otras respuestas es sin duda la mejor manera cuando es compatible con el adaptador/controlador, pero no todos lo hacen. NAT puede funcionar para algunas cosas, pero obtener una comunicación adecuada en ambos sentidos en la LAN se volverá problemático (por ejemplo, conectar una impresora o acceder a otros dispositivos IoT en el otro lado de la NAT). Todo lo que dependa de la transmisión/multidifusión (p. ej., detección automática, bonjour) fallará a través de NAT.
La alternativa es usar un Proxy ARP (parprouted) como se describe en https://wiki.debian.org/BridgeNetworkConnectionsProxyArp. Configuré esto en una Raspberry Pi para una impresora y funciona de maravilla (he agregado una suspensión de 10 segundos en el post-up comandos para permitirle obtener una dirección IP primero, podría tener que ver con la lentitud de mi antiguo RPi...)