Sim, a melhor maneira é criar um caso de negócios adequado e fazê-los relaxar as regras dos switches para que você possa ter vários IPs em uma NIC.
Recentemente, me deparei com uma situação em que eu precisava de dois endereços IP na mesma sub-rede atribuída 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 em vigor para a segurança que esmagaram essa ideia:
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 outro caminho. 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 - muito legal). Alguns toques de tecla mais tarde eu tive duas interfaces de rede em funcionamento e puxei endereços IP do DHCP.
Mas o problema veio: os administradores de rede podiam ver (no comutador) a entrada ARP para ambas as interfaces, mas apenas a primeira interface de rede que eu mencionava responderia a pings ou qualquer tipo de tráfego TCP ou UDP.
Depois de muita escavação e cutucando, aqui está o que eu fiz. Parece funcionar, mas também parece ser muito trabalhoso para algo que parece ser simples. Alguma idéia alternativa por aí?
Etapa 1: ative 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
Do 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 origem
Basicamente segui as instruções do link , embora essa página tenha sido escrita com um objetivo diferente em mente (lidando com dois ISPs).
Suponha que a sub-rede é 10.0.0.0/24, o gateway é 10.0.0.1, o endereço IP para eth0 é 10.0.0.100 e o endereço IP para eth1 é 10.0.0.101.
Defina duas novas tabelas de roteamento chamadas 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 cuidada pelo DHCP (e nem é claro que é estritamente necessário neste 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 voila! Tudo parece funcionar bem. O envio de pings para ambos os endereços IP funciona bem. Enviar pings desse 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 de / para qualquer 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 sendo incompleta. As coisas funcionavam bem se o tráfego permanecesse na mesma sub-rede, mas as comunicações com outras sub-redes usando a segunda interface não funcionariam corretamente. Em vez de cavar um buraco maior, acabei conversando com os administradores da rede e consegui que eles permitissem vários endereços IP para a única interface e usasse o aliasing de IP (por exemplo, eth0 e eth0: 0).