Duas interfaces de rede e dois endereços IP na mesma sub-rede no Linux


22

Recentemente, tive uma situação em que precisava de dois endereços IP na mesma sub-rede atribuídos a um host Linux, para que pudéssemos executar dois sites SSL / TLS. Minha primeira abordagem foi usar o aliasing de IP, por exemplo, usando eth0: 0, eth0: 1, etc., mas nossos administradores de rede têm algumas configurações bastante rígidas para segurança que esmagam essa idéia:

  1. Eles usam a espionagem DHCP e normalmente não permitem endereços IP estáticos. O endereçamento estático é realizado usando entradas DHCP estáticas, para que o mesmo endereço MAC sempre obtenha a mesma atribuição de IP. Esse recurso pode ser desativado por porta de switch, se você perguntar e tiver uma razão para isso (felizmente eu tenho um bom relacionamento com os caras da rede e isso não é difícil de fazer).
  2. Com o espionagem DHCP desativado na porta do switch, eles tiveram que colocar uma regra no switch que dizia que o endereço MAC X pode ter o endereço IP Y. Infelizmente, isso teve o efeito colateral de dizer também que o endereço MAC X só pode ter Endereço IP Y. O alias de IP exigia que o endereço MAC X tivesse dois endereços IP atribuídos, portanto isso não funcionou.

Pode ter havido uma maneira de contornar esses problemas na configuração do switch, mas, na tentativa de preservar boas relações com os administradores de rede, tentei encontrar outra maneira. Ter duas interfaces de rede parecia o próximo passo lógico. Felizmente, este sistema Linux é uma máquina virtual, então eu pude adicionar facilmente uma segunda interface de rede (sem reiniciar, devo acrescentar - bem legal). Algumas teclas depois, eu tinha duas interfaces de rede em funcionamento e as duas extraíam endereços IP do DHCP.

Mas aí surgiu o problema: os administradores de rede podiam ver (no comutador) a entrada ARP para ambas as interfaces, mas apenas a primeira interface de rede que eu criei responderia a pings ou a qualquer tipo de tráfego TCP ou UDP.

Depois de muitas escavações e cutucadas, eis o que eu criei. Parece funcionar, mas também parece ser muito trabalhoso para algo que parece simples. Alguma idéia alternativa por aí?


Etapa 1: habilite a filtragem ARP em todas as interfaces:

# sysctl -w net.ipv4.conf.all.arp_filter=1
# echo "net.ipv4.conf.all.arp_filter = 1" >> /etc/sysctl.conf

No arquivo networking / ip-sysctl.txt nos documentos do kernel do Linux:

arp_filter - BOOLEAN
    1 - Allows you to have multiple network interfaces on the same
    subnet, and have the ARPs for each interface be answered
    based on whether or not the kernel would route a packet from
    the ARP'd IP out that interface (therefore you must use source
    based routing for this to work). In other words it allows control
    of which cards (usually 1) will respond to an arp request.

    0 - (default) The kernel can respond to arp requests with addresses
    from other interfaces. This may seem wrong but it usually makes
    sense, because it increases the chance of successful communication.
    IP addresses are owned by the complete host on Linux, not by
    particular interfaces. Only for more complex setups like load-
    balancing, does this behaviour cause problems.

    arp_filter for the interface will be enabled if at least one of
    conf/{all,interface}/arp_filter is set to TRUE,
    it will be disabled otherwise

Etapa 2: implementar o roteamento baseado na fonte

Basicamente, apenas segui as instruções em http://lartc.org/howto/lartc.rpdb.multiple-links.html , embora essa página tenha sido escrita com um objetivo diferente em mente (lidar com dois ISPs).

Suponha que a sub-rede seja 10.0.0.0/24, o gateway seja 10.0.0.1, o endereço IP para eth0 seja 10.0.0.100 e o endereço IP para eth1 seja 10.0.0.101.

Defina duas novas tabelas de roteamento denominadas eth0 e eth1 em / etc / iproute2 / rt_tables:

... top of file omitted ...
1    eth0
2    eth1

Defina as rotas para essas duas tabelas:

# ip route add default via 10.0.0.1 table eth0
# ip route add default via 10.0.0.1 table eth1
# ip route add 10.0.0.0/24 dev eth0 src 10.0.0.100 table eth0
# ip route add 10.0.0.0/24 dev eth1 src 10.0.0.101 table eth1

Defina as regras para quando usar as novas tabelas de roteamento:

# ip rule add from 10.0.0.100 table eth0
# ip rule add from 10.0.0.101 table eth1

A tabela de roteamento principal já foi resolvida pelo DHCP (e nem está claro se é estritamente necessário nesse caso), mas basicamente equivale a isso:

# ip route add default via 10.0.0.1 dev eth0
# ip route add 130.127.48.0/23 dev eth0 src 10.0.0.100
# ip route add 130.127.48.0/23 dev eth1 src 10.0.0.101

E pronto! Tudo parece funcionar muito bem. Enviar pings para os dois endereços IP funciona bem. Enviar pings deste sistema para outros sistemas e forçar o ping a usar uma interface específica funciona bem ( ping -I eth0 10.0.0.1, ping -I eth1 10.0.0.1). E o mais importante, todo o tráfego TCP e UDP para / do endereço IP funciona conforme o esperado.


Então, novamente, minha pergunta é: existe uma maneira melhor de fazer isso? Isso parece muito trabalho para um problema aparentemente simples.


Atualização: a solução acima acabou incompleta. As coisas funcionavam bem se o tráfego permanecesse na mesma sub-rede, mas as comunicações com outras sub-redes usando a 2ª interface não funcionariam corretamente. Em vez de cavar um buraco maior, acabei conversando com os administradores da rede e consegui que permitissem vários endereços IP para uma interface e usei o aliasing de IP (por exemplo, eth0 e eth0: 0).


A principal diferença a lembrar é que o IP não pertence à interface, pertence à máquina. Portanto, é correto enviar qualquer interface para um ou outro IP nessa configuração, por isso é necessário alguns truques para não fazer isso.
MikeyB

Acredito que o roteamento de origem não seja necessário nesse caso, porque a filtragem arp deve ser aplicada apenas quando o switch estiver enviando para uma interface / precisar encontrá-lo entre suas portas. Eu posso estar errado, mas quando a máquina envia dados para o comutador, o IP no campo de origem (cabeçalho IP) não é verificado, apenas o arp enviando o pacote.
precisa saber é o seguinte

MikeyB está correto, o roteamento de origem é a única maneira. A máquina pode escolher qualquer interface de saída que deseje enviar tráfego, desde que esteja na mesma sub-rede. Não importa se o IP não está realmente localizado nessa interface ou não.
Patrick

2
AndreasM: Os pacotes recebidos não são o problema, são os pacotes enviados que são o problema. Sem o roteamento de origem, todos os pacotes de saída usarão a rota padrão, que é vinculada a uma interface ou a outra. Mesmo que os pacotes de saída tenham o endereço IP de origem correto, os filtros no switch não permitirão que eles saiam, pois esse endereço IP não pertence ao endereço MAC dessa interface. Para o switch, parece que um cliente está tentando falsificar o IP de outro cliente. (Esses são os switches inteligentes da camada 3).
Scott Duckworth

Os aliases de IP são obsoletos e um hack, não reflete a realidade, sem mencionar que derrubar o primário eliminará todos os aliases. Use ipfrom iproute2para adicionar mais de um endereço à mesma interface.
Pilona

Respostas:


8

Sim, a melhor maneira é criar um caso de negócios adequado e fazer com que relaxem as regras nos comutadores para que você possa ter vários IPs em uma NIC.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.