De acordo com o diagrama de caminho do pacote , e seu description :
Table 6-2. Source local host (our own machine)
[...]
- Routing decision, since the previous mangle and nat changes may have changed how the packet should be routed.
[...]
há uma segunda pesquisa de rota após a cadeia OUTPUT, porque o NAT e outras coisas podem ter alterado a interface de saída real. Mas nos meus testes descobri que é impossível mudar a interface de saída depois de escolhida .
Por exemplo, você tem um aplicativo que envia um pacote UDP de um soquete não acoplado para algum destino: a tabela principal é consultada e uma origem, interface e gateway padrão são escolhidos. Em seguida, você define um fwmark e usa isso no roteamento baseado em política para tentar colocar o pacote em outra interface:
[root@localhost ~]# ip rule add fwmark 1 lookup 1
[root@localhost ~]# ip route add default dev lo table 1
O pacote terá essas pesquisas
#first lookup, assuming main NIC is in LAN with address 192.168.1.2/24, gateway 192.168.1.1
[root@localhost ~]# ip route get 8.8.8.8
8.8.8.8 from 192.168.1.2 via 192.168.1.1 dev eth0
cache
#second lookup, source address and oif chosen
[root@localhost ~]# ip route get 8.8.8.8 oif eth0 from 192.168.1.2 mark 1
8.8.8.8 from 192.168.1.2 via 192.168.1.1 dev wlp3s0 mark 1
cache
Seu pacote ainda terá a interface de saída já escolhida. Observe que, se você não definir o parâmetro oif , obterá a interface correta:
[root@localhost ~]# ip route get 8.8.8.8 from 192.168.1.2 mark 1
8.8.8.8 from 192.168.1.2 dev lo mark 1
cache
Então, qual é o ponto? Parece (e eu testei) que você pode efetivamente alterar apenas o gateway, mas você não pode usar blackhole ou unreachable .