tun pré-criado no OpenVPN: comparar os dois modelos de propriedade

Alguém pré-criou tun1, o perfil diz dev tun1, e a ligação continua a não anexar. A existência do nome no anfitrião não diz quase nada, porque a anexação depende do espaço de nomes, do tipo de dispositivo, de quem é dono da ligação e do que é permitido ao daemon. Reutilizar um dispositivo também força uma decisão que a configuração padrão esconde: que componente escreve os endereços e as rotas. Os modos de falha dos dois arranjos diferem muito mais do que as linhas de configuração, por isso decida antes de editar um perfil.

Um nome não é uma anexação

dev tun1 pede ao OpenVPN essa interface nomeada, e as compilações tradicionais em espaço de utilizador tentarão abri-la. Se o nome não seguir o padrão habitual tun ou tap, o perfil também precisa de um dev-type correspondente, porque o tipo nunca é inferido de uma cadeia. Um dispositivo TAP não é um dispositivo TUN com outro rótulo: anexar o errado ou falha de imediato ou produz uma ligação que transporta tramas que ninguém espera. Verifique o tipo antes de tudo o resto, pois cada verificação posterior assume que os dois lados concordam quanto a ele. A partir daí, confirme que o processo consegue realmente abrir o dispositivo, e não apenas vê-lo.

dev tun1
dev-type tun

A interface de rede e /dev/net/tun são objetos diferentes: uma é uma ligação dentro de um espaço de nomes, a outra é o dispositivo de caracteres que um programa em espaço de utilizador usa para anexar. A documentação do Linux TUN/TAP descreve esse caminho de anexação e as regras de propriedade dos dispositivos persistentes. Uma shell root capaz de executar ip link só prova que a shell tem privilégios, não que o daemon os tenha. A propriedade do nó do dispositivo, o conjunto de capacidades do serviço e o utilizador sob o qual corre têm de estar todos alinhados antes de a abertura ter sucesso.

Um dispositivo que existe e não abre é um problema de propriedade, não de encaminhamento. Trate-o como tal ao depurar, ou a tarde passa a ler tabelas de rotas que nunca foram o problema.

Quem configura a ligação: dois modelos de propriedade

No primeiro modelo, o OpenVPN configura endereços e rotas como parte de levantar a ligação. É o comportamento padrão e o mais fácil de raciocinar, porque um único componente cria o estado e volta a removê-lo. No segundo modelo, um gestor externo é dono da interface, e ifconfig-noexec impede o OpenVPN de executar os seus comandos de configuração de endereços e entrega os parâmetros a scripts. O gestor tem então de aplicar ele mesmo a configuração local e do par correta, o que dá mais trabalho do que o nome da opção sugere. Escolher entre os dois é uma questão de quem pode alterar a ligação enquanto está levantada.

ifconfig-noexec abrange apenas os endereços: a tabela de rotas fica intacta, e a configuração de rotas pertence a route-noexec. Trate as duas diretivas como controlos separados com proprietários separados, porque definir uma e presumir a outra é uma fonte comum de ligações meio configuradas. Escolha exatamente um proprietário por camada, os endereços num sítio e as rotas num sítio. Um gestor de rede e um assistente de VPN que ambos escrevem endereços é como uma desconexão apaga estado do qual o outro lado ainda depende.

Inspecione o dispositivo a partir do espaço de nomes que conta

Inspecione o dispositivo a partir do espaço de nomes em que o processo VPN corre, não daquele em que a sua shell está por acaso. Os dois comandos abaixo respondem a perguntas diferentes, e a diferença aparece quando um anfitrião vê uma interface que um contentor não vê. Execute-os pela ordem indicada, porque o segundo só faz sentido depois de saber se a ligação existe.

ip -details link show dev tun1
ip tuntap show

O primeiro comando imprime a ligação tal como o kernel a vê, incluindo sinalizadores e tipo de interface, e é assim que confirma que este é o dispositivo que pretendia. O segundo lista entradas tun/tap persistentes, que existem sem que nenhum processo as detenha. Uma interface à espera do proprietário previsto é uma situação diferente de um túnel vivo anexado a outra VPN, e só o segundo explica porque a sua própria anexação falha. Encontre o processo que detém o dispositivo antes de mudar seja o que for, porque uma entrada persistente e uma interface ocupada têm correções diferentes.

O suporte a múltiplas filas é um arranjo específico de controlador com requisitos próprios, não uma autorização para processos sem relação partilharem uma interface. A sessão viva de outro proprietário é um problema de coordenação, e nenhuma edição de perfil o resolve.

Dois tipos de persistência

A persistência do kernel e persist-tun descrevem tempos de vida fáceis de confundir e caros de trocar. Um dispositivo persistente existe independentemente de qualquer processo, por isso sobrevive a uma paragem e pode ser reutilizado no arranque seguinte. O persist-tun conserva os recursos ao longo de reinícios suaves suportados dentro de um único processo OpenVPN, um horizonte muito mais curto. Nenhum dos dois promete que parar o serviço deixe rotas e endereços no sítio, e uma interface que permanece visível não é prova de uma sessão cifrada a funcionar.

Confirme também o backend, porque uma interface pré-criada não diz nada sobre que implementação a vai abrir. As compilações comunitárias que trazem o caminho de dados direto tentarão usá-la, a menos que o desenho diga o contrário. Onde a versão suporta o interruptor, o disable-dco seleciona em vez disso o caminho em espaço de utilizador; motores mais antigos e outros clientes não têm essa diretiva, por isso mantenha a condição de versão ao lado da opção em vez de assumir que se aplica.

O que quebra quando só se testa o arranque

Um acordo de propriedade pode passar o primeiro teste e falhar no último, o que torna o arranque uma verificação fraca por si só. Observe, em vez disso, duas transições: um reinício suave e uma paragem completa seguida de um arranque.

systemctl status openvpn-client@lab
ip -details link show dev tun1

O arranque é o caso fácil: a unidade sobe, a ligação aparece e a saída de estado nomeia o perfil carregado. A anexação é o momento em que o daemon abre o dispositivo, por isso execute a verificação da ligação depois de a unidade reportar que está ativa, e não antes. Se a ligação existir enquanto o estado ainda está a ativar, está a olhar para um dispositivo persistente ao qual ninguém se anexou ainda, e não para um túnel a funcionar. Faça passar tráfego real pela ligação antes de continuar, porque uma interface anexada sem rota utilizável continua a ser uma falha.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Um reinício suave deve deixar a sessão utilizável e os recursos intactos, e é esse o trabalho que o persist-tun faz. A paragem completa é onde um gestor externo se revela: se a ligação ou os seus endereços sobreviverem à paragem, alguém mais é dono deles, e isso é ou o estado que documentou ou o erro que acabou de encontrar. Registe as duas observações ao lado do perfil, para que a próxima alteração comece por evidências e não por um diagrama.