TUN/TAP : argument invalide — incompatibilité de tramage OpenVPN

Le client s’authentifie, le journal indique connecté, et aucun paquet ne traverse le tunnel. Le serveur termine la tentative avec write to TUN/TAP: Invalid argument (code=22), ce qui ressemble à un défaut de pilote et ne l’est généralement pas. Sur les routeurs et les petits serveurs Linux, cette ligne signifie le plus souvent que les deux pairs ne s’accordent pas sur la manière de tramer les paquets de données, si bien que le noyau rejette le tampon déchiffré qui lui a été remis. Le routage n’a pas encore été testé à ce stade.

Une table de routage correcte et un accord de tramage rompu se ressemblent côté client : connecté, et rien ne fonctionne.

Le tunnel monte et rien ne le traverse

Les erreurs d’écriture sur l’appareil de tunnel surviennent après le déchiffrement et avant le routage. Le démon déchiffre un paquet, le remet à l’interface, et l’interface le rejette parce que le tampon ne correspond pas à ce que cet appareil attend. Le code 22 est la réponse générique d’argument invalide, donc l’information utile est la couche : il s’agit du chemin de données et non du handshake. Si le trafic fonctionnait hier et s’est arrêté aujourd’hui sans changement de configuration, soupçonnez une mise à jour de paquet ou de firmware qui a déplacé une valeur par défaut avant de soupçonner le réseau.

Lisez le journal autour de la configuration du canal de données plutôt que la première erreur. Le mode de compression négocié, le type dev et les options poussées apparaissent tous à une verbosité plus élevée, et ils vous indiquent laquelle des trois incompatibilités vous avez.

La compression est un tramage, pas une bande passante

Lorsque la compression est activée, chaque paquet de données porte un en-tête décrivant comment il a été encodé, et les deux extrémités doivent s’accorder sur cet en-tête. Un serveur qui porte encore comp-lzo d’une ancienne configuration d’exemple, associé à un client sans ligne de compression, produit exactement cette erreur : le serveur attend un en-tête que le client n’a jamais écrit. Mélanger comp-lzo avec compress lz4-v2 échoue de la même manière, car les algorithmes diffèrent même si les deux s’appellent compression. L’option est un contrat de tramage plutôt qu’une fonction de bande passante sur les liaisons modernes.

Le comportement des versions ajoute un piège. La série 2.5 a commencé à émettre des avertissements d’obsolescence pour les options de compression, et 2.6 trace une ligne entre refuser les paquets compressés et simplement laisser les données non compressées. Une mise à jour du firmware du routeur peut donc modifier l’accord effectif sans que personne n’édite le tunnel.

Alignez les deux extrémités ou retirez-le des deux

Énumérez chaque directive de compression : le fichier du serveur, les éventuelles options poussées, les fichiers spécifiques au client et le profil du client. comp-lzo sur le serveur exige le même mot sur le client, et adaptive est la valeur par défaut héritée que l’option nue signifie généralement sur les anciennes versions. L’interrupteur de l’interface graphique du routeur étiqueté LZO ou compression écrit cette même option, alors réglez-le pour qu’il corresponde au lieu de mélanger les algorithmes. Ne supposez pas qu’un nom d’apparence similaire soit compatible.

Si la compression n’est pas souhaitée, retirez-la délibérément des deux extrémités. allow-compression no sur le serveur refuse les paquets compressés, mais seulement une fois que les clients ont cessé de les proposer ; l’appliquer alors qu’un client pousse encore la compression recrée l’incompatibilité dans l’autre sens.

Vérifiez la poussée et le type d’appareil

Un serveur peut pousser une directive de compression depuis son fichier principal ou depuis un fichier spécifique au client, et un client peut abandonner les options poussées avec pull-filter. Connectez un client à la verbosité 4, lisez ce que le serveur a annoncé par rapport à ce que le client a accepté, puis confirmez qu’aucun filtre ne l’a retiré. Si les deux côtés s’accordent maintenant et que l’erreur persiste, regardez le type d’appareil : dev tap à une extrémité et dev tun à l’autre ne peuvent pas échanger de trames, et le noyau rejette l’écriture de la même manière.

Un déploiement TAP ponté nécessite un véritable pont sur le serveur, pas seulement un nom d’appareil différent. Renommer une interface en tap0 sans l’ajouter à un pont produit un appareil qui accepte l’écriture et ne va nulle part.

Vérifiez ensuite avec un client et une destination : faites un ping vers l’adresse du tunnel du serveur, puis vers un hôte de son LAN. Le premier prouve le canal de données et le second le transfert.