Faire le pont entre wlan0 et eth0

Sur Arch Linux, je voudrais que eth0 (connecté à un routeur ponté) partage la connexion reçue de wlan0, j'ai lu des tutoriels mais je ne suis pas très averti comme les autres utilisateurs et ne comprends pas complètement.

MISE À JOUR

Il n'est pas possible de faire le pont entre le sans fil (client aka mode station) et les interfaces 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

Attribution d'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

Ensuite, démarrez-le /etc/init.d/dhcpd start

Et c'est tout!

Lisez uniquement ci-dessous si vous êtes intéressé par la configuration de pontage qui ne fonctionne pas

brctl addbr mybridge
brctl addif mybridge eth0
brctl addif mybridge wlan0

D'abord, vous créez une interface de pont, je choisis un nom arbitraire mybridge, puis j'y ajoute 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

Pour relier l' interface wifi , vous pouvez également utiliser l' iwoutil pour activer 4addr :

# 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 ça devrait marcher. Vous pouvez montrer des ponts en utilisant:

# brctl show

Cela dépend de la façon dont l'AP est méchant pour vous:

1) Il peut 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 devrait appartenir à quelle adresse de couche liaison (cause il connaît 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

4addr tel que 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 communication appropriée dans les deux sens sur le réseau local deviendra problématique (par exemple, la connexion d'une imprimante ou l'accès à d'autres appareils IoT de l'autre côté du NAT). Tout ce qui s'appuie sur la diffusion / multidiffusion (par exemple, découverte automatique, bonjour) échouera via le NAT.

L'alternative utilise 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 les post-upcommandes pour lui permettre d'obtenir d'abord une adresse IP, cela pourrait avoir à voir avec la lenteur de mon ancien RPi ...)

Pont wlan et 4addr:

Le pontage de wlan0 est une douleur. Normalement, vous ne pouvez 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 gros désordre de conflits ARP et DHCP. La raison 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 AP) et du destinataire final (comme dans Ethernet). On suppose toujours qu'il n'y a qu'un seul donneur d'ordre possible.

Le 802.11 peut porter la quatrième, l'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 la mise en réseau pontée 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, ajoutez 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 - le routeur rejette maintenant les paquets de trois adresses de l'ordinateur portable, ce qui peut être assez gênant (devoir basculer 4addr à chaque fois que le réseau WLAN est changé). La solution de contournement 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 - même si je n'ai testé que deux fois l'association au même AP, pas à des AP différents. Je suppose qu'ils devraient au moins être sur le même canal.

Certaines personnes ont demandé pourquoi utiliser cela lorsque VirtualBox peut relier le WiFi "très bien". La réponse est que VirtualBox n'envoie pas les adresses MAC des machines virtuelles; il exécute plutôt le NAT au niveau de la couche MAC également. - 2014-08-22

Pont WLAN direct

Dans certaines circonstances, vous pouvez également utiliser wlan_kabel. Il utilise des sockets paquets pour relier directement les périphériques wlan * aux périphériques Ethernet. Cependant, vous ne pouvez relier qu'un seul MAC à la fois avec wlan_kabel. Il n'a pas l'inconvénient d'être interdit par les points d'accès, car seul le MAC d'origine du périphérique WLAN est utilisé. Dans votre cas, cela signifierait que wlan0 ne pourrait être utilisé que par une machine virtuelle et pas même par l'hôte. Vous pouvez obtenir wlan_kabel ici . Ceci est similaire à la solution macvlans .

Passerelle avec ipvlan

IP Vlan n'a pas la limitation d'un pont, il pourrait être utilisé pour combler un réseau. Les 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 obtenir un pont, mais comme mentionné, cela nécessite d'activer ip_forward et fera en sorte que Linux agisse comme un routeur, cela 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 c'est très important, vous ne devez pas utiliser de commandes obsolètes et obsolètes comme ifconfig, brctl , etc. La suite iproute2 contient des commandes pour tout cela, y compris la configuration d'interfaces virtuelles (quelque chose pour laquelle nous avons dû 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 nous montons 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 PC (et non à votre espace de noms VM / Linux conteneur / 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 que vous pouvez 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 permet vraiment au LAN de fonctionner. Donc, le problème est: 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 est dans le blog de Bohdi Zazen , avec le titre révélateur: Bridge wireless cards. 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 négliger en toute sécurité le téléchargement du package, et utiliser la commande I écrit ci-dessus pour créer une interface tap ou tun, comme vous le souhaitez, modifiez simplement la commande en conséquence. puis créez une paire de veth pour votre LXC, et créez maintenant un pont entre tap0 et veth0. Ce pont, appelé br0, est ce pour quoi vous devez utiliser 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

J'ai aimé l' approche Proxy Arp , mais la question d'origine spécifiait Arch Linux. Voici une version Arch Linux d' une implémentation Raspbian . J'ai essayé très fort d'adapter l'approche originale du Debian Wiki mentionné ici à netctl en utilisant ExecUpPostet ExecDownPresans succès. Tout fonctionnait sur la ligne de commande, mais pas dans le profil.

Les marches:

1. Implémentez la mise en réseau sans fil avec systemd-networkd . Dans le fichier .network, définissez IPForward=yes. J'ai utilisé WPA Supplicant pour gérer l'interface réseau sans fil.
2. Activez le relais mDNS en définissant à l' enable-reflector=yesintérieur /etc/avahi/avahi-daemon.conf; démarrer et activer avahi-daemon.servicesi ce n'est pas déjà fait.
3. Installez parprouted à partir de l'AUR et créez un fichier de service pour celui-ci en adaptant celui de la réponse Raspbian . Je n'ai pas trouvé qu'il était nécessaire de définir l'interface pour qu'elle soit proche. Naturellement, ce service devra être démarré et activé.

[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]

4. Pour prendre en charge DHCP pour le périphérique connecté au port Ethernet, créez un service dhcrelay (à partir du package DHCP). Trouver l'adresse du serveur DHCP en effectuant une recherche dans les journaux semble inélégant, mais cela fonctionne. Démarrez et activez.

[Unit]
Description=DHCRelay Service
After=network-online.target parprouted_bridge.service
Type=simple

[Service]
ExecStart=/usr/bin/bash -c '/usr/bin/dhcrelay -d -4 -iu wlan0 -id eth0 $(/usr/bin/journalctl -b -u systemd-networkd.service | /usr/bin/grep -Po "via\s+\K\\d+\\.\\d+\\.\\d+\\.\\d+")'

[Install]
WantedBy=multi-user.target

Cette approche a fonctionné pour moi sur un Raspberry Pi modèle B + avec ArchLinuxArm arborant un adaptateur WiFi USB avec le chipset RT5370. Comme le Pi fournira le WiFi à une imprimante avec uniquement Ethernet, je voudrais qu'il soit robuste à une manipulation brutale, donc ma prochaine étape sera de configurer la carte SD en lecture seule .