É possível usar proxy-arp de volta para a mesma interface?

Question

Eu tenho um ponto de acesso WiFi conectado a um roteador Linux. O roteador está conectado à Internet. Por várias razões (principalmente para controlar a segurança e a qualidade do serviço), eu quero forçar o tráfego de todos os usuários a passar pelo roteador Linux, até mesmo o tráfego entre os usuários.

Para fazer isso, desativei as comunicações estação a estação no AP (eu uso um AP D-Link DWL-7200). Aqui está como eu configurei o AP:

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

Isso funciona bem: usuários sem fio não podem se comunicar mais uns com os outros. Pelo menos não diretamente. Meu objetivo é forçar o tráfego até o roteador e voltar.

Para fazer isso , eu habilitei o proxy-arp no Linux Router:

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

Aqui está o quadro geral.

                  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

Veja o que esperava que ocorresse se UserA pingasse UserB:

1. UserA tenta fazer ping 10.0.0.66
2. então o UserA envia uma transmissão ARP dizendo "Quem tem 10.0.0.66?"
3. O ponto de acesso permite que a solicitação chegue ao roteador (mas não ao UserB, porque o sta2sta está desativado)
4. o roteador recebe a solicitação e, como o proxy-arp está ativado na eth1, ele deve responder "Enviar pacotes para 10.0.0.66 para mim (endereço MAC do roteador)".
5. o ponto de acesso deve receber a resposta e retransmiti-la para o UserA.
6. então o UsuárioA deve enviar o pacote de ping real para o endereço MAC do roteador
7. o pacote deve passar pelo AP para o roteador
8. O roteador deve encaminhá-lo de volta para eth1, alterando o endereço MAC de destino para o de UserB (fazendo uma solicitação ARP, se necessário) e alterando o endereço MAC de origem para o seu próprio.
9. O pacote deve chegar ao AP e ser retransmitido para o UserB.
10. O UserB deve responder à solicitação de ping.
11. a resposta deve passar pelo ponto de acesso ao roteador.
12. a resposta deve ser encaminhada para o UserA.
13. e deve passar pelo AP e alcançar o UserA.

Infelizmente, todo esse sonho falha na etapa 4, porque o roteador Linux recebe a solicitação ARP, mas não consegue respondê-la. Pelo que li na Internet, parece que isso é normal: o proxy-ARP não é realmente projetado para ser usado nesse tipo de configuração. Para ser mais preciso: o roteador não responde às solicitações ARP para hosts que estão na mesma interface da qual a solicitação ARP veio. Nesse caso, a solicitação ARP vem da eth1, mas diz "Quem tem o IP 10.0.0.66?" E o host 10.0.0.66 está na interface eth1.

Eu entendo porque este é um bom comportamento padrão, porque se o sta2sta não estivesse desabilitado no AP, o UserA receberia uma resposta ARP do roteador e outra resposta ARP do UserB. Mas no meu caso, acredito que faria todo o sentido responder a cada solicitação ARP, mesmo para hosts na mesma interface.

Existe alguma maneira de contornar esse comportamento padrão do proxy-arp?

    

Answer 1

O que você quer é realmente possível, mas requer um kernel Linux bem recente (> = 2.6.34, ou um backport).

A opção que você precisa é /proc/sys/net/ipv4/conf/*/proxy_arp_pvlan :

proxy_arp_pvlan - BOOLEAN
    Private VLAN proxy arp.
    Basically allow proxy arp replies back to the same interface
    (from which the ARP request/solicitation was received).

    This is done to support (ethernet) switch features, like RFC
    3069, where the individual ports are NOT allowed to
    communicate with each other, but they are allowed to talk to
    the upstream router.  As described in RFC 3069, it is possible
    to allow these hosts to communicate through the upstream
    router by proxy_arp'ing. Don't need to be used together with
    proxy_arp.

    This technology is known by different names:
      In RFC 3069 it is called VLAN Aggregation.
      Cisco and Allied Telesyn call it Private VLAN.
      Hewlett-Packard call it Source-Port filtering or port-isolation.
      Ericsson call it MAC-Forced Forwarding (RFC Draft).

O commit do upstream adicionando este suporte é 65324144b50bc7022cc9b6ca8f4a536a957019e3 .

    

Answer 2

Não tenho certeza se a implementação do proxyarp do Linux pode ser facilmente ajustada para atingir sua meta. Você já pensou em usar uma abordagem de sub-rede / roteamento?

Eis a ideia: alocar, digamos, um espaço de endereçamento /24 para sua rede sem fio. Para corresponder ao exemplo da sua pergunta, usarei 10.0.0.0/24 . Agora divida esse /24 em 62 /30 sub-redes: 10.0.0.4/30 , 10.0.0.8/30 , 10.0.0.12/30 , ... 10.0.0.248/30 .

Cada /30 tem 2 endereços IP utilizáveis, um dos quais é atribuído a um cliente sem fio, e o outro é atribuído (aliado) à interface eth1 do seu roteador Linux. Para ser concreto, digamos que atribuímos endereços de clientes sem fio desta série: 10.0.0.6 , 10.0.0.10 , 10.0.0.14 , ..., 10.0.0.250 . E alias a seguinte série de IPs a eth1 no roteador: 10.0.0.5 , 10.0.0.9 , 10.0.0.13 , ..., 10.0.0.249 .

Para concluir a configuração, cada cliente sem fio obtém uma máscara de rede de 255.255.255.252 e um gateway padrão de 10.0.0.X-1 (onde X é o último octeto do endereço IP do cliente). No roteador, o comando ip pode ser usado para adicionar os endereços IP à eth1, da seguinte maneira:

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

Prós:

• Realiza o objetivo desejado: todo o tráfego do cliente sem fio é encaminhado pelo roteador e os clientes podem entrar em contato entre si.
• As transmissões ARP acontecem raramente, pois o primeiro salto de cada cliente é sempre o roteador.

Contras:

• A configuração não é convencional. Uma configuração estática (clientes e roteador) pode ser feita com bastante facilidade, mas é difícil estabelecer uma configuração dinâmica (DHCP).