Isso me fez pensar e eu dei uma olhada na fonte do kernel do Linux (suponho que sua pergunta é sobre o Linux).
Parece que a resposta é mais difícil do que você esperaria. Esta página do tutorial da TUN / TAP API oferece algumas dicas . Basicamente, seu programa aloca um novo dispositivo TUN / TAP abrindo /dev/net/tun
e enviando o TUNSETIFF
ioctl
. Se tudo correr bem, uma interface é criada, o kernel lhe dá seu nome e um descritor de arquivo, e é assim que você o gerencia.
Existem duas capturas aqui:
- O kernel não armazena o PID do processo que enviou o ioctl em
struct tun_struct
(o TUN e o TAP compartilham em grande parte as mesmas estruturas de dados). - Um processo pode marcar uma interface como persistente, fechar seu descritor de arquivo e, posteriormente, usá-lo como uma interface de rede normal.
Na prática, eu suspeito que 2 não aconteça muito. A verificação de um processo openvpn
com lsof
revela que ele ainda tem seu descritor de arquivo aberto no dispositivo TAP e obviamente o usa, mas como /dev/net/tun
é uma espécie de dispositivo de multiplexação como /dev/ptmx
, é possível usar lsof
para descobrir quais processos estão atualmente usando um dispositivo TUN / TAP, mas você não pode saber qual processo está usando o dispositivo.
Existem formas oblíquas de resolver o problema subjacente. Para o OpenVPN, eu uso um script de configuração de encapsulamento que nomeia os dispositivos tunX
/ tapX
com um nome mais descritivo que inclui o nome de base do arquivo de configuração do OpenVPN. Portanto, /etc/openvpn/foo.conf
leva a um dispositivo vpn-foo
. Então eu posso correlacionar o processo OpenvVPN com a interface que ele está usando. Ainda não tive que fazer isso com o QEmu / KVM.