Solution 1 :
Pour établir un pont Wi-Fi interface que vous pouvez utiliser iw outil pour activer 4addr de même :
# iw dev <wifiInterface> set 4addr on
c'est-à-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>
Maintenant, cela devrait fonctionner. Vous pouvez afficher les ponts en utilisant :
# brctl show
Solution 2 :
MISE À JOUR
Il n'est pas possible d'établir un pont entre les interfaces sans fil (client alias mode station) et câblées selon ce fil sur linux-ath5k-devel.
Configurer NAT
Il faut plutôt configurer NAT :
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
Attribuer une adresse IP
Ensuite, vous devez vous attribuer des adresses IP :
ifconfig eth0 10.0.0.1 netmask 255.255.255.0 up
Installer le démon DHCP
Installez un serveur DHCP et ajoutez le texte suivant à son fichier de configuration (dans /etc/dhcpd.conf ou quelque chose de similaire)
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;
}
Démarrer dhcpd
Puis démarrez-le /etc/init.d/dhcpd start
Et c'est tout !
Lisez ci-dessous uniquement si vous êtes intéressé par la configuration de pontage non fonctionnel
brctl addbr mybridge
brctl addif mybridge eth0
brctl addif mybridge wlan0
Vous créez d'abord une interface de pont Je choisis un nom arbitraire mybridge puis ajoutez-y des interfaces.
Vous devez demander une nouvelle adresse IP (cela n'est nécessaire que si vous souhaitez obtenir une adresse IP valide pour le périphérique de pontage lui-même) :
dhclient -d mybridge
Solution 3 :
Pont wlan et 4addr :
Le pontage wlan0 est une douleur. Vous ne pouvez normalement pas l'ajouter à une interface de pont (brctl renvoie "Opération non autorisée"), et l'utilisation du filtre "ponté" de VirtualBox entraîne un grand désordre de conflits ARP et DHCP. La cause en est que les trames 802.11 ne contiennent que trois adresses par défaut :les adresses MAC des deux appareils sans fil (ordinateur portable et point d'accès) et du destinataire final (comme dans Ethernet). On suppose toujours qu'il n'y a qu'un seul expéditeur possible.
802.11 peut transporter la quatrième adresse MAC de l'expéditeur, et celle-ci est utilisée en mode WDS par les répéteurs. Cette fonctionnalité peut également être activée sur Linux, en utilisant iw, et l'activation de ce mode permettra à wlan0 d'être utilisé dans les interfaces de pont, ainsi qu'avec le réseau ponté VirtualBox :
iw dev wlan0 set 4addr on
Cependant, avec 4addr activé, vous risquez d'être complètement ignoré par l'AP :l'association réussit mais toutes les trames de données disparaissent dans l'éther. Cela pourrait être pour des raisons de sécurité (car il est sacrément difficile d'usurper l'adresse MAC source. Ouais.) Dans mon routeur (exécutant OpenRG), il est nécessaire d'activer le mode "WDS" pour l'interface AP sans fil, ajouter un périphérique WDS limité à mon l'adresse MAC de l'ordinateur portable et ajoutez-la au pont LAN. Les paquets 4addr fonctionnent maintenant.
Il y a un autre problème avec cela, cependant - le routeur rejette maintenant les paquets à trois adresses de l'ordinateur portable, ce qui peut être plutôt gênant (avoir à basculer 4addr chaque fois que le réseau WLAN est changé). La solution consiste à ajouter, sur l'ordinateur portable, une deuxième interface sans fil liée au même appareil, mais avec une adresse MAC différente. Annulez d'abord la configuration précédente :
iw dev wlan0 set 4addr off
Ensuite, ajoutez une deuxième interface – le nom a été choisi arbitrairement – avec une adresse MAC différente :
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
Ici doit correspondre l'adresse du périphérique WDS configurée dans le routeur ; à part cela, il peut s'agir de n'importe quelle adresse MAC valide. Le MAC d'origine de wlan0 reste alors pour une utilisation "normale".
Il est possible d'utiliser à la fois wlan0 et wds.wlan0 - bien que je n'aie testé l'association au même point d'accès que deux fois, pas à des points d'accès différents. Je suppose qu'ils devraient au moins être sur le même canal.
Certaines personnes ont demandé pourquoi l'utiliser alors que VirtualBox peut relier le WiFi "très bien". La réponse est que VirtualBox n'envoie pas les adresses MAC des machines virtuelles; au lieu de cela, il exécute également le NAT au niveau de la couche MAC. – 2014-08-22
Pont Wi-Fi direct
Dans certaines circonstances, vous pouvez également utiliser wlan_kabel. Il utilise des sockets de paquets pour relier directement les appareils wlan* aux appareils ethernet. Cependant, vous ne pouvez ponter qu'un seul MAC à la fois avec wlan_kabel. Il n'a pas l'inconvénient d'être barré par les points d'accès, car seul le MAC d'origine de l'appareil wlan est utilisé. Dans votre cas, cela signifierait que wlan0 ne pourrait être utilisé que par une seule machine virtuelle et même pas par l'hôte. Vous pouvez obtenir wlan_kabel ici. Ceci est similaire à la solution macvlans.
Pont avec ipvlan
IP Vlan n'a pas la limitation d'un pont, il pourrait être utilisé pour relier un réseau. Des détails sur la façon de l'utiliser peuvent être trouvés ici
Alternative à la mascarade
Le routage Linux peut être utilisé à la place avec iptables-masquerade et ip_forward pour réaliser un pont, mais comme mentionné, cela nécessite d'activer ip_forward et fera agir Linux comme un routeur, ce qui doit être configuré avec soin car cela pourrait introduire des problèmes de sécurité.
# 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'interface br0 aura alors accès au réseau wlan0
Important et connexe
De plus, et très important, vous ne devez pas utiliser de commandes obsolètes et obsolètes telles que ifconfig, brctl , etc. La suite iproute2 contient des commandes pour tout cela, y compris la configuration d'interfaces virtuelles (quelque chose pour lequel nous devions autrefois utiliser openvpn) et la création de ponts. Si vous ne savez pas comment configurer un pont avec ip, c'est parti
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
Avec cet ensemble de commandes, nous créons une interface virtuelle appelée tap0, puis un pont appelé br0, puis asservissons eth0 et tap0 au pont, auquel nous attribuons une adresse IP de 10.173.10.1, puis ramenons le tout. Les trois instances distinctes d'activation des interfaces (pour tap0, eth0 et br0) sont requises.
L'astuce pour que cela fonctionne est d'utiliser proxy.arp, qui permet à votre ordinateur (et non à votre conteneur VM/Linux/espace de noms réseau) de répondre aux requêtes ARP à leur place.
En d'autres termes, en utilisant le transfert IPv4 entre votre interface matérielle et votre interface virtuelle, vous pensez pouvoir connecter votre VM/LXC/NNS à votre LAN comme s'il s'agissait d'une interface physique, mais ce n'est pas vrai :vous oubliez absolument le trafic ARP fondamental, qui est ce qui permet vraiment au LAN de fonctionner. Donc, le problème est le suivant :si je transfère correctement le trafic IPv4, comment puis-je également transférer le trafic ARP, afin que ma VM/LXC/NNS fonctionne ? L'astuce consiste à utiliser proxy-arp.
La réponse complète à cette question se trouve dans le blog de Bohdi Zazen, avec le titre révélateur :Cartes sans fil Bridge. Il utilise un package obsolète, uml-utilities, pour créer une interface virtuelle au moyen de la commande tunctl :c'est la seule commande pour laquelle il utilise uml-utilities, de sorte que vous pouvez en toute sécurité négliger de télécharger le package, et utilisez la commande I écrit ci-dessus pour créer une interface tap ou tun, selon votre choix, modifiez simplement la commande en conséquence. puis créez une paire veth pour votre LXC, et créez maintenant un pont entre tap0 et veth0. Ce pont, appelé br0, est ce pour quoi vous devez proxy-arp, au lieu de la simple interface tap0 décrite par Bohdi Zazen.
Sources :askubuntu.com, nullroute.eu.org, firejail.wordpress.com, superuser.com
Solution 4 :
Cela dépend de la façon dont l'AP est méchant avec vous :
1) Il pourrait ne vouloir voir que les paquets provenant de vous, avec votre adresse de couche liaison connue (et donc pas de paquets pontés) 2) Il pourrait en fait être encore plus intelligent et savoir quelle adresse IP doit appartenir à quelle adresse de couche liaison (cause il connaît le DHCP et l'inspecte)
Si 1+2 sont tous les deux vrais, vous avez en effet besoin de quelque chose comme IP NAT, DHCP, ..
Mais si seulement 1) est le cas, vous pouvez simuler l'adresse de la couche liaison et l'inverser sur la bonne dans l'autre sens comme décrit ici :
https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC
Solution 5 :
4addr comme décrit dans d'autres réponses est certainement le meilleur moyen lorsqu'il est pris en charge par l'adaptateur/pilote, mais pas tous. Le NAT peut fonctionner pour certaines choses, mais obtenir une bonne communication dans les deux sens sur le réseau local deviendra problématique (par exemple, connecter une imprimante ou accéder à d'autres appareils IoT de l'autre côté du NAT). Tout ce qui repose sur la diffusion/multidiffusion (par exemple, la découverte automatique, bonjour) échouera via le NAT.
L'alternative consiste à utiliser un proxy ARP (parprouted) comme décrit dans https://wiki.debian.org/BridgeNetworkConnectionsProxyArp. J'ai configuré cela sur un Raspberry Pi pour une imprimante et cela fonctionne comme un charme (j'ai ajouté un sommeil de 10 secondes dans le post-up commandes pour lui permettre d'obtenir une adresse IP en premier, cela pourrait avoir à voir avec la lenteur de mon ancien RPi...)