Configuration VPN et Telnet entre deux Lan
rezoagogo
-
brupala Messages postés 115330 Date d'inscription Statut Membre Dernière intervention -
brupala Messages postés 115330 Date d'inscription Statut Membre Dernière intervention -
Serveur UNIX SCO
(192.168.0.99)
|
|
PC n°1(Win)----------Switch ----------- PC n°2 (WinXP Pro)
(192.168.0.1) | (192.168.0.2)
|
Freebox
(192.168.0.200)
DHCP désactivé
Mode routeur activé
Routage du port 23 établi en TCP+UDP vers 192.168.0.2
|
IP Fixe : 70.71.72.73 (exemple bien sur)
|
[Internet]
|
IP Fixe : 212.213.214.215 (exemple)
|
Notebook----------Modem Routeur------------PC n°3 (Win2000 Pro)
192.168.1.3 Bewan 6104W VPN (192.168.1.2)
Wifi "sécurisé" (192.168.1.1)
DHCP désactivé
Bonjour
Nous avons au travail deux postes Windows XP PRO qui nous permettent de nous connecter et de travailler sur le serveur via du TELNET. Notre serveur UNIX héberge des données sensibles (médicales), et notre société informatique refuse d'installer un logiciel (type OpenSSH ou OpenVPN pour UNIX) sur notre serveur. Ne connaissant rien à UNIX (et ne souhaitant pas avoir de litiges avec ma SSII), je cherche donc à établir un VPN entre le PCn°3 de mon domicile et un terminal PCn°2 de mon lieu de travail. Une fois la connection VPN établie entre ces deux postes windows, je désire lancer TELNET 70.71.72.73 pour me connecter sur le serveur (192.168.0.99) via le PC n°2 (192.168.0.2). Le PC n°2 n'est donc pas ma cible, il doit juste de serveur VPN pour pouvoir me connecter via TELNET sur le serveur.
Je souhaite donc établir un VPN entre un poste bien précis de mon réseau domestique (PCn°3) et un poste bien précis du réseau au travail (PC N°2) qui lui même doit relayer mes requêtes sur le serveur, et donc ne pas fusionner les deux réseaux comme s'il s'agissait d'un seul intranet.
Suis-je clair ?
Plusieurs questions :
1/ Est-ce que cette configuration est sécurisée ? Je m'interroge sur la nécessité de monter une deuxième carte réseau sur le PC N°2 et créer un routage sur ce PC N°2 Windows (une sorte d'IPCop). Est-ce qu'un produit comme celui-ci http://www.ldlc.com/fiche/PB00024007.html rendrait mon réseau plus sur mais aussi plus facilement configurable ?
2/ Quel est l'intérêt d'un OpenVPN pour windows sachant que WinXP Pro peut nativement faire office de serveur VPN ? Est-ce pour les autres windows comme je l'imagine ?
3/ Est-ce que le logiciel Hamachi est sur ? Si je comprend bien il crée deux VPN : un qui relie le mon réseau du boulot à leur serveur, et l'autre qui relie mon réseau domestique à leur serveur ; leur serveur faisant le routage.
4/ Lorsque je configure mon PC domestique (Win2000Pro) comme client, j'ignore à quoi sert et comment paramétrer le WINS. C'est quoi un serveur WINS ?
Et enfin des questions encore plus Newbees :
5/ Je souhaite limiter le VPN qu'au port TELNET 23 en ne redirigeant que ce port au niveau de la FreeBox. Cela va t-il fonctionner, ou bien y'a t-il d'autres port qu'il faut obligatoirement ouvrir ?
6/ A la maison, mon modem routeur Bewan6104W gère nativement les VPN, mais sa configuration me semble ardue. Sachant qu'un seul poste de mon réseau domestique doit accéder à un seul poste de mon travail, est-il intéressant (d'un point de vue sécurité) que je cherche à paramètrer le VPN de mon modem routeur ?
7/ Sachant que le serveur UNIX est paramétré pour n'accepter que deux IP (pour des raisons de licences) qui sont 192.168.0.1 et 192.168.0.2, avec quelle adresse va t-il reconnaître mon PC domestique n°3 ?
Merci énormément pour votre aide parce que je galère beaucoup
(192.168.0.99)
|
|
PC n°1(Win)----------Switch ----------- PC n°2 (WinXP Pro)
(192.168.0.1) | (192.168.0.2)
|
Freebox
(192.168.0.200)
DHCP désactivé
Mode routeur activé
Routage du port 23 établi en TCP+UDP vers 192.168.0.2
|
IP Fixe : 70.71.72.73 (exemple bien sur)
|
[Internet]
|
IP Fixe : 212.213.214.215 (exemple)
|
Notebook----------Modem Routeur------------PC n°3 (Win2000 Pro)
192.168.1.3 Bewan 6104W VPN (192.168.1.2)
Wifi "sécurisé" (192.168.1.1)
DHCP désactivé
Bonjour
Nous avons au travail deux postes Windows XP PRO qui nous permettent de nous connecter et de travailler sur le serveur via du TELNET. Notre serveur UNIX héberge des données sensibles (médicales), et notre société informatique refuse d'installer un logiciel (type OpenSSH ou OpenVPN pour UNIX) sur notre serveur. Ne connaissant rien à UNIX (et ne souhaitant pas avoir de litiges avec ma SSII), je cherche donc à établir un VPN entre le PCn°3 de mon domicile et un terminal PCn°2 de mon lieu de travail. Une fois la connection VPN établie entre ces deux postes windows, je désire lancer TELNET 70.71.72.73 pour me connecter sur le serveur (192.168.0.99) via le PC n°2 (192.168.0.2). Le PC n°2 n'est donc pas ma cible, il doit juste de serveur VPN pour pouvoir me connecter via TELNET sur le serveur.
Je souhaite donc établir un VPN entre un poste bien précis de mon réseau domestique (PCn°3) et un poste bien précis du réseau au travail (PC N°2) qui lui même doit relayer mes requêtes sur le serveur, et donc ne pas fusionner les deux réseaux comme s'il s'agissait d'un seul intranet.
Suis-je clair ?
Plusieurs questions :
1/ Est-ce que cette configuration est sécurisée ? Je m'interroge sur la nécessité de monter une deuxième carte réseau sur le PC N°2 et créer un routage sur ce PC N°2 Windows (une sorte d'IPCop). Est-ce qu'un produit comme celui-ci http://www.ldlc.com/fiche/PB00024007.html rendrait mon réseau plus sur mais aussi plus facilement configurable ?
2/ Quel est l'intérêt d'un OpenVPN pour windows sachant que WinXP Pro peut nativement faire office de serveur VPN ? Est-ce pour les autres windows comme je l'imagine ?
3/ Est-ce que le logiciel Hamachi est sur ? Si je comprend bien il crée deux VPN : un qui relie le mon réseau du boulot à leur serveur, et l'autre qui relie mon réseau domestique à leur serveur ; leur serveur faisant le routage.
4/ Lorsque je configure mon PC domestique (Win2000Pro) comme client, j'ignore à quoi sert et comment paramétrer le WINS. C'est quoi un serveur WINS ?
Et enfin des questions encore plus Newbees :
5/ Je souhaite limiter le VPN qu'au port TELNET 23 en ne redirigeant que ce port au niveau de la FreeBox. Cela va t-il fonctionner, ou bien y'a t-il d'autres port qu'il faut obligatoirement ouvrir ?
6/ A la maison, mon modem routeur Bewan6104W gère nativement les VPN, mais sa configuration me semble ardue. Sachant qu'un seul poste de mon réseau domestique doit accéder à un seul poste de mon travail, est-il intéressant (d'un point de vue sécurité) que je cherche à paramètrer le VPN de mon modem routeur ?
7/ Sachant que le serveur UNIX est paramétré pour n'accepter que deux IP (pour des raisons de licences) qui sont 192.168.0.1 et 192.168.0.2, avec quelle adresse va t-il reconnaître mon PC domestique n°3 ?
Merci énormément pour votre aide parce que je galère beaucoup
A voir également:
- Telnet vpn
- Vpn comment ça marche - Guide
- Vpn gratuit - Accueil - Guide VPN
- Hola vpn chrome - Guide
- Nord vpn - Guide
- Netflix vpn - Guide
6 réponses
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 .....
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 .....
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.
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.
OK.
Je vais tenter le coup. Merci pour ton aide.
Je n'étais pas sur que tenet puisse relayer les resquetes car j'ai réalisée une tentative SSH+Telnet qui s'est révélé infructueuse:
J'avais ouvert un serveur SSH sur 0.2
Je me connecté avec Putty en SSG à partir d'un PC du réseau 0.3 sur le poste de 0.2. Je me loggais sans probleme avec le mot de passe, et je me retrouvais avec l'invite de commande MS-DOS du poste 0.2
A ce moment là, je pensais avoir gagné et je lancais un Telnet 192.168.0.99 pour attaquer le serveur, et là rien ne s'est passé (pas de msg d'erreur, ou autres, juste retour à la ligne de commande). Donc SSH ne permet pas de lancer un TELNET sur le poste cible ... c'est bien dommage, ça m'aurait bigrement arrangé.
Je vais tenter le coup. Merci pour ton aide.
Je n'étais pas sur que tenet puisse relayer les resquetes car j'ai réalisée une tentative SSH+Telnet qui s'est révélé infructueuse:
J'avais ouvert un serveur SSH sur 0.2
Je me connecté avec Putty en SSG à partir d'un PC du réseau 0.3 sur le poste de 0.2. Je me loggais sans probleme avec le mot de passe, et je me retrouvais avec l'invite de commande MS-DOS du poste 0.2
A ce moment là, je pensais avoir gagné et je lancais un Telnet 192.168.0.99 pour attaquer le serveur, et là rien ne s'est passé (pas de msg d'erreur, ou autres, juste retour à la ligne de commande). Donc SSH ne permet pas de lancer un TELNET sur le poste cible ... c'est bien dommage, ça m'aurait bigrement arrangé.
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
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
(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 )
en effet car c'est plutôt route add
et les commandes de routage ne permettent pas de manipuler les ports .
Seuls les firewall ou la nat peuvent tenir compte des ports .
en effet car c'est plutôt route add
et les commandes de routage ne permettent pas de manipuler les ports .
Seuls les firewall ou la nat peuvent tenir compte des ports .
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 :-)
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 :-)
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
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 :-)
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 :-)
Un diagramme de mon réseau :
http://perso.club-internet.fr/demouzon/rezo.gif
Juste une précision lorsque tu dis :"d'ouvrir un vpn sur 0.2, d'ouvrir une session telnet sur 0.2 (serveur telnet activé)" c'est le client telnet que je dois ouvrir sur le 0.2 car le serveur telnet lui est sur le serveur UNIX 192.168.0.99. En fait, dans mon VPN, je veux ouvrir une fenêtre MS-DOS sur le 0.2 (command.exe), puis je tape telnet 192.168.0.99. C'est bien cela ?
Sinon, plus j'y réfléchis, plus je pense que pour plus de simplicité, il faut que j'installe un modem routeur VPN à la place de la freebox. C'est certes plus onéreux, mais au moins le serveur VPN sera établi entre le hardware des deux modems routeurs, et je pourrais adresser ainsi directement le serveur UNIX sans passer par un poste windows. A moins que les IP limités à 192.168.0.1 et 192.168.0.2 m'en empèchent (mais si je suis chez moi, un seul poste fonctionnera au travail, donc il restera une ip libre sur l'intranet)
Sinon est-ce que tu connais Hamachi ? penses-tu que ca pourrait fonctionner avec un tel logiciel (au demeurant très simple d'utilisation à priori) ?