« Tunnels ethernet avec OpenSSH » : différence entre les versions
mAucun résumé des modifications |
mAucun résumé des modifications |
||
| Ligne 16 : | Ligne 16 : | ||
== Sur le serveur == | == Sur le serveur == | ||
La | La première chose à faire est de dire à openssh d'autoriser les tunnels, en rajoutant cette directive : | ||
<code>PermitTunnel yes</code> | <code>PermitTunnel yes</code> | ||
| Ligne 28 : | Ligne 28 : | ||
Une autre solution est de donner les permissions en lecture écriture à un groupe particulier | Une autre solution est de donner les permissions en lecture écriture à un groupe particulier | ||
sur /dev/tun, ce qui est bien plus simple et | sur /dev/tun, ce qui est bien plus simple et sûr. | ||
<code>chmod :mongroupe /dev/tun</code> | <code>chmod :mongroupe /dev/tun</code> | ||
| Ligne 47 : | Ligne 47 : | ||
== Sur le client == | == Sur le client == | ||
Il faut simplement les droits sur /dev/tun, donc soit tourner en root, ou avoir la permission | |||
d'écrire sur /dev/tun, comme plus haut, puis faire ( sisay etant le serveur ) : | d'écrire sur /dev/tun, comme plus haut, puis faire ( sisay etant le serveur ) : | ||
| Ligne 66 : | Ligne 66 : | ||
<code>ping 10.0.0.1</code> | <code>ping 10.0.0.1</code> | ||
Le reste, c'est de la configuration | Le reste, c'est de la configuration normale pour les interfaces. Vous pouvez rajouter des routes, un firewall, n'importe quoi. | ||
Néanmoins, il faut savoir que les connexions tcp par dessus tcp ( comme c'est le cas avec ssh ) sont déconseillés, de par la nature de tcp ( http://docs.mandragor.org/files/Misc/GLFM/lm31/TCP_over_TCP_mauvaise_iD.html ). | Néanmoins, il faut savoir que les connexions tcp par dessus tcp ( comme c'est le cas avec ssh ) sont déconseillés, de par la nature de tcp ( http://docs.mandragor.org/files/Misc/GLFM/lm31/TCP_over_TCP_mauvaise_iD.html ). | ||
Version du 12 février 2006 à 13:40
Depuis la version 4.3 de Openssh, l'option pour faire des tunnels ip a été ajouté, mais la doc sur internet est plutot rare sur le sujet.
Avant tout, il faut vérifier la version d'openssh sur le serveur et le client.
~ $ rpm -q openssh
openssh-4.3p1-3mdk
~ $ ssh sisay rpm -q openssh
openssh-4.3p1-0.1.20060mdk
L'exemple ici a été fait à partir de 2 mandriva, mais ça doit marcher sans modification sur un autre linux ou *bsd.
Tout d'abord, il faut les droits root sur les 2 machines. En effet, il y a quelques opérations à faire, aussi bien au niveau de la configuration que du réseau.
Sur le serveur
La première chose à faire est de dire à openssh d'autoriser les tunnels, en rajoutant cette directive :
PermitTunnel yes
dans /etc/ssh/sshd_config.
Il faut aussi retirer la séparation des priviléges, ou jouer sur les permissions de /dev/tun . J'ai pris la facilité pour le moment, j'ai rajouté
UsePrivilegeSeparation no
Une autre solution est de donner les permissions en lecture écriture à un groupe particulier sur /dev/tun, ce qui est bien plus simple et sûr.
chmod :mongroupe /dev/tun
et bien sur, être dans le groupe en question.
Il faut ensuite charger le module tun :
modprobe tun
et le rajouter dans /etc/modprobe.preload
echo tun >> /etc/modprobe.preload
pour le charger au prochain démarrage.
Sur le client
Il faut simplement les droits sur /dev/tun, donc soit tourner en root, ou avoir la permission d'écrire sur /dev/tun, comme plus haut, puis faire ( sisay etant le serveur ) :
ssh -w any:any sisay
Vous pouvez jeter une oeil sur les options -f et -N pour ne pas lancer de shell sur la machine distante. Et bien sur, les options habituels marchent encore ( clé, tunnel, master/slave ).
Puis, en root, vous pourrez changer l'ip de la nouvelle interface tun0 sur le serveur
ifconfig tun0 10.0.0.1
et faire pareil sur le client :
ifconfig tun0 10.0.0.2
Et finalement, vous pouvez maintenant tester le ping depuis le client :
ping 10.0.0.1
Le reste, c'est de la configuration normale pour les interfaces. Vous pouvez rajouter des routes, un firewall, n'importe quoi.
Néanmoins, il faut savoir que les connexions tcp par dessus tcp ( comme c'est le cas avec ssh ) sont déconseillés, de par la nature de tcp ( http://docs.mandragor.org/files/Misc/GLFM/lm31/TCP_over_TCP_mauvaise_iD.html ).