Linux dev net tun

OpenVPN — ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)

There are lots of questions pertaining this error, and there is a suggested manual fix which works well, but there’s no permanent solution. How can i permanently solve this? Im having this issue on a debian wheezy server, using OpenVPN client to connect to an OpenVPN server. The suggested fix is the one below. Seems like, /dev/net is not automatically created and of course disappears on each reboot.

mkdir -p /dev/net mknod /dev/net/tun c 10 200 chmod 600 /dev/net/tun 

it’s work like a charm on synology nas, i was try to use zerotier and was unable until i see this answer .

3 Answers 3

debian wheezy has been out of support since may 2018 (https://www.debian.org/releases/wheezy/), you should not be using it in 2020 any more for production.

Now, with that out of the way, you could add the commands that temporarily fix your issue adding those commands a bash script that you add to your root crontab with the @reboot nickname (man 5 crontab).

So create a bash script somewhere in your file system with something like this:

#!/bin/bash mkdir -p /dev/net mknod /dev/net/tun c 10 200 chmod 600 /dev/net/tun /etc/init.d/openvpn restart 

Save it with 755 permissions and modify the root crontab:

with this content at least

@reboot /path/to/where/you/saved/the/script 

And after rebooting it should have started openvpn successfully.

As an alternative, the code snippet can be be written into /etc/default/openvpn file, which is sourced by /etc/init.d/openvpn script.

nice, I do not have a debian wheezy handy to test, but this should be the preferred option if it works

It happens in Arch/Manjaro as well.

I managed to figure out the problem, apparently a kernel upgrade is simply moving the modules directory, so trying to reach the modules from their known location is unavailable, the current running kernel is still running but I can’t seem to modprobe (load) any modules which are not already loaded (such as tun required for OpenVPN connections).

So for example, the /lib/modules/ directory had the following directories before the upgrade (I have multiple kernels, notice the 5.16 series):

5.15.32-1-MANJARO *5.16.14-1-MANJARO* extramodules-5.15-MANJARO extramodules-5.16-MANJARO 

And this is the status after the upgrade:

5.15.32-1-MANJARO *5.16.18-1-MANJARO* extramodules-5.15-MANJARO extramodules-5.16-MANJARO 

Trying to load the tun modules shows the following message:

modprobe: FATAL: Module tun not found in directory /lib/modules/5.16.14-1-MANJARO 

Which perfectly makes sense as this directory doesn’t exist.
So, what is my proposed solution in this case? A restart.

I think that a possible solution is to configure the system to load the tun kernel module during startup. In order to do so, list the tun module name in /etc/modules file:

udev is the system component that creates and maintains device nodes in /dev folder according to loaded kernel modules and connected hardware devices. I believe that by loading tun kernel module at boot time, the system will create the /dev/net/tun device node on every startup.

EDIT: I am a bit outdated. After launching a Debian Wheezy image published in Vagrant Cloud website, I figured out that udev in fact handles permissions, ownerships and symlinks regarding already existing device nodes. Device nodes are actually created by the kernel itself and are exposed to userspace through the devtmpfs pseudo-filesystem.

devtmpfs filesystem is mounted at initramfs time. The file /usr/share/initramfs-tools/init , which gets executed once grub extracts initramfs to memory, presents code that mounts a devtmpfs filesystem into /dev , falling back to a standard tmpfs filesystem if unsuccessful.

In addition, to have devtmpfs filesystem available, Debian Wheezy kernel is shipped with CONFIG_DEVTMPFS=y enabled.

Источник

создание

уверен, что «grep _TUN /usr/src/linux/.config» совпадает с «zgrep _TUN /proc/config.gz» ?

grep «TUN» /usr/src/linux/.config — не говорит ни о чём.

zgrep TUN /proc/config.gz покажи, как уже выше посоветовали

Pinkbyte ★★★★★ ( 30.05.15 11:55:09 MSK )
Последнее исправление: Pinkbyte 30.05.15 11:55:22 MSK (всего исправлений: 1)

 grep _TUN /usr/src/linux/.config CONFIG_YENTA_ENE_TUNE=y CONFIG_NET_IP_TUNNEL=y # CONFIG_NET_UDP_TUNNEL is not set # CONFIG_INET_XFRM_TUNNEL is not set CONFIG_INET_TUNNEL=y # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set CONFIG_INET6_XFRM_MODE_TUNNEL=y # CONFIG_IPV6_TUNNEL is not set CONFIG_TUN=y # CONFIG_8139TOO_TUNE_TWISTER is not set # zgrep TUN /proc/config.gz CONFIG_YENTA_ENE_TUNE=y CONFIG_NET_IP_TUNNEL=y # CONFIG_NET_UDP_TUNNEL is not set # CONFIG_INET_XFRM_TUNNEL is not set CONFIG_INET_TUNNEL=y # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set CONFIG_INET6_XFRM_MODE_TUNNEL=y # CONFIG_IPV6_TUNNEL is not set # CONFIG_TUN is not set # CONFIG_8139TOO_TUNE_TWISTER is not set 

эмм а почему CONFIG_TUN is not set ?!

Какбы в ядре вроде грузится ?!

 ls -l /boot итого 19212 -rw-r--r-- 1 root root 97247 май 30 06:45 config-3.18.11-gentoo -rw-r--r-- 1 root root 97258 май 3 18:24 config-3.18.11-gentoo.old -rw-r--r-- 1 root root 3300026 май 30 06:45 System.map-3.18.11-gentoo -rw-r--r-- 1 root root 3297885 май 3 18:24 System.map-3.18.11-gentoo.old -rw-r--r-- 1 root root 6436736 май 30 06:45 vmlinuz-3.18.11-gentoo -rw-r--r-- 1 root root 6431360 май 3 18:24 vmlinuz-3.18.11-gentoo.old # grep "_TUN=" /boot/config-3.18.11-gentoo CONFIG_TUN=y # grep "_TUN=" /boot/config-3.18.11-gentoo.old # 

openvpn сам его создаст, руками не надо.

Источник

Universal TUN/TAP device driver¶

Linux, Solaris drivers Copyright © 1999-2000 Maxim Krasnyansky

FreeBSD TAP driver Copyright © 1999-2000 Maksim Yevmenkin

Revision of this document 2002 by Florian Thiel

1. Description¶

TUN/TAP provides packet reception and transmission for user space programs. It can be seen as a simple Point-to-Point or Ethernet device, which, instead of receiving packets from physical media, receives them from user space program and instead of sending packets via physical media writes them to the user space program.

In order to use the driver a program has to open /dev/net/tun and issue a corresponding ioctl() to register a network device with the kernel. A network device will appear as tunXX or tapXX, depending on the options chosen. When the program closes the file descriptor, the network device and all corresponding routes will disappear.

Depending on the type of device chosen the userspace program has to read/write IP packets (with tun) or ethernet frames (with tap). Which one is being used depends on the flags given with the ioctl().

The package from http://vtun.sourceforge.net/tun contains two simple examples for how to use tun and tap devices. Both programs work like a bridge between two network interfaces. br_select.c — bridge based on select system call. br_sigio.c — bridge based on async io and SIGIO signal. However, the best example is VTun http://vtun.sourceforge.net :))

2. Configuration¶

mkdir /dev/net (if it doesn't exist already) mknod /dev/net/tun c 10 200

There’s no harm in allowing the device to be accessible by non-root users, since CAP_NET_ADMIN is required for creating network devices or for connecting to network devices which aren’t owned by the user in question. If you want to create persistent devices and give ownership of them to unprivileged users, then you need the /dev/net/tun device to be usable by those users.

Driver module autoloading

Make sure that «Kernel module loader» — module auto-loading support is enabled in your kernel. The kernel should load it on first access.

insert the module by hand:

If you do it the latter way, you have to load the module every time you need it, if you do it the other way it will be automatically loaded when /dev/net/tun is being opened.

3. Program interface¶

3.1 Network device allocation¶

char *dev should be the name of the device with a format string (e.g. «tun%d»), but (as far as I can see) this can be any valid network device name. Note that the character pointer becomes overwritten with the real device name (e.g. «tun0»):

#include #include int tun_alloc(char *dev) < struct ifreq ifr; int fd, err; if( (fd = open("/dev/net/tun", O_RDWR)) < 0 ) return tun_alloc_old(dev); memset(&ifr, 0, sizeof(ifr)); /* Flags: IFF_TUN - TUN device (no Ethernet headers) * IFF_TAP - TAP device * * IFF_NO_PI - Do not provide packet information */ ifr.ifr_flags = IFF_TUN; if( *dev ) strscpy_pad(ifr.ifr_name, dev, IFNAMSIZ); if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 )< close(fd); return err; >strcpy(dev, ifr.ifr_name); return fd; >

3.2 Frame format¶

If flag IFF_NO_PI is not set each frame format is:

Flags [2 bytes] Proto [2 bytes] Raw protocol(IP, IPv6, etc) frame.

3.3 Multiqueue tuntap interface¶

From version 3.8, Linux supports multiqueue tuntap which can uses multiple file descriptors (queues) to parallelize packets sending or receiving. The device allocation is the same as before, and if user wants to create multiple queues, TUNSETIFF with the same device name must be called many times with IFF_MULTI_QUEUE flag.

char *dev should be the name of the device, queues is the number of queues to be created, fds is used to store and return the file descriptors (queues) created to the caller. Each file descriptor were served as the interface of a queue which could be accessed by userspace.

#include #include int tun_alloc_mq(char *dev, int queues, int *fds) < struct ifreq ifr; int fd, err, i; if (!dev) return -1; memset(&ifr, 0, sizeof(ifr)); /* Flags: IFF_TUN - TUN device (no Ethernet headers) * IFF_TAP - TAP device * * IFF_NO_PI - Do not provide packet information * IFF_MULTI_QUEUE - Create a queue of multiqueue device */ ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_MULTI_QUEUE; strcpy(ifr.ifr_name, dev); for (i = 0; i < queues; i++) < if ((fd = open("/dev/net/tun", O_RDWR)) < 0) goto err; err = ioctl(fd, TUNSETIFF, (void *)&ifr); if (err) < close(fd); goto err; >fds[i] = fd; > return 0; err: for (--i; i >= 0; i--) close(fds[i]); return err; >

A new ioctl(TUNSETQUEUE) were introduced to enable or disable a queue. When calling it with IFF_DETACH_QUEUE flag, the queue were disabled. And when calling it with IFF_ATTACH_QUEUE flag, the queue were enabled. The queue were enabled by default after it was created through TUNSETIFF.

fd is the file descriptor (queue) that we want to enable or disable, when enable is true we enable it, otherwise we disable it:

#include #include int tun_set_queue(int fd, int enable)

Universal TUN/TAP device driver Frequently Asked Question¶

Currently driver has been written for 3 Unices:

As mentioned above, main purpose of TUN/TAP driver is tunneling. It is used by VTun (http://vtun.sourceforge.net).

Another interesting application using TUN/TAP is pipsecd (http://perso.enst.fr/~beyssac/pipsec/), a userspace IPSec implementation that can use complete kernel routing (unlike FreeS/WAN).

Virtual network device can be viewed as a simple Point-to-Point or Ethernet device, which instead of receiving packets from a physical media, receives them from user space program and instead of sending packets via physical media sends them to the user space program.

Let’s say that you configured IPv6 on the tap0, then whenever the kernel sends an IPv6 packet to tap0, it is passed to the application (VTun for example). The application encrypts, compresses and sends it to the other side over TCP or UDP. The application on the other side decompresses and decrypts the data received and writes the packet to the TAP device, the kernel handles the packet like it came from real physical device.

TUN works with IP frames. TAP works with Ethernet frames.

This means that you have to read/write IP packets when you are using tun and ethernet frames when using tap.

BPF is an advanced packet filter. It can be attached to existing network interface. It does not provide a virtual network interface. A TUN/TAP driver does provide a virtual network interface and it is possible to attach BPF to this interface.

Yes. Linux and FreeBSD drivers support Ethernet bridging.

Источник