Você deve conseguir realizar o que quiser usando este comando:
ip route add 10.10.0.10 dev eth0:1 src 192.168.111.5
Se você inserir ip route list , verá a alteração de src .
Estou tentando isolar o tráfego de rede de saída para um destino específico para fins de medição. Por isso, achei que seria o roteamento por meio de um endereço IP dedicado. Para conseguir isso eu configurei uma subinterface eth0:1 , que aparece da seguinte maneira:
# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:42:ae:d3 brd ff:ff:ff:ff:ff:ff
inet 192.168.111.6/24 brd 192.168.111.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.111.5/24 brd 192.168.111.255 scope global secondary eth0:1
valid_lft forever preferred_lft forever
Até aí tudo bem. A peça de roteamento que deveria fazer funcionar é esta:
# ip route add 10.10.0.10 via 192.168.111.1 dev eth0:1
Quando eu verifico a tabela de roteamento, recebo:
# ip route list
default via 192.168.111.1 dev eth0
10.10.0.10 via 192.168.111.1 dev eth0
192.168.111.0/24 dev eth0 proto kernel scope link src 192.168.111.6
Observe a segunda linha, que termina em dev eth0 em vez de eth0:1 , como eu esperava, mas até agora isso pode ser apenas um problema de exibição. No entanto, ao observar o tráfego usando tcpdump , fica óbvio que a rota está se comportando como a tela acima sugere, ou seja: tráfego para 10.10.0.10 transita pela interface principal eth0 , usando seu IP 192.168.111.6 em vez de eth0:1's IP 192.168.111.5 .
O mais estranho é que, se eu usar um NIC dedicado (eth1) em vez de uma subinterface como acima, tudo funcionará como esperado. Isso é uma limitação de subinterfaces, um bug ou estou fazendo algo errado?
O SO é o servidor Ubuntu 14.04.3 em execução no kernel 3.13.0-76. É uma VM guest hospedada em um hypervisor KVM (embora eu duvide que isso seja um fator).