Veja novamente a tabela de roteamento ( ip route ). Você notará que há uma rota default para 10.13.10.5 ou um par de 0.0.0.0/1 / 128.0.0.0/1 rotas para 10.13.10.5 (que é apenas um truque que permite que o OpenVPN mantenha a rota padrão, embora se torne inativo), e esta rota passa por tun0 .
Não importa qual% IP tun0 tenha, o que importa é o IP gateway , que por acaso é 10.13.10.5 e está do outro lado de tun0 .
Então, como o OpenVPN faz todo o tráfego entrar em tun0 ? Ao fornecer rotas, assim como sem o OpenVPN, todo o tráfego vai para eth0 (ou wlan0 , ou para onde quer que a rota padrão diga).
O OpenVPN não faz nada de especial. Em particular, ele não usa um socket bruto, ele cria uma interface tun / tap.
Editar
O OpenVPN não "escuta o tráfego ligado ao outro lado".
Quando o kernel Linux vê um pacote de rede, ele consulta a tabela de roteamento para decidir o que fazer com o pacote. Se a tabela de roteamento disser "enviar todos os pacotes para o gateway 10.13.10.5 via tun0 ", é isso que o kernel do Linux faz. O OpenVPN não está envolvido de forma alguma nisso.
Agora o OpenVPN criou tun0 , então o que acontece quando o kernel coloca um pacote em tun0 é que o OpenVPN pode ler este pacote. Isso é o que uma interface tun / tap faz: permite que uma aplicação leia pacotes colocados nesta interface (pelo kernel), e também escrever pacotes que serão emitidos desta interface (que também será tratada como o kernel, assim como se o pacote veio de uma placa de rede real).
Nenhum modo promíscuo envolvido. O problema é que você não entende como a interface tun / tap funciona?