Primeiro: a rota "meio-padrão" 128.0.0.0/1 (sem a outra metade 0.0.0.0/1 ??) não deve existir se o roteador não usar o túnel:
# ip route del 128.0.0.0/1 via 10.8.8.1 dev tun0
Como é mais provável que seja definido a partir do software do túnel, lide com sua configuração.
Agora crie uma nova tabela (escolha aleatória: 100) com uma rota padrão no túnel e use-a apenas para o tráfego da eth2:
# ip route add default via 10.8.8.1 dev tun0 table 100
# ip rule add iif eth2 lookup 100
Testes:
O host está usando a rota padrão usual, qualquer que seja seu IP de origem (conforme a pergunta, o seletor do túnel é da interface, não do IP):
# ip -o route get 8.8.8.8
8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.56 \ cache
# ip -o route get 8.8.8.8 from 192.168.0.1
8.8.8.8 from 192.168.0.1 via 192.168.1.1 dev eth0 \ cache
O tráfego da eth2 será tratado de maneira diferente:
# ip -o route get 8.8.8.8 from 192.168.0.2 iif eth2
8.8.8.8 from 192.168.0.2 via 10.8.8.1 dev tun0 table 100 \ cache iif eth2
Se você também quiser que o IP 192.168.0.1 local atravesse o túnel. É um pouco mais complexo porque o 192.168.0.1 precisa enviar pacotes IP para sua própria LAN, se necessário (e não para tun0 neste caso). Requer a cópia da rota da LAN também para a tabela 100, adicionando uma regra baseada no IP de origem (e, em seguida, removendo a regra anterior inútil baseada na interface):
# ip route add 192.168.0.0/24 dev eth2 table 100
# ip rule add from 192.168.0.0/24 lookup 100
( # ip rule del iif eth2 lookup 100 )
O que agora também dá:
# ip -o route get 8.8.8.8 from 192.168.0.1
8.8.8.8 from 192.168.0.1 via 10.8.8.1 dev tun0 table 100 \ cache
É isso para roteamento. Note que, sem NAT, a outra extremidade do túnel precisa de uma rota para 192.168.0.0/24 via 10.8.8.27 ou não funcionará. Esta deve ser a escolha preferida.
Se esta rota no remoto não estiver definida, e o NAT estiver bom o suficiente, configure-o com:
# iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o tun0 -j MASQUERADE