En Arch Linux, me gustaría que eth0 (conectado al enrutador en puente) comparta la conexión recibida de wlan0, he leído los tutoriales pero no conozco los comandos como lo hacen otros usuarios y no entiendo completamente.
por favor no ponga '[resuelto]' en la pregunta o título, aceptar una respuesta es la forma correcta de mostrar que se resolvió un problema. Cambia la forma en que se muestra la pregunta en la lista principal y pone la marca de verificación verde en la respuesta que ha marcado como correcta.
Zypher
1
Agradecería que nadie se metiera con esta página. Si tiene algún problema, contácteme. Gracias.
dbdii407
13
serverfault.com/faq Específicamente el encabezado "Otras personas pueden editar mis cosas"
Zypher
@Zypher La URL a la que enlaza ya no existe. ¿Se ha trasladado el párrafo correspondiente a otra parte?
En realidad, no necesita una dirección IP para la interfaz del puente para que el puente funcione.
Massimo
77
no se puede agregar wlan0 al puente mybridge: Operación no admitida
dbdii407
1
@ Massimo: sí, eso es cierto. La IP válida es necesaria para acceder a la red desde el "dispositivo puente".
cstamas
10
NAT es algo completamente diferente del puente. Bridging es la capa dos, NAT es la capa tres y específico de IPv4. No entiendo por qué esta es una respuesta aceptada.
WhyNotHugo
3
@Hugo IP NAT es la capa 3, pero MAC NAT es la capa 2. Para el enlace WiFi, puede usar 4addr, WDS, MAC NAT o puede hacer algo en la capa 3 (como IP NAT).
David Schwartz
27
Para conectar la interfaz wifi , puede usar la iwherramienta para habilitar 4addr de la misma manera:
# 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:
¿Para qué es esta configuración y por qué sugiere específicamente usarla en este escenario?
Hakre
Esta es una solución para el error "Operación no permitida" al intentar agregar la interfaz wlan0 a la interfaz del puente. Después de eso, debe especificar la interfaz del puente en / etc / network / interfaces para que aparezca después del inicio.
Str82DHeaD
1
@hakre El 4addrmodo hace que WiFi se comporte lo suficiente como Ethernet por cable para que el puente funcione. Sin él, el puente no funcionará sin NAT.
David Schwartz
1
4addrrequiere que ambos lados de un enlace inalámbrico lo admitan (suponiendo que intente implementar un extensor wifi)
nhed
5
Depende de lo malo que sea el AP para usted:
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 los paquetes en puente) 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 (causa 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 la dirección correcta en la otra dirección como se describe aquí:
Esto es realmente desordenado. Y requiere una configuración adicional cada vez que agrega una nueva computadora.
Michael Hampton
4
4addr como se describe en otras respuestas es ciertamente la mejor manera cuando es compatible con el adaptador / controlador, pero no todos lo hacen. NAT podría funcionar para algunas cosas, pero obtener una comunicación adecuada en ambos sentidos en la LAN será 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 (por ejemplo, autodescubrimiento, bonjour) fallará a través del NAT.
La alternativa es utilizar un Proxy ARP (parprouted) como se describe en https://wiki.debian.org/BridgeNetworkConnectionsProxyArp . Lo configuré en una Raspberry Pi para una impresora y funciona de maravilla (he agregado una suspensión de 10 segundos en los post-upcomandos para que primero obtenga una dirección IP, podría tener que ver con la lentitud de mi antiguo RPi ...)
Este enlace a la solución proxy-arp plus dhcp-helper es la solución más compatible y limpia hasta ahora que he visto.
minghua
3
Puente wlan y 4addr:
Unir wlan0 es un dolor. Por lo general, no puede agregarlo a una interfaz de puente (brctl devuelve "Operación no permitida"), y el uso del filtro "puenteado" de VirtualBox genera una gran confusión 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 supone que solo hay un posible originador.
802.11 puede transportar la cuarta dirección MAC del originador, y esto es utilizado en modo WDS por los repetidores. Esta característica 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 la red puenteada 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 ser por 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 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 consiste en 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 con 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 tanto wlan0 como wds.wlan0 al mismo tiempo, aunque solo he probado asociarme 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 conectar WiFi "bien". La respuesta es que VirtualBox no envía las direcciones MAC de las máquinas virtuales; más bien, realiza NAT en la capa MAC también. - 2014-08-22
Puente wlan directo
Bajo ciertas circunstancias, también podría usar wlan_kabel. Utiliza sockets de paquetes para conectar 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, porque solo se usa el MAC original del dispositivo wlan. En su caso, esto significaría que wlan0 solo puede ser utilizado por una VM y ni siquiera por el host. Puedes obtener wlan_kabel aquí . Esto es similar a la solución de macvlans .
Puenteando con ipvlan
IP Vlan no tiene la limitación de un puente, podría usarse para tender un puente sobre los detalles de la red aquí.
Alternativa de disfraces
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 presentar algunos problemas de seguridad.
Además, y muy importante, no debe usar comandos obsoletos y obsoletos como ifconfig, brctl , etc. El paquete 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 sabe 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 le asignamos una dirección IP de 10.173.10.1, y luego lo ponemos en marcha. 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 nombre de red) responda a las consultas ARP en su lugar.
En otras palabras, al utilizar 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 cierto: se está olvidando absolutamente tráfico ARP 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 es usar proxy-arp.
La respuesta completa a eso está en el Blog de Bohdi Zazen , con el título revelador: tarjetas inalámbricas Bridge. Él usa 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, de modo que puede descuidar la descarga del paquete y usar el comando I escribió anteriormente para crear una interfaz de toque o tun, 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 proxy-arp, en lugar de la simple interfaz tap0 descrita por Bohdi Zazen.
Implemente redes inalámbricas con systemd-networkd . Dentro del archivo .network, establezca IPForward=yes. Utilicé WPA Supplicant para administrar la interfaz de red inalámbrica.
Habilite la retransmisión de mDNS configurando enable-reflector=yesen /etc/avahi/avahi-daemon.conf; iniciar y activar avahi-daemon.servicesi no lo es ya.
Instale parprouted desde el AUR y cree un archivo de servicio para él adaptando el de la respuesta Raspbian . No encontré que fuera necesario configurar la interfaz para que sea promiscua. Naturalmente, este servicio deberá iniciarse y habilitarse.
[Unit]
Description=proxy arp routing service
Documentation=/raspberrypi//q/88954/79866
[Service]
Type=forking
# Restart until wlan0 gained carrier
Restart=on-failure
RestartSec=5
TimeoutStartSec=30
ExecStartPre=/lib/systemd/systemd-networkd-wait-online --interface=wlan0 --timeout=6 --quiet
ExecStartPre=/usr/bin/echo 'systemd-networkd-wait-online: wlan0 is online'
# clone the dhcp-allocated IP to eth0 so dhcrelay will relay for the correct subnet
ExecStartPre=/usr/bin/bash -c '/usr/bin/ip addr add $(/usr/bin/ip -4 -br addr show wlan0 | /usr/bin/grep -Po "\\d+\\.\\d+\\.\\d+\\.\\d+")/32 dev eth0'
ExecStartPre=/usr/bin/ip link set dev eth0 up
# v minus sign
ExecStart=-/usr/bin/parprouted eth0 wlan0
ExecStopPost=/usr/bin/ip link set dev eth0 down
ExecStopPost=/usr/bin/bash -c '/usr/bin/ip addr del $(/usr/bin/ip -4 -br addr show eth0 | /usr/bin/grep -Po "\\d+\\.\\d+\\.\\d+\\.\\d+")/32 dev eth0'
[Install]
[email protected]
Para admitir DHCP para el dispositivo conectado al puerto ethernet, cree un servicio dhcrelay (desde el paquete DHCP). Encontrar la dirección del servidor DHCP haciendo grep'the a través de los registros parece poco elegante, pero funciona. Iniciar y habilitar.
Este enfoque funcionó para mí en un Raspberry Pi Modelo B + con ArchLinuxArm con un adaptador USB WiFi con el chipset RT5370. Como el Pi proporcionará WiFi a una impresora con solo Ethernet, me gustaría que sea robusto para un manejo brusco, por lo que mi próximo paso será configurar la tarjeta SD como solo lectura .
Respuestas:
ACTUALIZAR
No es posible establecer un puente entre las interfaces inalámbricas (modo estación de cliente) y las cableadas de acuerdo con este hilo en linux-ath5k-devel .
Configurar NAT
Uno debería configurar NAT en su lugar:
Asignando una IP
Luego debe asignarse direcciones IP a usted mismo:
Instalar dhcp daemon
Instale un servidor dhcp y agregue el siguiente texto a su archivo de configuración (en /etc/dhcpd.conf o algo similar)
Inicie 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
Primero crea una interfaz de puente. Elijo un nombre arbitrario mybridge y luego le agrego intefaces.
Debe solicitar una nueva dirección IP (esto es necesario solo si desea obtener una IP válida para el dispositivo de enlace en sí):
fuente
Para conectar la interfaz wifi , puede usar la
iwherramienta para habilitar 4addr de la misma manera:es decir:
Ahora debería funcionar. Puede mostrar puentes usando:
fuente
4addrmodo hace que WiFi se comporte lo suficiente como Ethernet por cable para que el puente funcione. Sin él, el puente no funcionará sin NAT.4addrrequiere que ambos lados de un enlace inalámbrico lo admitan (suponiendo que intente implementar un extensor wifi)Depende de lo malo que sea el AP para usted:
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 los paquetes en puente) 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 (causa 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 la dirección correcta en la otra dirección como se describe aquí:
https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC
fuente
4addr como se describe en otras respuestas es ciertamente la mejor manera cuando es compatible con el adaptador / controlador, pero no todos lo hacen. NAT podría funcionar para algunas cosas, pero obtener una comunicación adecuada en ambos sentidos en la LAN será 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 (por ejemplo, autodescubrimiento, bonjour) fallará a través del NAT.
La alternativa es utilizar un Proxy ARP (parprouted) como se describe en https://wiki.debian.org/BridgeNetworkConnectionsProxyArp . Lo configuré en una Raspberry Pi para una impresora y funciona de maravilla (he agregado una suspensión de 10 segundos en los
post-upcomandos para que primero obtenga una dirección IP, podría tener que ver con la lentitud de mi antiguo RPi ...)fuente
Puente wlan y 4addr:
Unir wlan0 es un dolor. Por lo general, no puede agregarlo a una interfaz de puente (brctl devuelve "Operación no permitida"), y el uso del filtro "puenteado" de VirtualBox genera una gran confusión 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 supone que solo hay un posible originador.
802.11 puede transportar la cuarta dirección MAC del originador, y esto es utilizado en modo WDS por los repetidores. Esta característica 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 la red puenteada de VirtualBox:
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 ser por 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 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 consiste en 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:
Luego, agregue una segunda interfaz, el nombre fue elegido arbitrariamente, con una dirección MAC diferente:
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. El MAC original de wlan0 permanece para uso "normal".
Es posible usar tanto wlan0 como wds.wlan0 al mismo tiempo, aunque solo he probado asociarme 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 conectar WiFi "bien". La respuesta es que VirtualBox no envía las direcciones MAC de las máquinas virtuales; más bien, realiza NAT en la capa MAC también. - 2014-08-22
Puente wlan directo
Bajo ciertas circunstancias, también podría usar wlan_kabel. Utiliza sockets de paquetes para conectar 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, porque solo se usa el MAC original del dispositivo wlan. En su caso, esto significaría que wlan0 solo puede ser utilizado por una VM y ni siquiera por el host. Puedes obtener wlan_kabel aquí . Esto es similar a la solución de macvlans .
Puenteando con ipvlan
IP Vlan no tiene la limitación de un puente, podría usarse para tender un puente sobre los detalles de la red aquí.
Alternativa de disfraces
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 presentar algunos problemas de seguridad.
La interfaz br0 tendrá acceso a la red wlan0
Importante y relacionado
Además, y muy importante, no debe usar comandos obsoletos y obsoletos como ifconfig, brctl , etc. El paquete 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 sabe cómo configurar un puente con ip, aquí vamos
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 le asignamos una dirección IP de 10.173.10.1, y luego lo ponemos en marcha. 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 nombre de red) responda a las consultas ARP en su lugar.
En otras palabras, al utilizar 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 cierto: se está olvidando absolutamente tráfico ARP 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 es usar proxy-arp.
La respuesta completa a eso está en el Blog de Bohdi Zazen , con el título revelador: tarjetas inalámbricas Bridge. Él usa 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, de modo que puede descuidar la descarga del paquete y usar el comando I escribió anteriormente para crear una interfaz de toque o tun, 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 proxy-arp, en lugar de la simple interfaz tap0 descrita por Bohdi Zazen.
Fuentes: askubuntu.com , nullroute.eu.org , firejail.wordpress.com , superuser.com
fuente
Me gustó el enfoque Proxy Arp , pero la pregunta original especificaba Arch Linux. Aquí hay una versión de Arch Linux de una implementación de Raspbian . Intenté adaptar el enfoque original de Debian Wiki mencionado aquí para usar netctl
ExecUpPostyExecDownPresin éxito. Todo funcionó en la línea de comando, pero no dentro del perfil.Los pasos:
IPForward=yes. Utilicé WPA Supplicant para administrar la interfaz de red inalámbrica.enable-reflector=yesen/etc/avahi/avahi-daemon.conf; iniciar y activaravahi-daemon.servicesi no lo es ya.Este enfoque funcionó para mí en un Raspberry Pi Modelo B + con ArchLinuxArm con un adaptador USB WiFi con el chipset RT5370. Como el Pi proporcionará WiFi a una impresora con solo Ethernet, me gustaría que sea robusto para un manejo brusco, por lo que mi próximo paso será configurar la tarjeta SD como solo lectura .
fuente