Solución:
Solución 1:
Para puente wifi interfaz que puede utilizar iw herramienta para habilitar 4addr igualmente:
# iw dev set 4addr on
es decir:
# brctl addif
can't add to bridge : Operation not supported
# iw dev set 4addr on
# brctl addif
Ahora debería funcionar. Puede mostrar puentes usando:
# brctl show
Solucion 2:
ACTUALIZAR
No es posible hacer un puente entre las interfaces inalámbricas (cliente, también conocido como modo de estación) e interfaces cableadas de acuerdo con este hilo en linux-ath5k-devel.
Configurar NAT
En su lugar, se debe configurar NAT:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
Asignar una IP
Entonces tienes que asignarte direcciones IP a ti mismo:
ifconfig eth0 10.0.0.1 netmask 255.255.255.0 up
Instalar el 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!
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 dispositivo de puente):
dhclient -d mybridge
Solución 3:
Puente wlan y 4addr:
Puentear wlan0 es un fastidio. Normalmente no puede agregarlo a una interfaz de 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 (computadora portátil 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 interfaces de puente, así como con redes de 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 se realiza correctamente, 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, agregar un dispositivo WDS restringido a mi la 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 se eligió 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
ip link set dev wds.wlan0 up
Aquí debe coincidir con la dirección del dispositivo WDS configurada en el enrutador; Aparte de eso, puede ser cualquier dirección MAC válida. La MAC original de wlan0 permanece para uso “normal”.
Es posible usar wlan0 y wds.wlan0 al mismo tiempo, aunque solo he probado la asociación al mismo AP dos veces, no a diferentes AP. Supongo que tendrían que estar al menos en el mismo canal.
Algunas personas han preguntado por qué usar esto cuando VirtualBox puede puentear WiFi “muy 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. – 22-08-2014
Puente wlan directo
En determinadas circunstancias, también puede utilizar wlan_kabel. Utiliza sockets de paquetes para conectar directamente dispositivos wlan * con dispositivos ethernet. Sin embargo, solo puede puentear una sola MAC a la vez con wlan_kabel. No tiene el inconveniente de estar bloqueado por puntos de acceso, porque solo se usa la MAC original del dispositivo wlan. En su caso, esto significaría que wlan0 solo podría ser utilizado por una máquina virtual y ni siquiera por el host. Puedes conseguir wlan_kabel aquí. Esto es similar a la solución macvlans.
Puente con ipvlan
IP Vlan no tiene la limitación de un puente, podría usarse para puentear 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, esto debe configurarse con cuidado porque podría introducir 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á acceso a la red wlan0
Importante y relacionado
Además, y muy importante, no debe utilizar comandos obsoletos y obsoletos como ifconfig, brctl, etcétera. La suite iproute2 contiene comandos para todo esto, incluida la configuración de interfaces virtuales (algo para lo que una vez tuvimos que usar openvpn) y la creación de puentes. Si no sabes cómo montar 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 cual le asignamos una dirección IP de 10.173.10.1, luego lo mostramos todo. Se requieren las tres instancias separadas de 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 contenedor VM / Linux / espacio de nombres de red) responda consultas ARP en su lugar.
En otras palabras, al usar el reenvío 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 así. true: se está olvidando del tráfico ARP absolutamente fundamental, que es lo que realmente permite que LAN funcione. 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 consiste en utilizar proxy-arp.
La respuesta completa a eso está en el Blog de Bohdi Zazen, con el título revelador: Tarjetas inalámbricas Bridge. Utiliza un paquete obsoleto, uml-utilities, para crear una interfaz virtual mediante el comando tunctl: este es el único comando para el que usa uml-utilities, por lo que puede descuidar la descarga del paquete y usar el comando I escribió arriba para crear una interfaz tap o tun, lo que desee, 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 sencilla 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 desee ver los paquetes que provienen de usted, con su dirección de capa de enlace conocida (y, por lo tanto, no de paquetes puenteados) 2) En realidad, podría ser aún más inteligente y saber qué dirección IP debería pertenecer a qué dirección de capa de enlace (porque conoce DHCP y lo inspecciona)
Si 1 + 2 son ambos true, 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 la dirección correcta 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 de IoT en el otro lado de la NAT). Todo lo que dependa de la transmisión / multidifusión (por ejemplo, autodescubrimiento, 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 como un encanto (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 …)
Si estás de acuerdo, puedes dejar un tutorial acerca de qué le añadirías a este ensayo.