OpenVPN num VPS: nenhum dispositivo /dev/net/tun para abrir

O primeiro arranque falha com uma mensagem sobre /dev/net/tun ou um dispositivo TUN/TAP que não pode ser aberto. Os certificados ainda não foram lidos, por isso nada no perfil está implicado. O daemon está a pedir ao kernel um objeto que este guest não tem.

Esse objeto é um dispositivo de caracteres suportado pelo módulo tun. Se o pode criar depende de quem possui o kernel.

O que o daemon pede ao kernel

OpenVPN abre /dev/net/tun e pede ao driver uma interface. O driver é o módulo tun, e o nó do dispositivo é a pega que o espaço de utilizador usa para o alcançar. Se o módulo não estiver carregado, o nó pode faltar ou a abertura pode falhar. Nenhuma das condições se corrige editando server.conf.

Leia o erro primeiro como uma pergunta sobre a plataforma. Um erro de configuração aparece depois de o dispositivo abrir, não antes.

VM ou guest com kernel partilhado

Num KVM, Xen ou outra máquina virtual completa, o kernel está sob o seu controlo. Pode carregar módulos e criar o nó. Num OpenVZ, Virtuozzo ou contentor ao estilo LXC, o guest partilha o kernel do anfitrião, pelo que root lá dentro não pode carregar um módulo que o anfitrião não carregou.

A mesma falha tem, portanto, dois donos muito diferentes. No primeiro caso pode corrigi-la a partir do interior da instância. No segundo está a pedir ao anfitrião, ou ao fornecedor, que exponha algo.

Execute ls -l /dev/net/tun, lsmod | grep tun e ip -brief link show antes de decidir em que caso está.

Numa VM, carregue o módulo no arranque

Numa máquina virtual, modprobe tun normalmente cria o nó do dispositivo. Verifique que aparece e depois torne o carregamento permanente através da configuração de módulos da distribuição, em vez de confiar num comando escrito uma vez. Um nó que desaparece após um reinício torna-se no mesmo ticket no mês seguinte.

Verifique também se o kernel que arrancou tem o módulo de todo. Um kernel de fornecedor reduzido pode não o ter.

Se o nó existe mas a abertura continua a falhar, as permissões e os números major/minor do dispositivo são os próximos suspeitos. São correções locais, não pedidos ao fornecedor.

Num contentor, o dispositivo pertence ao anfitrião

Num contentor, o dispositivo e a capacidade são dois requisitos separados. O runtime tem de deixar passar /dev/net/tun, e o contentor precisa da capacidade de rede para criar uma interface. Um runtime rootless que não concede nenhuma das duas continuará a produzir o mesmo erro de abertura, por muito bem escrito que esteja o perfil. Muitos anfitriões OpenVZ oferecem um botão TUN/TAP no painel do cliente, e ativá-lo mais um reinício é muitas vezes a solução completa.

Faça ao fornecedor duas perguntas precisas: o módulo tun está carregado no anfitrião e o dispositivo está disponível dentro desta instância? Um ticket vago recebe uma resposta vaga.

Porque reconstruir o módulo raramente ajuda

Compilar um módulo dentro do guest raramente ajuda. A compilação exige a configuração exata do kernel em execução, e /proc/config.gz é opcional e muitas vezes está ausente em imagens mínimas. Mesmo um módulo funcional não pode ser inserido num kernel que o contentor não possui.

Depois de o dispositivo aparecer, reinicie o serviço e confirme a interface antes de testar tráfego. Ver tun0 mostra que o daemon abriu o dispositivo. Ainda não diz nada sobre encaminhamento, regras de firewall ou as rotas que os clientes recebem.

São perguntas separadas com provas separadas. Um dispositivo em falta é uma falha de pré-requisito; um túnel que existe mas não transporta nada é uma falha de política.