TUN/TAP: argumento inválido — incompatibilidade do enquadramento do OpenVPN

O cliente autentica-se, o log diz conectado e nenhum pacote atravessa o túnel. O servidor termina a tentativa com write to TUN/TAP: Invalid argument (code=22), que parece uma falha do driver e normalmente não é. Em routers e pequenos servidores Linux, essa linha costuma significar que os dois pares não concordam sobre como os pacotes de dados são enquadrados, por isso o kernel rejeita o buffer desencriptado que lhe foi entregue. O encaminhamento ainda não foi testado nesse ponto.

Uma tabela de rotas correta e um acordo de enquadramento quebrado parecem iguais do lado do cliente: conectado, e nada funciona.

O túnel sobe e nada o atravessa

Os erros de escrita no dispositivo do túnel ocorrem após a desencriptação e antes do encaminhamento. O daemon desencripta um pacote, entrega-o à interface, e a interface rejeita-o porque o buffer não corresponde ao que esse dispositivo espera. O código 22 é a resposta genérica de argumento inválido, por isso a informação útil é a camada: este é o caminho de dados e não o handshake. Se o tráfego funcionava ontem e parou hoje sem qualquer alteração de configuração, suspeite de uma atualização de pacote ou firmware que moveu um valor predefinido antes de suspeitar da rede.

Leia o log em torno da configuração do canal de dados em vez do primeiro erro. O modo de compressão negociado, o tipo dev e as opções enviadas aparecem todos com maior verbosidade, e dizem-lhe qual das três incompatibilidades tem.

A compressão é enquadramento, não largura de banda

Com a compressão ativada, cada pacote de dados transporta um cabeçalho que descreve como foi codificado, e as duas pontas têm de concordar sobre esse cabeçalho. Um servidor que ainda transporta comp-lzo de uma configuração de exemplo antiga, emparelhado com um cliente sem linha de compressão, produz exatamente este erro: o servidor espera um cabeçalho que o cliente nunca escreveu. Misturar comp-lzo com compress lz4-v2 falha da mesma forma, porque os algoritmos diferem embora ambos se chamem compressão. A opção é um contrato de enquadramento e não uma funcionalidade de largura de banda nos links modernos.

O comportamento das versões acrescenta uma armadilha. A série 2.5 começou a emitir avisos de obsolescência para as opções de compressão, e 2.6 traça uma linha entre recusar pacotes comprimidos e simplesmente deixar os dados sem compressão. Uma atualização de firmware do router pode, portanto, alterar o acordo efetivo sem que ninguém edite o túnel.

Alinhe as duas pontas ou remova das duas

Enumere cada diretiva de compressão: o ficheiro do servidor, quaisquer opções enviadas, os ficheiros específicos do cliente e o perfil do cliente. comp-lzo no servidor precisa da mesma palavra no cliente, e adaptive é o valor predefinido herdado que a opção nua costuma significar em compilações mais antigas. O interruptor da GUI do router rotulado LZO ou compressão escreve essa mesma opção, por isso defina-o para corresponder em vez de misturar algoritmos. Não assuma que um nome de aspeto semelhante seja compatível.

Se a compressão não for desejada, remova-a deliberadamente das duas pontas. allow-compression no no servidor recusa pacotes comprimidos, mas só depois de os clientes terem deixado de os oferecer; aplicá-lo enquanto um cliente ainda envia compressão recria a incompatibilidade na direção oposta.

Verifique o envio e o tipo de dispositivo

Um servidor pode enviar uma diretiva de compressão a partir do seu ficheiro principal ou de um ficheiro específico do cliente, e um cliente pode descartar as opções enviadas com pull-filter. Ligue um cliente com verbosidade 4, leia o que o servidor anunciou face ao que o cliente aceitou, e depois confirme que nenhum filtro o removeu. Se ambos os lados agora concordam e o erro persiste, veja o tipo de dispositivo: dev tap numa ponta e dev tun na outra não podem trocar frames, e o kernel recusa a escrita da mesma forma.

Uma implementação de TAP com bridge precisa de uma bridge real no servidor, não apenas de um nome de dispositivo diferente. Renomear uma interface para tap0 sem a adicionar a uma bridge produz um dispositivo que aceita a escrita e não vai a lado nenhum.

Depois verifique com um cliente e um destino: faça ping ao endereço do túnel do servidor, depois a um host na sua LAN. O primeiro prova o canal de dados e o segundo o reencaminhamento.