Est-il possible d'utiliser proxy-arp dans la même interface?

J'ai un point d'access WiFi connecté à un routeur Linux. Le routeur est lui-même connecté à Internet. Pour plusieurs raisons (principalement pour contrôler la security et la qualité du service), je veux forcer tout le trafic des users à passer par le routeur Linux, même le trafic entre les users.

Pour ce faire, j'ai désactivé les communications station-station dans l'AP (j'utilise un D-Link DWL-7200 AP). Voici comment j'ai configuré l'AP:

ssh admin@accesspoint1 D-Link Access Point wlan1 -> set sta2sta disable D-Link Access Point wlan1 -> reboot 

Cela fonctionne bien: les users sans fil ne peuvent plus communiquer les uns avec les autres. Au less pas directement. Mon objective est de forcer le trafic vers le routeur et le return.

Pour ce faire, j'ai activé proxyarp dans le routeur Linux:

 echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp 

Voici la grande image.

  10.0.0.0/8 subnet ____________________|______________________ / \ | | (sta2sta disabled) UserA----------------AP---------------------Router-------------------Internet 10.0.0.55 / eth1 eth0 / 10.0.0.1 203.0.113.15 / proxy-arp enabled UserB____________/ 10.0.0.66 

Voici ce que j'espérais arriver si UserA pinged UserB:

  1. UserA essaie de faire un ping 10.0.0.66
  2. donc UserA envoie la diffusion ARP en disant "Qui a 10.0.0.66?"
  3. Le point d'access permet à la requête de passer au routeur (mais pas à UserB, car sta2sta est désactivé)
  4. le routeur reçoit la requête, et parce que proxy-arp est activé sur eth1, il devrait répondre "Envoyer des packages pour 10.0.0.66 (l'adresse MAC du routeur)".
  5. le point d'access devrait recevoir la réponse et le relayer à UserA.
  6. alors l'user doit envoyer le package ping réel à l'adresse MAC du routeur
  7. le package devrait passer par l'AP au routeur
  8. Le routeur doit l'apather vers eth1, en changeant l'adresse MAC de destination par celle de UserB (en faisant une request ARP si nécessaire) et en modifiant l'adresse MAC source.
  9. Le package doit atteindre l'AP et être transmis à UserB.
  10. UserB devrait répondre à la requête ping.
  11. la réponse devrait passer par l'AP au routeur.
  12. la réponse doit être apathée vers UserA.
  13. et il devrait passer par l'AP et atteindre UserA.

Malheureusement, tout ce rêve échoue à l'étape 4, car le routeur Linux reçoit la requête ARP mais ne parvient pas à le répondre. D'après ce que j'ai lu sur Internet, il semble que ce soit normal: proxy-ARP n'est pas vraiment conçu pour être utilisé dans ce type d'installation. Pour être plus précis: le routeur ne répond pas aux requests ARP pour les hôtes qui se trouvent sur la même interface que celle fournie par ARP. Dans ce cas, la request ARP vient de eth1, mais elle dit "Qui a la propriété IP 10.0.0.66?", Et l'hôte 10.0.0.66 est sur l'interface eth1.

Je comprends pourquoi il s'agit d'un bon comportement par défaut, car si sta2sta n'était pas désactivé dans l'AP, UserA recevrait une réponse ARP du routeur et une autre réponse ARP de UserB. Mais dans mon cas, je crois qu'il serait logique de répondre à toutes les requests ARP, même pour les hôtes sur la même interface.

Est-ce que je peux contourner ce comportement proxy-arp par défaut?

Ce que vous voulez est réellement possible, mais nécessite un kernel Linux assez récent (> = 2.6.34 ou un backport).

L'option dont vous avez besoin est /proc/sys/net/ipv4/conf/*/proxy_arp_pvlan :

 proxy_arp_pvlan - BOOLEAN
     Proxy privé VLAN arp.
     Autoriser basiquement les réponses proxy proxy à la même interface
     (dont la request / sollicitation ARP a été reçue).

     Ceci est fait pour prendre en charge les fonctionnalités de commutateur (ethernet), comme la RFC
     3069, où les ports individuels ne sont PAS autorisés à
     communiquer entre eux, mais ils peuvent parler avec
     le routeur en amont.  Comme décrit dans RFC 3069, c'est possible
     pour permettre à ces hôtes de communiquer via l'amont
     routeur par proxy_arp'ing.  Ne pas utiliser avec
     proxy_arp.

     Cette technologie est connue sous différents noms:
       Dans RFC 3069, il s'appelle VLAN Aggregation.
       Cisco et Allied Telesyn l'appellent VLAN privé.
       Hewlett-Packard l'appelle Source-Port de filtrage ou d'isolement du port.
       Ericsson appelle MAC-Forced Forwarding (RFC Draft).

Le commit en amont ajoutant ce support est 65324144b50bc7022cc9b6ca8f4a536a957019e3 .

Je ne suis pas sûr que l'implémentation proxy proxy Linux puisse être facilement modifiée pour atteindre votre objective. Avez-vous envisagé d'utiliser une approche de sous-réseau / routing?

Voici l'idée: Allouez, par exemple, un espace d'adresse de /24 pour votre réseau sans fil. Pour correspondre à l'exemple de votre question, je vais utiliser 10.0.0.0/24 . Créez maintenant ce /24 sous 10.0.0.4/30 sous-réseaux: 10.0.0.4/30 , 10.0.0.8/30 , 10.0.0.12/30 , … 10.0.0.248/30 .

Chaque /30 dispose de 2 adresses IP utilisables, dont l'une est affectée à un client sans fil, et l'autre est affecté (alias) à l'interface eth1 de votre routeur Linux. Pour être concret, disons que nous 10.0.0.6 adresses de clients sans fil de cette série: 10.0.0.6 , 10.0.0.10 , 10.0.0.14 , …, 10.0.0.250 . Et nous allons être la série d'IP suivantes à eth1 sur le routeur: 10.0.0.5 , 10.0.0.9 , 10.0.0.13 , …, 10.0.0.249 .

Pour compléter la configuration, chaque client sans fil obtient un masque de réseau de 255.255.255.252 et une passerelle par défaut de 10.0.0.X-1 (où X est le dernier octet de l'adresse IP du client). Sur le routeur, la command ip peut être utilisée pour append les adresses IP à eth1, comme suit:

 ip addr add 10.0.0.5/30 broadcast 10.0.0.7 dev eth1 ip addr add 10.0.0.9/30 broadcast 10.0.0.11 dev eth1 ip addr add 10.0.0.13/30 broadcast 10.0.0.15 dev eth1 ... ... ip addr add 10.0.0.249/30 broadcast 10.0.0.251 dev eth1 

Avantages:

  • Réalise l'objective souhaité: tout le trafic de client sans fil est transmis via le routeur et les clients peuvent se contacter.
  • Les émissions ARP se produisent rarement, puisque le premier saut de chaque client est toujours le routeur.

Les inconvénients:

  • La configuration n'est pas conventionnelle. Une configuration statique (clients et routeur) peut être effectuée assez facilement, mais une configuration dynamic (DHCP) sera très difficile à établir.