Autoriser TCP 873 sur l’interface du tunnel ne fait pas passer rsync par OpenVPN, et cela ne fait pas non plus accepter le module à l’extrémité distante. Un tunnel transporte une connexion interne dont les règles de protocole et de destination restent exactement ce qu’elles étaient. La première question n’est donc pas quel port ouvrir, mais quel type de connexion rsync établit. Tout ce qui suit suppose que le tunnel est déjà monté et que seul le service interne fait encore doute.

Déterminez quelle connexion rsync établit réellement

L’argument distant de la commande répond généralement à cette question avant toute modification du pare-feu. Un double deux-points ou un schéma d’URL sélectionne le démon, tandis qu’un seul deux-points après un nom d’hôte sélectionne un shell distant. Lisez l’argument que vous exécutez réellement, pas celui de l’exemple de la documentation.

Une option explicite de shell distant peut de nouveau changer la réponse, car elle indique à rsync quel programme lancer pour le transport. Lisez toute la ligne de commande, y compris les scripts d’enveloppe hérités, pas seulement la partie hôte.

Remote argumentWhat it opens
rsync://vault.corp.internal/archive/rsync daemon, normally TCP 873
vault.corp.internal::archive/rsync daemon, normally TCP 873
[email protected]:/srv/archive/Remote shell, normally SSH on its configured port

Mode démon : adresse de liaison, module et port

Dans la syntaxe du démon, le segment de chemin nomme un module configuré, pas un répertoire sur le disque. Le mot de passe d’un module n’est vérifié qu’une fois la connexion acceptée, et le module peut en outre être en lecture seule ou masqué du listage. Cet ordre compte quand vous lisez une erreur, car une connexion refusée et un module rejeté sont des échecs à deux étapes différentes. Aucun des deux messages ne vous dit quoi que ce soit sur le tunnel lui-même.

Un démon autonome peut être épinglé à l’adresse du tunnel dans son fichier de configuration, ce qui le tient à l’écart de l’interface publique sans aucune règle de pare-feu. La valeur doit exister au moment où le démon se lie, et un écouteur activé par socket ou géré par inetd peut l’ignorer complètement.

address = 10.44.0.1
port = 873
[archive]
    path = /srv/archive
    read only = yes

Testez ensuite contre l’adresse privée plutôt que le nom public. Un nom d’hôte public se résout en une adresse WAN et emprunte un chemin différent, même quand une seule machine répond sur les deux.

rsync --list-only rsync://10.44.0.1/archive/

Mode shell distant : SSH transporte le transfert

Avec un seul deux-points, rsync lance un programme de shell distant et parle son protocole sur ce canal, si bien que le seul service joignable est SSH sur le port qu’écoute le serveur. Le démon rsync ne s’exécute jamais, le port 873 est sans objet et la décision d’accès devient une décision de compte SSH. Le chemin distant est alors un vrai chemin de système de fichiers interprété par le shell en face. C’est pourquoi une modification de pare-feu visant 873 ne fait absolument rien pour ce mode.

Ce modèle a besoin d’un compte autorisé et de la vérification de la clé d’hôte, et il hérite de la politique d’authentification propre à SSH. C’est souvent le meilleur choix quand le transfert doit traverser un réseau non fiable, car le chiffrement appartient à un protocole conçu pour cela. Un démon avec invite de mot de passe n’est pas la même chose.

N’ouvrez que le chemin que vous avez choisi

Une fois le mode fixé, autorisez le seul service interne sur la seule interface qui porte le tunnel. Limitez la règle par interface, pool source et adresse de destination afin qu’un changement ultérieur de refus par défaut ne puisse pas l’élargir silencieusement. Vérifiez ensuite l’ordre des règles, car une règle permissive placée plus haut dans la chaîne rend l’étroite purement décorative.

Si le démon tourne sur une machine derrière la passerelle VPN plutôt que sur la passerelle elle-même, la passerelle a aussi besoin d’un chemin de transfert et la cible de sa propre autorisation et de sa route de retour. Ouvrir le port sur la seule passerelle produit une connexion qui est acceptée puis ne mène nulle part.

Vérifiez depuis le client avec le même mode et la même destination que ceux que vous comptez utiliser en production. Un listage réussi prouve ensemble l’écouteur, la route et la règle ; un délai d’attente désigne le chemin, et un refus désigne l’écouteur.

ufw allow in on tun0 from 10.44.0.0/24 to 10.44.0.1 port 873 proto tcp
ss -ltnp | grep 873

Articles similaires