How to find out which process keeps tunnel interface(tun) up?

Question

If I create a tun interface with ip tuntap add mode tun command and force it administratively up with ip link set dev tun1 up command, then the interface itself is always "physically" down:

root@A58:~# ip link show dev tun1
46: tun1: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 500
    link/none 
root@A58:~# 

This makes sense as there are no applications connected to this interface. However, I also have tun0 in my system which is "physically" up:

root@A58:~# ip link show dev tun0
45: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 100
    link/none 
root@A58:~# 

Is there a way to find out which process is connected to this tun0 interface? I had no luck with ps -ef | grep tun0 or lsof | grep tun0.

Solution 1

The Linux kernel exposes this info now in /proc/$PID/fdinfo/$FD. For example:

# grep ^iff: /proc/*/fdinfo/*
/proc/31219/fdinfo/5:iff:       tun0
/proc/31235/fdinfo/5:iff:       tun1
/proc/31252/fdinfo/5:iff:       tun2
/proc/31267/fdinfo/5:iff:       tun3

Tested with Debian 5.8.10.

Solution 2

It doesn't looks like the kernel exposes this information. Therefore, short of kernel debugging, I don't think you can know this. The best you can do is list all processes that have tun or tap devices open like this:

lsof /dev/net/tun

So that will narrow it down, but in the case where there are multiple active tun interfaces on the system, it doesn't tell you which process is managing which tunnel.

When a process wants to create a tun interface, it opens /dev/net/tun no matter which tun interface it intends to use. Then, it either lets the kernel dynamically assign a new tun interface name (like tun0, tun1, tun2 etc...) or it sets a chosen name. This is done with an ioctl call with code TUNSETIFF. So unless you get to trace that ioctl call, there isn't really a way to tell what name got assigned.

Comments

[Celada]

That doesn't seem to do anything useful at all for me. The find finds a whole bunch of files under /proc/sys/net and even more under /proc/<every single process id>/net/dev_snmp6, none of which are useful to pipe info lsof. As for lsof, I can see that processes using tun devices hold open /dev/net/tun and that tells you that the process is sitting behind a tun/tap interface but it doesn't tell you which one.

[frogstarr78]

I don't understand. The <every single process_id> is what you're attempting to pipe to lsof -using the -P option which takes a pid. Using this method worked on my system. What version of lsof? I'm using 4.87

[Celada]

Why do you want to find every valid process ID on the system (or more correctly, every process ID that exists in the same network namespace as the tun interface... but that usually means every process on the system) and pipe them all into lsof? It doesn't give you any information about which process is controlling the tun interface.

[IpsRich]

Strangely, for me (on Mint based upon Ubuntu 18.04) this didn't work but should have. If instead of grep ^iff: /proc/*/fdinfo/* (which for me returns nothing) I do grep -R ^iff: /proc/*/fdinfo it gives similar output to the above! Actually, I take that back! It does work but only when logged in as root. If I run the command via sudo it doesn't work, presumably because my user is not allowed to see what's below /proc/*/fdinfo. I considered deleting my comment but actually, I can't be the only one who will make that mistake! :-)