Salut,
si tu n'as pas du tout le controle sur ton serveur unix et qu'il n'accepte que les connexions telnet depuis 0.1 et 0.2,
la solution serait:
d'ouvrir un vpn sur 0.2
d'ouvrir une session telnet sur 0.2 (serveur telnet activé)
depuis cette session telnet , ouvrir, comme en local une session telnet sur 0.99
le vpn passe par la fbx, donc tu n'as pas à mapper le port 23 dessus: le telnet est encapsulé dans le vpn pptp.
du coté vpn client (chez toi), tu n'as rien de particulier à faire.
tu dois lancer un telnet 192.168.0.2 pas 71 .....
et ... Voili Voilou Voila !

Tu dois ouvrir le serveur telnet sur 0.2 pour lancer une commande telnet (client) dessus comme d'habitude.
telnet permet de faire des bonds comme ça d'une machine à l'autre.
Je ne connais pas hamachi et je ne vois pas ce que passer par un proxy extérieur pourrait apporter dans ton cas.
tu ne pourras pas te connecter directement en telnet depuis chez toi pour cause de filtrage des adresses ip sur ta machine unix. et ... Voili Voilou Voila !

Bonjour à vous,

En cherchant tout autre chose, je tombe sur ce post avec le sourire... sourire ? pourquoi ?

Parce que j'ai galeré pendant des jours et des jours sans trouver de réponses pour un problème similaire (pas exactement le même mais qui s'en approche beaucoup).

Mon but à moi était d'émuler un terminal sur une machine SCO UNIX Open Server 5.0X distante au travers d'un lien sécurisé. Je précise que dans mon cas j'avais un probleme supplémentaire : pas de carte réseau sur le SCO donc pas de LAN et les terminaux de l'entreprise se connectent donc par le réseau RS-232 dit "série" (oui je sais ça sent les photos en noir et blanc....).

Ma solution simple mais efficace, s'articule autour d'un petit serv Linux (monté sur Ubuntu Hardy Heron pour plus de facilité). Sur celui-ci j'ai installé le serveur OpenVPN pour sécuriser la communication en SSL (choix logique du protocole SSL quand on utilise OpenVPN) et rediriger le flux telnet vers les ports séries de la machine Linux connectés par câbles série au Serveur SCO. Enfin sur la freebox (ou autre), il suffit de rediriger le port du serveur OpenVPN vers l'IP de la machine Linux l'hébergeant.Ainsi j'ai pu avoir accès à mon serveur SCO depuis chez moi et de façon très très sécurisée (car SSL et bien plus robuste que tout autre protocole utilisé en VPN mais certes moins performant que d'autre).

Comme je l'ai dit, mon problème s'approchait pas mal de celui-ci mais n'était pas le même. (j'ai sauté volontairement le passage de la conversion du réseau RS-232 (série) vers ETHERNET pour l'émulation de terminal).*

Ici je dirais que c'est plus simple : Une fois le VPN "posé" sur la machine Linux (ou autre mais c plus simple sous linux) il suffira de router le port 23 de telnet (ou SSH, ou ce qu'on veut !!!) vers le serveur SCO. (les commandes pour faire du routage sous linux ressembles à : add route 10.8.XXX.XXX:PORT 192.XXX.XXX.XXX:PORT bla bla bla il y a tellement de doc sur le net que je connais même pas la commande entière :p). A noter que le routage peut "relier" plusieurs réseaux en passant par plusieurs Interfaces réseau différentes (Cartes réseaux, PCs, Routeurs etc.)

Bon biensûr, il faut ajouter une machine linux (un PIII 500Mhz 256Mo étant déjà trop puissant pour cette application :p) ou l'installer en multiboot sur la machine XP 0.2 (ce qui suffirait largement si il n'y a personne sur le poste XP 0.2 durant l'accès de chez toi). Si vraiment il ne faut rien changer ni aux machines ni aux systèmes alors c'est toujours possible sous XP avec OpenVPN mais le routage sera plus complexe. Il existe néanmoins des outils Microsoft ou autre pour faire du routage sous Windows (utiliser les outils des plateformes Windows Server par exemple).

En tous cas, je ne suis pas expert Linux (bon je suis informaticien kumême :p) et pourtant j'ai réussi à mettre un solution similaire en place.

Je ne dit pas que cette solution est "miracle" mais si elle pouvait au moins éclairer tes recherches je n'en serais que ravis.

Bon courage.

*PS: Un terminal RS-232 sur le LAN ? Ou comment faire passer un réseau RS-232 série sur le LAN en utilisant telnet

Tout à fait !!!!
Je n'ai pas pris le temps d'aller vérifier la syntaxe des commandes et me suis donc emmêlé les câbles réseaux :-p

Plates et grandes excuses donc !

Cela dit c'était plus pour mettre sur la voie sans trop de conviction (vu la date du dernier message précédant le mien).

Mais tout ça m'a donné envie d'améliorer mon système et maintenant ma configuration ressemble beaucoup plus à celle présentée ici. J'ai donc ouvert le Serveur SCO et j'ai foutu une bonne vieille carte Rézal et me voilà parti dans des sessions telnet distantes.

Je vais donc donner la configuration nécessaire pour une connexion telnet à distance à travers un VPN SSL (OpenVPN) installé sur un serveur Ubuntu (sachant que le principe est strictement identique sur XP seules les correspondances entre les syntaxes de commandes seront à rechercher ;-) ) :

1 - Monter le serveur OpenVPN de façon classique et le rendre fonctionnel à travers le réseau mis en place.
Le but pour l'instant est de faire communiquer simplement le Serveur Open VPN (0.2) et le Client à domicile (1.2).
Sur la Freebox de l'entreprise, on n'oubliera pas de forwarder le port (donc faire de la NAT :p) du serveur OpenVPN (par défaut UDP 1194) vers son adresse IP (0.2). Et c'est la seule chose à faire sur la FreeBox de l'entreprise !
La mise en place est un peut longue mais beaucoup de How-To sont à disposition à travers le net pour arriver à ses fins.

ex 1 : How-To excellent si on utilise Ubuntu
ex 2 : How-To pas trop complexe traitant Linux et Windows
ex 3 : How-To un peut plus barbare :-p

2 - On va rajouter (ou plutôt dé commenter) une ligne dans la configuration du serveur OpenVPN. On aurait pu le faire avant pendant l'installation mais il est plus simple de tester le serveur avec une configuration classique, juste pour voir si ça marche et ensuite aller plus loin.

Donc il faut ajouter : push "route 192.168.0.0 255.255.255.0"

Cette ligne indique au client du VPN (donc 1.2 dans ce cas) que le réseau 192.168.0.0/24 peut-être accessible à travers le VPN. Voilà pour la configuration du serveur OpenVPN. Il n'y a rien à faire sur le client à domicile vu que la route est "poussée" (push) par le serveur VPN vers le client au moment de la connexion.

3 - La ça se complique un peut car c'est cette partie qu'il faudra "traduire dans le monde Windows".
En effet, pour que le serveur OpenVPN puisse faire le lien entre les 2 réseaux (10.8.0.0 et 192.168.0.0) il faut pouvoir forwarder les trames entre les 2 interfaces. Ainsi, pour simplifier, les trames envoyées sur une interface seront transférées à l'autre et inversement.

Sur Linux dans un terminal en Root/SuperUtilisateur :

sysctl -w net.ipv4.ip_forward=1

ou encore :

echo 1 > /proc/sys/net/ipv4/ip_forward

Sous Ubuntu on rajoute "sudo" devant pour prendre les droits Root/SuperUtilisateur si besoin est.

Pour que cette option ne soit pas perdue au redémarrage, il convient d'ajouter (ou modifier) une ligne dans le fichier /etc/sysctl.conf :

net.ipv4.ip_forward=1

Attention cependant à aussi activer cette option pour l'interface TUN/TAP créée par OpenVPN à l'installation (normalement la commande donnée ci-dessus active l' ip_forward pour toutes les interfaces).
On pourra vérifier cella en tappant :

cat /proc/sys/net/ipv4/conf/tun0/forwarding (pour vérifier l'interface TUN)
cat /proc/sys/net/ipv4/conf/eth0/forwarding (pour vérifier l'interface ETHERNET)
cat /proc/sys/net/ipv4/conf/all/forwarding (pour vérifer toute les interface)
cat /proc/sys/net/ipv4/ip_forward (pour vérifer l'Ip forwarding en général)

Voilà coté serveur (0.2).

Bon allé chui sympa, je viens de tomber sur un article de Microsoft pour activer l'IP Forwarding sur XP :p .

Donc sur XP :

- Démarrer l'Éditeur du Registre (Regedit.exe).

- Dans l’Éditeur du Registre, localiser la clé de Registre :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

- Définir la valeur de registre suivante :

Nom de la valeur : IPEnableRouter
Type de la valeur : REG_DWORD
Données de la valeur : 1

Une valeur égale à 1 active l'Ip forwarding pour toutes les connexions réseau installées et utilisées par la machine.

- Quitter l'éditeur.

- Redémarrer (merci Windows :p)

Ouf !!! Ça vous à plu ? ... Alors on continue !!! :)

4 - A ce stade de la configuration, on est capable d'atteindre le serveur SCO à travers le VPN mais celui-ci ne pourra pas nous répondre !!! En effet quand le client du VPN envoi une trame sur le Serveur SCO celui-ci la reçoit car la route pour l'atteindre est connue du client (on se rappelle avoir "poussé" la route dans la config OpenVPN). De plus celle-ci est forwardée par le Serveur hébergeant OpenVPN (0.2).
Mais le serveur SCO lui, ne connait pas la route pour atteindre le client distant et ne peut donc pas lui répondre !!!
On va donc ajouter une route statique sur le serveur SCO (0.99) pour lui "apprendre" à renvoyer sa réponse au client.

Sur SCO Release 5 (pour les Releases supérieures, je ne peux affirmer que les commandes soient les mêmes sachant que "Route" a changé de syntaxe dans le temps et selon le système) :

Dans un terminal en Root/SuperUtilisateur, à la dièse, tapper :

route add -net 10.8.0.0 192.168.0.2 255.255.255.0
(On voit bien ici la syntaxe archaïque avec la passerelle avant le masque).

Bien sûr, si le serveur SCO redémarre, la route est perdue... On va donc l'écrire dans un fichier prévu à cet effet mais la encore, il y a des différences entre les versions de SCO et même des mélanges entre versions (j'avoue m'être bien embêté pour prendre une décision à ce sujet et comme le serveur est en production je n'ai pas pu le redémarrer pour vérifier si cela fonctionne).

Pour vérifier la version du système, on pourra taper la commande : uname -v

Donc ce qui est soit-disant donné officiellement (toujours dans un terminal en Root/SuperUtilisateur) :

- Release 5.0.4 et 5.0.5 : Dans le fichier /usr/internet/etc/sco_ip/routes on ajoute la route en question :
route add -net 10.8.0.0 192.168.0.2 255.255.255.0

- Release 5.0.6 : c'est dans ce fichier que l'on doit l'ajouter /etc/default/tcp (Je n'ai pas vérifié ayant une version 5.0.5 donc a prendre avec des pincettes).

- Pour les Release avant 5.0.4 un tips est donné mais la aussi à vérifier : il faut créer le fichier /etc/rc2.d/S99route et y ajouter la route en question. Ne pas oublier de donner les droits d'exécution sur le fichier (chmod 755 /etc/rc2.d/S99route).

Personnellement j'ai une Release 5.0.5 et j'ai quand même dû créer le dossier /usr/internet/etc/sco_ip/ et le fichier /usr/internet/etc/sco_ip/routes car il n'était pas présent sur le système (d'où mon léger doute sur la tenue de la route (sans jeux de mots) après redémarrage).

Et voilà c'est fini !

Juste pour Info, si jamais il faut pouvoir accéder à une machine Windows située derrière le VPN voila les commandes (ATTENTION : c'est juste donné pour info car dans la config actuelle nous n'en avons pas besoin !!!).

Ajouter une route sous Windows est assez similaire à Linux :

- Démarrer -> Executer
- Taper : cmd puis appuyer sur la touche Entrée
- A l'invite de commande taper : route add 10.8.0.0 mask 255.255.255.0 192.168.0.2
- Taper Exit.

Pour vérifier, la commande suivante, permet d’avoir la liste des routes :
C:\>route print


Bon cette fois ci c'est vraiment fini :-p

Cette solution est donc fonctionnelle (testée dans mon entreprise sans problème) et de plus elle est adaptable aux systèmes Linux et Windows.

Bien sûr, je ne suis pas dieu et je tire tout ça de mon enseignement et de documentations tirées sur le net. C'est pour cela que je recommande toujours de vérifier la faisabilité avant de se lancer tête baissée (surtout si les connaissance UNIX sont limitées). Je serais désolé de voir un réseau tomber à cause d'une mauvaise utilisation de ce qui est écrit ici mais de toute évidence, je ne pourrais en être tenu pour responsable.

Prudence est mère de sureté !

Bonne lecture, bonne continuation et surtout merci de m'avoir donné l'envie d'aller plus loin et améliorer le système de mon entreprise qui se voit dotée d'un nouveau souffle à présent.

Bye :-)

Bonjour à tous !!!!

Je viens me corriger car j'ai pu effectuer un redémarrage de notre serveur SCO et effectivement la route incluse dans mon fichier /usr/internet/etc/sco_ip/routes et bien perdue !!!

Pourquoi ? Tout simplement car ce fichier est lu par un script au démarrage de la machine.
Ce script est dans le fichier : /etc/rc2.d/S90iproute

Les deux premières lignes de ce script indique dans quel fichier aller chercher les routes à ajouter/enlever. C'est donc dans ce fichier qu'il faudra aller écrire les routes, mais pas n'importe comment !!!!

En effet après lecture du script on s'aperçoit que le but de celui-ci est de construire des commandes de type :
route add 10.8.XXX.XXX... etc etc avec les informations données dans le fichier contenant les routes.

Je vais prendre l'exemple de la route à ajouter dans le cas présent et la "traduire" pour pouvoir l'ajouter au fichier :

Donc, à la base on a la commande : route add -net 10.8.0.0 192.168.0.2 255.255.255.0

Et pour cette route il faudra écrire dans le fichier : net 10.8.0.0 192.168.0.2 255.255.255.0

Bien sûr on sauvegarde le tout, on oublie pas de vérifier si le fichier en question à les droits pour y accéder (chmod 755 sur le fichier en cas de doute) et c'est fini !!! Car c'est le script qui va faire le boulot pour nous !

En fait le script se charge d'aller chercher la commande /etc/route et y ajoute les arguments/paramètres dont on a besoin (add si on est au démarrage de la machine, -net pour les routes "classiques" quand il voit net dans le fichier, -host pour les routes pour un hôte spécifique quand il voit host dans le fichier... etc.).

Cela ne s'arrête pas là, sinon le script n'aurait pas vraiment d'utilité.

En effet il est aussi capable d'accepter les arguments start ou stop ce qui reviens à :
start -> ajout de l'argument add pour ajouter toutes les routes contenues dans le fichier.
stop -> ajout de l'argument delete pour enlever toutes les routes contenues dans le fichier.

A la manière d'un daemon on pourra donc utiliser start et stop pour ajouter ces routes ou les effacer en un rien de temps !!!

Voilà Voilà, j'espère que je ne me trompe pas ce coup là, car je suis en pleine journée et donc le serveur est en production, je ferais un redémarrage demain pour voir si ça tient le coup mais normalement, il n'y a pas de raisons que ça tienne pas.

Bye all :-)

Salut salut !!!

Juste pour confirmer qu'après redémarrage, la route est toujours valable.

Tout est nickel ! Et fonctionnel !

Bye à tous ;-)