Você poderia emprestar sua experiência para entender como configurar a separação do tráfego de rede em duas interfaces de rede?
Pelo que entendi até agora, as rotas estáticas são usadas para o tráfego de rede que não foi projetado para usar um gateway padrão. O gateway padrão é usado para todo o tráfego não destinado à rede local e para o qual nenhuma rota preferencial foi especificada em uma tabela de roteamento.
O cenário é o seguinte.
- Cada computador na rede possui duas placas de rede.
- A interface de produção para cada um é
eth0(GW = 10.10.10.1). - A interface de gerenciamento para cada um é
eth1(GW = 192.168.100.1). - O tráfego de produção e gerenciamento deve ser totalmente separado.
Postei, abaixo, o que tentei com o Debian Wheezy. E, meu problema é que, embora eu tenha hosts configurados de tal maneira que eles se comuniquem nas duas interfaces, os hosts individuais parecem "ouvir" o tráfego na interface errada. Por exemplo:
Anfitrião 140
eth0 Link encap:Ethernet HWaddr 08:00:27:d1:b6:8f
inet addr:10.10.10.140 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fed1:b68f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1341 errors:0 dropped:0 overruns:0 frame:0
TX packets:2530 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:641481 (626.4 KiB) TX bytes:241124 (235.4 KiB)
eth1 Link encap:Ethernet HWaddr 08:00:27:ad:14:b6
inet addr:192.168.100.140 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fead:14b6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7220 errors:0 dropped:0 overruns:0 frame:0
TX packets:5257 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:602485 (588.3 KiB) TX bytes:1022906 (998.9 KiB)
A partir do host 140, eu executar o comando: tcpdump -i eth0. Em uma sessão separada no host 140, eu executo ping 192.168.100.50.
19:17:29.301565 IP 192.168.100.140 > 192.168.100.50: ICMP echo request, id 1400, seq 10, length 64
19:17:30.301561 IP 192.168.100.140 > 192.168.100.50: ICMP echo request, id 1400, seq 11, length 64
19:17:31.301570 IP 192.168.100.140 > 192.168.100.50: ICMP echo request, id 1400, seq 12, length 64
19:17:32.301580 IP 192.168.100.140 > 192.168.100.50: ICMP echo request, id 1400, seq 13, length 64
Por que vejo a saída acima ativada eth0? Acho que só devo ver o tráfego para 10.10.10.140. Também vejo isso eth1como esperado:
19:18:47.805408 IP 192.168.100.50 > 192.168.100.140: ICMP echo request, id 1605, seq 247, length 64
Se eu executar ping no host 50 (mesmos ifconfigresultados - apenas um último quadrilátero diferente), eth0ficaremos em silêncio e vejo o eco do ICMP ativado eth1, conforme o esperado.
Gostaria de entender como configurar cada interface para lidar apenas com o tráfego pelo qual é responsável nas duas principais variedades do Linux. Acho que estou quase lá, mas estou perdendo algo que simplesmente não consigo encontrar.
- Debian Wheezy (7.x) ou Debian Jessie (8.x)
- Enterprise Linux (6.x) (RedHat / CentOS / Scientific / Oracle).
Eu sei que uma solução para o Debian deve ser boa tanto para Wheezy quanto para Jessie, e que uma solução para um EL deve ser a mesma para todas as versões do EL 6.x. Gostaria de evitar o uso de um script RC para executar comandos, optando por usar os arquivos de configuração.
No Debian, os arquivos de configuração relevantes que eu conheço são:
/etc/network/interfaces
No EL 6.x, os arquivos de configuração relevantes que eu conheço são:
/etc/sysconfig/network/etc/sysconfig/network-scripts/ifcfg-eth0/etc/sysconfig/network-scripts/ifcfg-eth1/etc/sysconfig/network-scripts/route-eth0/etc/sysconfig/network-scripts/route-eth1/etc/sysconfig/network-scripts/rule-eth0/etc/sysconfig/network-scripts/rule-eth1
Meu /etc/network/interfacesarquivo "Jessie" do Debian 8 :
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# Production interface
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 10.10.10.140
netmask 255.255.255.0
gateway 10.10.10.1
# Management interface
auto eth1
allow-hotplug eth1
iface eth1 inet static
address 192.168.100.140
netmask 255.255.255.0
Eu acho que netstat -anrpode ilustrar o problema:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.10.10.1 0.0.0.0 UG 0 0 0 eth0
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
iptabels -L -t natRespostas:
Gostaria de saber mais sobre este tópico para refinar a configuração para ser a melhor possível, mas aqui está o que tenho até agora. Mesmo sem ativar a filtragem ARP em todas as interfaces de rede (
net.ipv4.conf.all.arp_filter = 0), como mencionado pelo @spuk, o tráfego parece estar completamente separado nessa configuração.O arquivo
/etc/iproute2/rt_tables,, é o mesmo no EL 6.xe DEB 7/8, pelo menos. Este é o arquivo que cria uma tabela de roteamento nomeada para rotas estáticas.Acima, o número da rota estática nomeada, 1, é essencialmente arbitrário; ou, cada rota estática recebe seu próprio número exclusivo entre 1 e 252.
O arquivo,
/etc/network/interfacesem DEB 7/8, pelo menos:O resultado do
ip route showDebian:O
/etc/sysconfig/networkarquivo EL 6.x :Acima, GATEWAY é a rota padrão. Abaixo, se o BOOTPROTOCOL estivesse definido como DHCP, a rota padrão seria adquirida do DHCP.
O
/etc/sysconfig/network-scripts/ifcfg-eth0arquivo EL 6.x , sem "HWADDR" e "UUID":O
/etc/sysconfig/network-scripts/ifcfg-eth1arquivo EL 6.x , sem "HWADDR" e "UUID":O
/etc/sysconfig/network-scripts/route-eth1arquivo EL 6.x :O
/etc/sysconfig/network-scripts/rule-eth1arquivo EL 6.x :O resultado do
ip route showEL 6.x:fonte
Não li completamente toda a sua postagem (desculpe, não posso gastar muito tempo no momento), mas acredito que possa estar relacionada à maneira como o Linux implementa o modelo de host IP :
Nessa mesma página:
Ou seja, no Linux, por padrão, os endereços IP "pertencem ao host", não estritamente "à interface". Você pode alterar esse comportamento através da
arp_filter,rp_filter,arp_announce,arp_ignoresysctls (GOT de LVS: O ARP problema , visto aqui ). Além disso, consulte ip-sysctl.txt .fonte