Por que um IP em uma interface fictícia responde a uma solicitação ARP em eth0

Question

Eu trouxe uma interface fictícia no meu laptop (Ubuntu 15.10) com um endereço IP de 10.0.3.144, máscara de rede 255.255.255.255

Eu tenho um USB - > Adaptador Ethernet. Quando conectado, ele é configurado para fornecer uma interface "eth0", que obtém seu endereço IP via DHCP no intervalo 10.0.3.2 - 10.0.3.10 (máscara de rede 255.255.255.0)

Eu noto que quando eth0 aparece - por exemplo em 10.0.3.2, outras máquinas podem chegar a 10.0.3.144 - este é o comportamento desejado, mas eu não entendo exatamente por que isso está acontecendo. Eu não tenho nenhum tipo de conexão em ponte, então eu teria pensado que a máquina não teria respondido pela interface fictícia.

Eu posso ver solicitações e respostas arp na interface eth de laptops -

tcpdump -n -i eth0 arp tcpdump: saída detalhada suprimida, use -v ou -vv para decodificação completa do protocolo escutando em eth0, link-type EN10MB (Ethernet), tamanho de captura 262144 bytes

tcpdump -n -i eth0 arp
14:01:31.948781 ARP, Request who-has 10.0.3.144 tell 10.0.3.254, length 48
14:01:31.948842 ARP, Reply 10.0.3.144 is-at 00:23:55:9c:52:31, length 28

Esse comportamento é repetitivo se eu remover a entrada ARP em 10.0.3.254 (que é um roteador que também executa Linux)

Alguém pode aconselhar se posso confiar nesse comportamento? (e por que um computador responderia na interface de um endereço IP não vinculado a ele - e relacionado - teria o potencial de, em determinadas circunstâncias, preencher o roteamento em cenários onde havia várias interfaces em sub-redes diferentes e os pacotes deveriam ser forçado a atravessar um firewall?).

    

Answer 1

why a computer would answer on the an interface for an IP address not bound to it

Isso não é necessariamente verdade em um host Linux.
Por padrão, o endereço IP pertence ao host do Linux, não a uma interface.
Consulte O Linux considera um endereço IP como pertencente a um host em vez de uma interface

Este "recurso" do Linux é algumas vezes chamado de "problema de fluxo de ARP", e é descrito na seção 2.1.4 de Protocolo de resolução de endereços (ARP)

Existem vários métodos para alterar esse comportamento no Linux. No passado, atualizei o kernel para eliminá-lo. Outros métodos são menos intrusivos, como mencionado no LVS HOWTO . < br> Se você não fizer nada, esse comportamento do ARP deverá ser consistente.

    

Answer 2

Outros dispositivos acreditam que 10.0.3.144 faz parte da rede. A máscara de sub-rede 255.255.255.255 (a.k.a. / 24) especifica o tamanho da rede de 256 endereços. Com a maneira como as sub-redes são distribuídas, a sub-rede de 256 endereços que contém 10.0.3.2-10.0.3.10 é a sub-rede que vai de 10.0.3.0 a 10.0.3.255. Portanto, quando outros dispositivos tentam se comunicar com 10.0.3.144, esse endereço parece fazer parte da mesma sub-rede. Como resultado, outros dispositivos tentarão se comunicar usando a Camada 2 (ARP, Ethernet / WiFi) e não a Camada 3 (roteamento usando IPv4 / IPv6).

O computador que recebe o tráfego da Camada 2 está reconhecendo 10.0.3.144 para fazer parte de uma sub-rede que ele usa. Assim, o computador presta atenção ao tráfego, que é endereçado ao computador. Talvez em um momento posterior, o computador pode até perceber que 10.0.3.144 é um endereço IP que está no outro NIC. Como o Networking é implementado com diferentes componentes de software, projetados para lidar com uma ou mais das "camadas" do modelo OSI, é inteiramente possível que o componente que reconheceu 10.0.3.144 como um endereço IP da Camada 3 não seja o mesmo conjunto de instruções / código / programação que determinaram que o endereço ARP era aceitável.

Entenda que os computadores normalmente não possuem endereços IP em todo o sistema. Portas de rede têm endereços IP. Assim, cada placa de rede normalmente obtém seu próprio endereço IP.

Se você não quiser que a segunda placa de rede receba tráfego, talvez seja necessário realizar uma ou mais dessas ações:

• define o endereço IP para fazer parte de uma sub-rede diferente. (Ver um gráfico de máscara de sub-rede de tamanho variável ("VLSM") pode ajudar a visualizar quais endereços fazem parte de quais sub-redes. Os gráficos comuns normalmente focam apenas no último octeto, tornando os gráficos mais fáceis de entender para redes de 24- / 32 onde os primeiros 3 octetos da máscara de sub-rede IPv4 são ("255.255.255").
• Desativar o encaminhamento pode ser útil. Eu acho que computadores diferentes podem agir de forma diferente sobre se o tráfego para um NIC diferente, no mesmo sistema, é considerado "encaminhamento". Se o encaminhamento estiver ativado, haverá ainda menos surpresa de que o tráfego possa ter atingido outra placa de rede.
• Os firewalls podem ser úteis para bloquear alguns tipos de tráfego. (Note que alguns firewalls podem ser limitados. Por exemplo, eu sei que no OpenBSD, o cliente DHCP usa BPFs que não são bloqueados pelo firewall IP.)

Para responder a outra pergunta: Bridging muitas vezes pode ser considerado como "encaminhamento da Camada 2". O encaminhamento da camada 3 também pode resultar na passagem do tráfego para outra placa de rede, mesmo que você não esteja usando a ponte da Camada 2.

Sobre se você pode confiar no comportamento: eu acredito que sim. Mas você deve entender, e fazer perguntas até que você faça. Depois de entender como as coisas devem funcionar, você pode verificar se é assim que as coisas estão funcionando; se assim for, deve ser bastante confiável. Se ainda existem mistérios, então as surpresas podem ser prováveis, por isso não deixe de perguntar sobre o que ainda não está claro.