Como forçar o pacote a passar por uma interface física específica conhecendo somente o MAC de destino?

Question

Estou criando um L3-Switch que modifica pacotes, redirecionando alguns deles para o aplicativo local. Meu objetivo é enviá-los para o mesmo MAC de antes.

Curto "por quê": dispositivo zero-conf para conectar-se a qualquer rede ethernet, portátil, faz proxy.

O switch é organizado como ponte ethernet (br-lan) entre eth0 e eth1. Presume-se por padrão que o gateway para clientes br-lan reside na eth0.

Pergunta: Vamos dizer que o pacote vem da eth1 no caminho para a eth0 e é redirecionado para o aplicativo local. Depois que o aplicativo tiver saída e o IP de destino do pacote original tiver sido alterado. O L3 tenta rotear o pacote para um novo destino, mas ele não possui nenhum gateway padrão (e não deveria, porque é o switch!). Supondo que eu conheça o endereço MAC do gateway padrão, como forçar o pacote a sair através da eth0 para um endereço MAC específico?

Tecnicamente não estou tentando fazer nada "ilegal" em termos de rede. Eu quero chutar o pacote de eth0 e tudo o que eu estou "ausente" é o MAC de destino, mas posso recuperá-lo do pacote original. Eu sei com certeza que o IP de destino não é local e, portanto, ele seria enviado para o gateway padrão usando seu endereço MAC. Então, é uma questão de implementação.

Eu estava tentando modificar o MAC de destino na bridge -t NAT OUTPUT fazendo isso:

ebtables -t nat -A OUTPUT -p ipv4 --ip-proto tcp --ip-src 192.168.1.251 -j dnat --to-dst 04:61:e7:d2:e2:09

Mas isso não ajudou. (Assumindo 04: 61: e7: d2: e2: 09 é gateway padrão MAC e 192.168.1.251 é um dos clientes apenas para testar esta teoria)

A implementação real está no OpenWRT, portanto, os pacotes disponíveis podem ser limitados.

Como cheguei a esse problema:

Mais informações sobre o aplicativo local: é o ss-redir daqui, vinculado a 0.0.0.0:port = > link

Adicionados casos de uso ao [Dispositivo]:

Expectativa: Temos 3 clientes de PC conectados a um comutador regular. Depois de trazer o [Dispositivo] e conectá-lo ao comutador regular e reconectar os clientes do PC ao [Dispositivo], os clientes do PC ganham [Resultado] sem configurar o dispositivo.

[Resultado]:

1) Do lado de fora (outros nós de rede, exceto 3 nossos e tudo mais), deve parecer que todo usuário mantém seu par IP / MAC, então admin seria feliz. O DHCP é configurado de forma estática no escritório, portanto, o par IP / MAC provavelmente não será alterado, mas o administrador pode alterar qualquer um deles. E o dispositivo deve manipular quaisquer alterações sem reconfigurar manualmente. Nenhum novo IP / MAC deve aparecer na rede (não sendo registrado pelo administrador).

2) Do lado de fora, todo cliente-PC deve estar acessível para todos os protocolos da rede, quaisquer que sejam (RDP, NetBIOS para resolução de nomes, compartilhamento de arquivos ou qualquer que seja o administrador local que decidir fazer).

3) Eles devem ter acesso à Internet via gateway padrão como sempre, exceto o proxy tcp via SS para um destino particular ipset (que é sempre através do mesmo gateway)

Supondo que esses casos de uso exigem que o dispositivo não tenha nenhum conhecimento IP / MAC da rede existente desde o início (porque os usuários do escritório não configuram nada sozinhos), estou tentando fazer uma "ponte de proxy" que funcione como um switch, interceptando pacotes e os envia para eth0 (WAN) após o redirecionamento local do aplicativo. O problema é que o pacote de redirecionamento posterior precisa ser enviado a caminho. Estou investigando "auto-reconfig on the fly idéia" com um MAC-snat / dnat, mas preso com o problema que o pacote não vai para eth0 depois de ser gerado localmente, mesmo se eu puder especificar Gateway padrão MAC-addr em ebtables como destino.

    

Answer 1

Deixe-me adivinhar alguma "tarefa original X". Eles provavelmente não corresponderão à sua tarefa original X, mas podem dar uma ideia de que tipo de informação é necessária.

1) O dispositivo é um roteador doméstico normal disponível no mercado, com quatro portas LAN atrás de um comutador externo em eth0 e uma única porta WAN em eth1 . A porta WAN está conectada ao seu gateway de redes locais. Todos os hosts que devem usar o proxy transparente estão conectados às portas LAN, possivelmente com switches adicionais. Nenhum outro host ou conectado às portas LAN. O outro ponto final de meias está no lado da WAN.

Nesse caso, esqueça o nível 2, use as regras iptables , conforme descrito em man ss-redir , adaptado apenas para NAT em eth0 . O roteamento enviará a solicitação SOCKS com proxy de eth1 . O NAT cuidará de que quaisquer respostas sejam enviadas de volta no eth0 para o dispositivo com o IP correto. O ARP garantirá que o MAC para este IP seja usado.

2) Variação dos itens acima: Alguns hosts conectados às portas LAN devem usar o proxy, outros não. Nesse caso, olhe mais de perto o hardware, ele provavelmente tem um switch-chip que você pode configurar com sw-conf . Reconfigure-o para que duas portas LAN estejam conectadas a eth0 e as outras duas estejam conectadas a eth2 . Então proceda como acima. Conecte os hosts às portas LAN corretas, conforme apropriado.

3) O dispositivo é usado como uma ponte simples em uma configuração de rede mais complicada, em que o outro ponto final SOCKS está no mesmo segmento da LAN interna que os hosts que devem usar o proxy. Nesse caso, preciso de uma descrição da rede.

Etc., pp.

Editar

Se eu ler seu caso de uso corretamente, seu principal problema é que você deve conectar a porta WAN (eth0) às portas LAN (eth1), porque o servidor DHCP está atrás da porta WAN e deve gerenciar a atribuição estática dos IPs via DHCP corretamente.

Nesse caso, eu configuraria a bridge como um "brouter" : tudo é superado, exceto pacotes que chegam na rede local (eth1) que devem ser intermediados por proxy (TCP e no intervalo de IP de destino desejado). Esses pacotes surgirão da porta interna br-lan da ponte. Lá, o processamento da camada 3 pode manipulá-los conforme descrito acima. Em particular, o rastreador de conexão pode rastreá-los por IP e porta, e pode enviar respostas do proxy de meias de volta para o dispositivo correto.

Não é necessário o MAC NAT, não é necessário rastreamento de conexão baseado em MAC que colabore com o L5, etc.

Eu gostaria de testar isso com alguns namespaces de rede, para que eu pudesse dar a receita inteira, mas infelizmente não vou ter tempo para isso hoje ou nos próximos dias.

    

Answer 2

Encontrei uma solução suja.

Se esquecermos o contexto X e mergulharmos mais fundo no problema Y, descobriremos o seguinte.

A idéia é que, antes de redirecionar o pacote para o aplicativo local, eu possa registrá-lo e, em seguida, analisá-lo. O processo de atravessar o pacote de eth1 para eth0 para o gateway padrão é assim:

(CLIENT1_SRC_IP, CLIENT1_SRC_MAC, DEST_IP_ADDR_TO_PROXY, DF_GW_MAC)

Mas depois de passar o aplicativo local, ele cai nesse estado:

((!) CLIENT1_SRC_IP, (!) CLIENT1_SRC_MAC, SS_SERVER) e DF_GW_MAC está prestes a ser ARPed (e falhar, porque não há vizinho SS_SERVER, assim como o próprio gateway padrão, então o pacote não chega a lugar nenhum).

Então eu decidi aproveitar o fato de que SS_SERVER é um endereço IP const. DF_GW_MAC do log pode ser analisado e usado para adicionar a rota arp estática para o IP do SS_SERVER.

Alguns detalhes para os usuários do OpenWRT:

Para fazer o ip neigh funcionar:

opkg update

opkg install ip-full

E então:

ip neigh add 123.123.123.123 dev eth0 lladdr 11:22:33:44:55:66

ip route add default dev eth0

Então o problema Y está resolvido aqui. X não é resolvido completamente porque acima de onde eu especifiquei (!) Isso não é verdade porque o aplicativo local faz MASQUARADE para você usando o IP da interface, então você tem que SNAT ele de volta ao IP de origem, que também está sujo. Eu não vejo nenhuma outra opção por enquanto.