Laisser un client OpenVPN se connecter en SSH à un autre sans ouvrir le pool

Un client doit atteindre le service SSH d’un autre client, et le reste du pool doit rester aussi isolé qu’aujourd’hui. L’interrupteur tentant est client-to-client, qui active l’accès entre pairs pour tout le monde d’un coup et confie la décision à OpenVPN plutôt qu’au noyau. Une réponse plus étroite laisse cet interrupteur désactivé et laisse le routage et le pare-feu du serveur porter exactement un flux.

Le mécanisme compte plus que le texte de la règle, car les deux approches placent le paquet à des endroits différents. Savoir laquelle vous avez choisie explique à la fois la règle qui semble ne rien faire et le pair qui se connecte sans elle.

Où client-to-client déplace le paquet

Avec client-to-client activé, le serveur relaie un paquet de pair en interne au lieu de le renvoyer par le périphérique tunnel, si bien que le paquet n’atteint jamais le chemin de transmission du noyau. C’est pratique, et cela signifie aussi que votre pare-feu ne voit jamais le flux qu’il est censé contrôler. Laissez l’option désactivée et le serveur route le paquet vers l’extérieur par la même interface, ce qui le place devant netfilter. Même interface en entrée, même interface en sortie, et la chaîne FORWARD a la voix.

L’échange est explicite : vous gagnez un point de politique et vous prenez en charge le routage et la transmission que le raccourci faisait pour vous. Ce travail est mince pour un seul flux et grandit avec chaque exception que vous ajoutez. Comptez les exceptions maintenant, car c’est dans le jeu de règles que vit réellement la politique entre pairs.

Le chemin qu’emprunte réellement un paquet de pair

Supposez un service Linux Community OpenVPN 2.6, un traitement TUN en espace utilisateur plutôt que DCO, une topologie de sous-réseau, tun0 et un pool de 10.44.0.0/24 avec le client A à 10.44.0.21 et le client B à 10.44.0.37. En topologie de sous-réseau, l’adresse et le masque reçus par A couvrent déjà le pool, donc A envoie le paquet au périphérique tunnel sans route poussée supplémentaire. Vérifiez la route effective sur A au lieu d’en supposer une.

Sur le serveur, le paquet arrive adressé à B, qui n’est pas une adresse locale, il est donc transmis. Le transfert IPv4 doit être activé pour que cela se produise, et la recherche de route doit renvoyer le paquet par tun0. Le pare-feu voit donc un flux transmis avec la même interface des deux côtés, et c’est le détail que la plupart des jeux de règles manquent. Aucune traduction de source n’est nécessaire ici, et c’est en gardant l’adresse de A intacte que B peut appliquer sa propre règle fondée sur la source.

Deux règles sur le serveur, dans cet ordre

Trois règles portent toute l’autorisation : la transmission, l’exception de paire et un rejet par défaut pour la paire tunnel. La règle d’acceptation nomme la paire et le service, donc l’autorisation survit à un pool qui grandit. Placez-la avant tout refus global du trafic tunnel à tunnel, car la première correspondance gagne :

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Ces commandes sont illustratives et appartiennent au mécanisme que votre hôte utilise pour conserver les règles ; une insertion à chaud disparaît au prochain démarrage. C’est la règle avec état qui permet aux réponses de B et à la poignée de main TCP de revenir sans une seconde acceptation en miroir.

Vérifiez les compteurs ensuite, pas la liste des règles, car une règle qui ne correspond jamais est identique à une règle qui fonctionne. Si les compteurs restent à zéro, le paquet ne suit pas le chemin que vous croyez.

Ce que B doit encore autoriser

B fait tourner le service SSH, donc B décide si quelque chose écoute sur l’adresse du tunnel et si son propre pare-feu d’hôte accepte la source. Une autorisation réseau sur le serveur n’est pas une permission pour un compte de B, et la vérification de la clé d’hôte comme l’authentification utilisateur s’appliquent toujours comme depuis n’importe où ailleurs.

Testez d’abord le cas positif : une nouvelle connexion SSH de A vers l’adresse tunnel de B, acceptée avec la clé d’hôte attendue. Testez ensuite un autre pair ou un autre port et confirmez qu’il est refusé, car une autorisation qui permet tout en silence est indiscernable d’une qui fonctionne jusqu’au moment où cela compte. Les deux moitiés de ce test sont nécessaires, et la seconde est celle que les gens sautent.

Notez les adresses attribuées, les routes effectives sur les deux clients et les règles exactes sur le serveur et sur B. Un ping réussi vers la passerelle ou un port ouvert sur le serveur ne prouve rien de tout cela, car les deux peuvent être vrais alors que la transmission entre pairs est encore bloquée. Écrivez ces chiffres pendant que le tunnel est monté, car l’adresse qu’un client reçoit après une reconnexion peut être différente.