Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
3293 connectés 

 


 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  10  11  12  ..  42  43  44  45  46  47
Auteur Sujet :

Réseau privé virtuel sous Windows - OpenVPN - Tutoriels.

n°278252
nando94
Posté le 09-05-2007 à 20:55:32  profilanswer
 

Reprise du message précédent :
Salut à tous,
 
J'ai quelque problème dans la comprehension des mécanismes. Je crois que j'ai fait tous les sites exista,t abordant le sujet et je ne trouve pas de reponse. Je m'en remet don à vous:
 
- A quoi servent les 3 fichiers .crt .key et ca.crt côté clients. Pourquoi le client a -t- il besoin de ces 3 fichiers ??
- A quel moment le fichier dh1024.pem est il utilisé??
 
- Enfin, est-ce qu'on est censé voir des trames ssl ou udp lorsqu'on utilise un analyseur de trames (ex: ethereal)
 
Merci d'avance à tous ceux qui m'accorderons leur attention.
 
 
Mathieu

mood
Publicité
Posté le 09-05-2007 à 20:55:32  profilanswer
 

n°278261
mugnier102
Posté le 09-05-2007 à 21:58:44  profilanswer
 

nando94 > *Le serveur authentifie le client mais, le client authentifie egalement le serveur, il n'accepte pas de donner des données a un autre client imitant le serveur...
*DH1024 permet d'ajouter de l'aleatoire au generateur de nombre aleatoire dont tout le monde connait le fonctionnement... Donc en gros, si je connais une clé, je ne peut pas trouver les suivantes car il me manque une variable utilisé par le générateur aléatoire
*Les trames SSL sont généralement basé sur TCP... Je ne sais plus trop
ce que tu vois... mais en gros, de memoire... je vois les trames decripté sur l'interface OpenVPN et des Trames crypté sur l'interface modem / routeur.... Il ne te reste plus qu'a essayer !!
 
m3z > As tuouvert le même protocol que celui utiliser dans OpenVPN (proto udp OU proto tcp) ? Sinon, rien d'autre a ouvrir, je confirme !!!
 
fatal83 > On dirait que tu a trouver le BUG !!! Non plus serieux... T'est sous windows 2000 ou XP ? Tu peut essayer la procedure sur un autre PC ? Juste des pistes mais la je ne vois pas...

n°278500
LimDul
Comment ça j'ai tort ?
Posté le 11-05-2007 à 11:53:00  profilanswer
 

[:bibije]  [:bibije]  [:bibije]

n°279380
Waazzaaaa
Posté le 15-05-2007 à 15:28:22  profilanswer
 

J'ai bien suivi le tutorial 5min mais arrivé a la fin je bloque :
 
il est ecrit  
" Pour chaque client, vous devez changer la ligne :
remote xx.xx.xxx.xx 1194  
en mettant l'adresse du serveur et le port.
 
Ainsi que
cert client1.crt
key client1.key
avec le nom correct correspondant au client."
 
C'est cette partie que je pige pas, enin ç partir du Ainsi que....
 
Que fois je faire?


---------------
Core 2 Duo E6600@stock  / P5W DH  / 2x1024 corsair xms2 cas 5  /  Geforce 8800 GTX msi  / Antec Superlan Boy
n°279386
_p1c0_
Posté le 15-05-2007 à 15:49:44  profilanswer
 

Pour chaque client, tu dois spécifier la clé et le certificat qui vont lui permettre de s'authentifier au serveur.


---------------
-_- http://www.scienceshopping.com -_-
n°279398
Waazzaaaa
Posté le 15-05-2007 à 16:35:03  profilanswer
 

Ba c'est juste le fait de refaire un build-key client x c'est tout non?


---------------
Core 2 Duo E6600@stock  / P5W DH  / 2x1024 corsair xms2 cas 5  /  Geforce 8800 GTX msi  / Antec Superlan Boy
n°279563
sotaz
Posté le 16-05-2007 à 09:09:50  profilanswer
 

Bonjour à tous,
J'ai mis en place OpenVPN, et maintenant je cherche à mettre en place un système de mot de passe lors de la connexion d'un client au VPN ??? pour l'instant le seul mot de passe qu'il m'est demandé c'est lorsque l'on veut accéder à une machine via le VPN, hors j'aimerais savoir s'il serait possible de mettre en place un mot de passe autre, et LORS de la connexion ???
Merci pour vos infos et votre aide....!!!  :jap:

n°280264
Neo--Nemes​is
Posté le 20-05-2007 à 11:05:19  profilanswer
 

Bonjour,
 
Tout d'abord je tiens a dire bravo pour ce tuto vraiment utile mais j'ai cepedant un petit problème.
 
Une fois tout configurer je lance openVPN, l'icone devient verte, pas de problème. Du coté client ca s'allume vert aussi mais le problème c'est qu'il est  impossible de se pinger dans les 2 sens.
 
Voici un petit schéma de mon installation :
 
http://jeremie.lancian.free.fr/Images/Sch%e9ma%20installation.jpg
 
Donc comme vous le voyez le PC1 fait serveur VPN et je cherche a faire un réseau virtuel avec le PC3. Le PC2 et juste relié a mon réseau mais il ne sera pas utilisé pour le mise en place d'OpenVPN.
 
La freebox et en mode routeur et branché en ethernet et j'ai bien sûr rediriger le port vers le PC1.
 
L'adresse de ma freebox est 192.168.0.254 les sous réseau sont en 192.168.0.xxx
Mon adresse publique et sous la forme 82.242.xxx.xxx
J'utilise le Port 5000
 
Les firewall laisse passer des 2 coté.
 
Impossible pour moi de faire un pont entre la freebox et VPN a cause de la connexion internet. (si je fait le pont je perd ma connexion)
 
J'ai lu qu'il falait utiliser la fonction push mais je ne trouve pas comment elle fonctionne.
 
Si vous pouviez m'aider svp ca serait sympa ^^
 
@+

n°280321
mugnier102
Posté le 20-05-2007 à 17:48:07  profilanswer
 

Ben... C'est le probleme du pont !
Laisse tomber le pont... et utilise du routage...
 
Basiquement ne fait pas de pont et configure manuellement les IP...

n°280387
Neo--Nemes​is
Posté le 20-05-2007 à 21:51:39  profilanswer
 

Ben expliquer moi comment router mes sous-réseau alors svp parceque j'ai pas compris comment il falait faire.
 
Sur la freebox je ne peut router que sur des IP type 192.168.xxx.xxx je ne peut pas faire autrement.
 
Merci ^^


Message édité par Neo--Nemesis le 20-05-2007 à 21:52:30
mood
Publicité
Posté le 20-05-2007 à 21:51:39  profilanswer
 

n°280400
mugnier102
Posté le 20-05-2007 à 23:59:19  profilanswer
 

BOn... tu a 2 cartes reseau...
Une relié a la freebox... et l'autre relié a travers un VPN, cad un espece de fil magique et invisible. Tu te contente de regler des adresses IP sur cette carte au fil magique. Si t'arrive a pinguer t'a reussi... et on verra si tu a besoin d'un routage plus avancé... (plusieurs poste... ou PC2 depuis le PC3 en passant par le VPN !)
Tu prend donc x,y,z deux chiffre entre 1 et 254
et tu met les IP fixe.
192.168.x.y sur le premier PC masque 255.255.255.0
192.168.x.z sur le deuxieme PC masque identique
Tu ping depuis le deuxieme 127.0.0.1
puis 192.168.x.z
puis pour finir 192.168.x.y !
Si cela marche reste plus qu'a utiliser...
 
Sinon, desactive les par feu ! C'est le seul point bloquant pour le PING si l'icone est verte...
Une copie des log en dernier recours par mail privé... (Clique droit/Voir le log...)

n°280458
nando94
Posté le 21-05-2007 à 13:08:03  profilanswer
 

Ok merci beaucoup.  
 
J'ai tout de même une dernière question. Est ce normal qu'avec l'utilisation du mode routing, j'ai quand même accès, depuis mon ordinateur client VPN, aux serveurs samba situé dans le réseau local. Les broadcast ne sont pas censé passé dans ce mode routing, non ?? Et d'ailleurs, je ne comprend pas comment le client obtient une adresse IP, sachant que les messages dhcp sont des messages de diffusions.
 
Par ailleurs, je me pose la question de savoir qu'est ce qu'on peut faire avec le mode routing si on ne peut même pas accèder aux serveurs de fichiers.
 
Merci de bien vouloir me répondre.
 
C'est trés important.
 
Mathieu
 
PS: Je tiens à préciser que le serveur Samba auquel j'accède est situé sur la serveur OpenVPN.


Message édité par nando94 le 21-05-2007 à 14:19:14
n°280481
Florent42
Posté le 21-05-2007 à 14:27:18  profilanswer
 

Bonjour,
 
J'ai suivi le tres bon tuto pour la configuration de openVPN sur un windows et j ai un petit problème:
 
J ai donc un PC client (PC1) qui se connecte de l'extérieur via un routeur (ou le port 1194 est routé sur le serveur openvpn).
Le serveur openvpn (PC2) est un 2000 server.
 
La connexion se passe correctement entre PC1 et PC2, le voyant de openvpn est vert tout va bien.
Par contre le ping est impossible de chaque coté.
 
J'ai fait le test également sur le LAN mais le problème est identique.
Je précise que les pc en question n'ont aucun firewall...donc logiquement en internet ca devrait marcher...
 
merci d'avance pour votre aide

n°280484
Florent42
Posté le 21-05-2007 à 14:38:12  profilanswer
 

je precise que le LAN est en 192.168.120.x et j ai gardé la config IP de base pour openvpn 10.8.0.x

n°280487
mugnier102
Posté le 21-05-2007 à 14:42:12  profilanswer
 

Florent42 > Tu est en Bridge ou Routed ? (DEV TUN ou DEV TAP)
Tu n'arrive pas a pinger PC2 depuis PC1... Hors PC1 est derriere un routeur... quelle est l'adresse du routeur ?
Que donne un ping du routeur ?
 
Nando94 > Helas... vu la securité toute relative de windows, il semble normale que tu puisse voir le PC Serveur et tout ce qui tourne dessus.
Par contre, il est a priori anormale que tu puisse acceder au partage situé sur une machines differentes. Cela est cependant possible si le serveurs est une edition Serveur de windows auquel cas, le routage est activé par defaut !
 
Sinon, pour le reste precise tes questions et fais suivre tes fichiers de config en prive...

n°280513
Florent42
Posté le 21-05-2007 à 16:52:26  profilanswer
 

je suis en dev tun (dc normalement routed)
le routeur est a ladresse 192.168.120.254...donc le ping ne marche forcément pas étant sur 2 plages différentes

n°280522
mugnier102
Posté le 21-05-2007 à 18:04:53  profilanswer
 

et de l'autre coté ? Cote internet ?
Que donne les log OpenVPN ?
Fais passer ta config en privé...

n°280560
nando94
Posté le 21-05-2007 à 21:01:18  profilanswer
 

Citation :

Nando94 > Helas... vu la securité toute relative de windows, il semble normale que tu puisse voir le PC Serveur et tout ce qui tourne dessus.
Par contre, il est a priori anormale que tu puisse acceder au partage situé sur une machines differentes. Cela est cependant possible si le serveurs est une edition Serveur de windows auquel cas, le routage est activé par defaut !


 
 
Mon serveur VPN est une Debian. Quelqu'un a t'il une explication quant au fait que j'accède à tous les services de mon serveur VPN ( Samba notamment) malgré l'utilisation du mode routing ???
 
Je me pose la question de savoir qu'est ce qu'on est censé faire avec ce mode routing par rapport au mode bridge ???

n°280577
mugnier102
Posté le 21-05-2007 à 21:50:09  profilanswer
 

Le mode route te permet d'acceder a des PC derriere le serveur ou derriere un clients... Reprend le shema de Neo,
Le serveur est le PC1. Le PC3 se connecte au PC1... Pas de prb pour acceder au contenu du PC1. Sauf qu'il serait sans doute interressant de pouvoir acceder au 15 autre serveur (PC2...) de la boite pour acceder a tout les service...
Mais si il faut ouvrir 15 tunnel, 1 avec chaque PC, j'imagine la galere pour rajouter un client sur les 15 serveur ou un serveur sur les 15 clients.
Sans compter des limitation physique de windows, de plan d'adressage et autre considerations d'encombrement de bande passante...
 
Je met donc un PC qui ne sert que de serveur, qui filtre les acces (par-feu), facile a maintenir, a faire évoluer... et je configure dessus un par-feu qui filtrera les connections du VPN au 15 serveurs interne... (et d'ailleurs pas les 30 autres qui sont interdit depuis l'exterieur... trop confidentiel !) De meme, je reduit les risque de piratages des stations...
 
Sur le mode bridge, on peut beaucoup plus facilement envoyé des trames indesirable (Hacking) car le serveur ne regarde même pas si le paquets est correcte... Ni la destination d'ailleurs...
En reliant en mode bridge 2 sites sur lequel j'ai des Hub, je vais avoir des problemes de collision 2 fois + vite !
 
Pour ce qui est de Samba et des autres... au lieu de les faire écouter sur toute les interfaces (defaut - 127.0.0.1), demande leurs d'écouter uniquement sur l'ip du reseau ou l'ip du VPN. Cela devrait resoudre ton probleme a condition de filtrer avec le firewall...(Sinon, il suffit de mettre l'ip interne et de trafiquer la table de routage de la station cible!)

n°280702
sotaz
Posté le 22-05-2007 à 10:29:26  profilanswer
 

bonjour,
Excusez moi d'insister mais personne n'aurait d'éléments à me donner par rapport à la mise en place d'un mot de passe lors de la connexion du client VPN....j'aimerais savoir s'il serait possible d'en mettre en place lors de la connexion parce que pour l'instant le seul mot de passe demandé c'est celui lorsque le client essaie d'accéder à une autre machine, et c'est donc le mot de passe du PC en question...
Merci pour vos réponses... :jap:

n°280706
mugnier102
Posté le 22-05-2007 à 10:55:54  profilanswer
 

C'est cela le probleme de ne pas utiliser un serveur central... LDAP...
J'essaye de te bricoler qq chose...

n°280710
mugnier102
Posté le 22-05-2007 à 11:18:38  profilanswer
 

hyperman22 a écrit :

Bonjour a tous,
 
Je me suis dit que tout le monde ne voulait peut-être pas utiliser le système d'authentification par certificat (méthode sécurisé mais lourde à mettre en place). OpenVPN propose une solution d'authentification par mot de passe. Je vais expliquer comment cela se passe et les modifications des fichiers a effectuer.
 
 
 
Tout d'abord sur le client :
 

Les lignes suivantes peuvent être commentées ou supprimées par rapport au tuto (il n'est donc plus nécessaire de créer un certificat par utilisateur). Il est tout de  même possible de les laisser si l'on souhaite avoir une sécurité maximum (cad certificat + mot de passe) :
      ;cert client1.crt
      ;key client1.key
 
 
Il faut ajouter cette ligne dans le fichier pour qu'il demande à l'utilisateur de saisir le mot de passe :
 
      auth-user-pass


 
Mon client fonctionnel :

client
 
;dev tap
dev tun
 
proto tcp
;proto udp
 
remote xxxxx.com 1201
 
resolv-retry infinite
 
nobind
 
persist-key
persist-tun
 
ca ca.crt
;cert client1.crt
;key client1.key
 
ns-cert-type server
 
tls-auth ta.key 1
 
verb 3
 
auth-user-pass


 
 
Ensuite sur le serveur :

port 1201
 
proto tcp
;proto udp
 
;dev tap
dev tun
 
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
 
dh dh1024.pem
 
server 10.8.1.0 255.255.255.0
 
ifconfig-pool-persist ipp.txt
 
client-to-client
 
keepalive 10 120
 
tls-auth ta.key 0 # This file is secret
 
persist-key
persist-tun
 
status openvpn-status.log
 
verb 3
 
#ajouter pour authentification par mot de passe :
client-cert-not-required
auth-user-pass-verify script.bat via-env
username-as-common-name


 
Explications des lignes ajoutés :

client-cert-not-required

==> nécessaire si ont utilise une authentification par mot de passe uniquement et sans les certificats
 
 

auth-user-pass-verify script.bat via-env

==> ligne indiquant le script utiliser pour vérifier le mot de passe et le username saisie par le client. (J'expliquerais cela plus loin).
 
 

username-as-common-name

==> Utiliser le username en tant que common name (ligne facultative mais recommandé pour simplifier la lecture des logs et faire des configuration plus compexe)
 
 
A ce stade la configuration pure d'openVPN est terminé. Il reste a gérer les utilisateurs et mot de passes. Des dizaine de solutions existent (surtout sur UNIX). Sur windows les infos sont plutôt rare.  
 
 
L'avantage et l'inconvénient d'OpenVPN est que la gestion des utilisateur est laissé à l'entière charge de celui qui l'instal. Il faut donc créer un script décidant de laisser le client se connecter ou non. Voici mon script que j'ai placé dans le répertoire "config" d'OpenVPN :
 
script.bat :

if %username%:%password%==roro:azert EXIT 0
if %username%:%password%==toto:titit EXIT 0
ELSE EXIT 1


 
Ce script fonctionne et est très simple. Je l'ai créer rapidement pour mes propres besoins. Il est évident que si vous devez gérer un nombre important d'utilisateurs (ou récupérer dans une base LDAP par exemple), il est impossible d'utiliser un script comme celui ci. A vos clavier pour en faire de plus sophistiquer. Je précise qu'il en existe des dizaines sous Unix!!
 
L'essentiel est de dire que le script doit renvoyer 0 si l'utilisateur est autorisé a se connecter et un dans le cas contraire. C'est ce que je fait avec le "EXIT 0" et le "EXIT 1". Le username et le password saisi sur le client sont récupérer dans deux variables d'environnement "username" et "password".  
 
Voila, je pense avoir dit l'essentiel !!


 
Bon... le travail est deja donc tout fait !
 
Donc en gros...
auth-user-pass =>Dans le client
auth-user-pass-verify script.bat via-env => Dans le serveur
Eventuellement username-as-common-name =>Dans le serveur
 
script.bat : => Dans le repertoire config
--------------Script.Bat--------------
if %username%:%password%==roro:azert EXIT 0  
if %username%:%password%==toto:titit EXIT 0
if %username%:%password%==nom_utilisateur:mot_de_passe EXIT 0
ELSE EXIT 1
--------------Fin script.Bat--------------
 
PS: Rajoute autant de ligne que d'utilisateur...
 
J'essaye de voir pour un encodage des mots de passe....

n°280736
mugnier102
Posté le 22-05-2007 à 12:29:34  profilanswer
 

Cela marche... j'ameliore et je poste en fin de journée

n°280897
mugnier102
Posté le 22-05-2007 à 23:28:18  profilanswer
 

BOn... je m'arrete la pour ce soir...
C'est du PHP en ligne de commande...
 j'ai réussi l'ecriture dans un fichier des nom/mdp encodé
 J'ai réussi a retrouver les noms... mais il faut que je standardise
la methode d'encodage du mot de passe... presque fini...
Merci de me faire un privé pour ceux que cela interresse...

n°281069
tigermick
Posté le 23-05-2007 à 21:37:57  profilanswer
 

Bonjour,
 
Voilà mon probléme :
Je viens ici car je ne sais plus quoi faire.
En effet je viens de m'installer un serveur OpenVPN en mode bridge sous une debian Etch en mode texte...
Tout marche nickel....je ping tous mais pour le jeux en réseau je trouve que c'est pas le top.
Quand j'essai de jouer à blobby le jeu rame à mort d'un coté ou de l'autre suivant celui qui crée la partie.
Quand je joue à Command and Conquer 3, les joueurs distant ne voient pas les joueurs qui sont dans le réseau où se trouve le serveur OpenVpn....obligé de désactiver l'interface réseau principal (l'interface non virtuelle donc...) démarrer le jeu...le minimiser... réactiver l'interface principal me reconnecter au VPN et rerentrer dans le jeu....et là enfin je suis dans le jeu et je voit tout le monde...(tout les client VPN doive faire cela).
j'ai essayé de changer le protocole et d'utiliser TCP au lieu d'UDP mais aucun changement. J'ai essayé de diminuer le MTU et le passer à 1400 sur l'interface br0 eth0 et eth1 sur le serveur et sur les clients mais toujours aucun changement.
Quand je ping mon serveur OpenVpn j'ai une réponse au ping qui met 72ms et quand je ping un autre client openvpn le ping met entre 200 et 300ms...je trouve que c'est vraiment trés élevé pour dire que les tests sont réalisés depuis 3 connections 20Mbps/1Mbps avec des lignes de bonnes qualités donc pouvant atteindre réellement ces débits.
Et en réalité mon problème principal est que la connection OpenVPN est trop lente.... mais comment faire pour pouvoir profité du maximum des débit disponible depuis les clients et depuis la connection où se trouve les serveurs...
il me faudrait de bons temps de réponse pour pouvoir jouer au jeux en réseau.  
Pourriez vous m'envoyer vos config réseaux (débit connexion internet) et un copier coller de vos ping.
si quelqu'un voulait bien me donner une config qui irait bien pour faire du réseau...j'en serais ravi....
Toute les infos sont les bienvenues donc n'hésitez pas à poster si vous avez des idées...  
Merci beaucup d'avance.

n°281084
mugnier102
Posté le 23-05-2007 à 22:16:11  profilanswer
 

Le probleme du VPN openVPN... c'est que tout passe par le serveur...
 
Et donc, tu n'a pas client1 <=> client2
mais client1 <=> serveur <=> client2
et donc logiquement...
un ping client2 depuis client fait
client1 => serveur : 30ms
serveur => client2 : 30ms
client2 => serveur : 30ms
serveur => client1 : 30ms
 
Rajoute a cela les temps d'encodage plus ou moins long en fonction de la puissance de la machine et de la clé.... il te manque encore le temps de traitement pour le routage... sur le serveur... qui a la base n'est pas conçu specialement pour cela....
Tu obtiens sans doute la difference !!!
 
1 Solution: Mettre le serveur sur une machine (dedié) directement
sur internet (Fibre optique: ping en general <10 ms contre plus de 30 sur de l'adsl !)
2 Solution: Simplifier l'encodage dans OpenVPN... mais la je ne connais pas encore l'option sauf a baisser la longueur de clé, eviter la renegociation (2h par defaut) et autre petit parametre...
 
Je me permet de te demander te completer ton post par les temps de ping suivant:
client1 => google
client1 => ip_serveur_hors_vpn
client1 => ip_serveur_en_vpn
client1 => client2_hors_vpn
client1 => client2_en_vpn
 
Et la ce sera top ! Je pense que l'on verra mieux ton prb !
 
PS: Si tu a baisse le mtu a 1400, tu aurais put descendre en dessous de 1300 voir de 1000 sans prb... mais je doute que cela resolve ton prb !
PS2: A tu essayer en mode routé ?
 
Jeu bloby: c'est la surcharge de la machine qui crée un fort ralentissement du VPN, essaye d'utiliser une autre (vielle) pour s'occuper du VPN.
Jeu C&C 3: Il me semble que TCP ne lui fait pas peur !
 
Hela pour toi, je ne croit pas que la securité et la vitesse fasse bon ménage !

n°281143
tigermick
Posté le 24-05-2007 à 10:56:08  profilanswer
 

oui mais même en pensant comme tu le fais c'est pas top car en fait 70 ms c'est une machine du réseau où se trouve le serveur VPN sous linux Debian (mon openVPN est en Bridging) qui ping un client donc c'est pareille si c'est le serveur qui ping ou le client ; et de client à client c'est plutôt entre 150 et 200ms de délai pour la réponse.
 
bon je redonne les valeurs :
client1=>google : 54
client1=>ip serveur sans VPN : 60
client1=>ip serveur avec VPN (donc là on ping une IP privé) : 250
client1=>client2 sans VPN :  
client1=>client2 avec VPN  (donc là on ping une IP privé) :  
(je réédite mon message pour mettre les informations dès que je l'ai ai!)


Message édité par tigermick le 24-05-2007 à 20:13:48
n°281158
King_T
Posté le 24-05-2007 à 11:34:13  profilanswer
 

Bonjour a tous ,
 
J'utilise  la connexion VPN en tant que client, et j'ai un petit souci car j'aimerai bien fixer mon Adresse IP (celui du VPN) exp :192.168.1.200
j'ai cherché l'a reponse dans les postes précédents, mais j'ai pas trouvé !!!
alors s'il ya une solution, merci de m'informer.
 
encor merci :)
 

n°281160
mugnier102
Posté le 24-05-2007 à 11:36:02  profilanswer
 

Moi j'ai mini 3 maxi 7 et moyenne 5 entre le serveur et un client sur du wifi et 8,8 moyenne 8 sur le meme client en ping a travers le VPN !
Ton reseau se traine... ou est sciemment ralenti ! (On evite certaine attaque en ralentissant les paquets)

n°281166
mugnier102
Posté le 24-05-2007 à 12:01:30  profilanswer
 

Alors... Sachant que 4 ip sont utilise par client, il te faudra configurer manuellement les ip telle que:
 
Classe :  C  
Nombre de sous réseaux disponibles :  64  
Nombre d'hôtes disponibles :  2  
Masque de sous-réseau :  255. 255. 255. 252    
Incrément :  4
 
Num| Sous-Réseau| Adresse Début / Fin | Broadcast
1 | 192. 168. 1. 0 | 192. 168. 1. 1 / 192. 168. 1. 2 | 192. 168. 1. 3
2 | 192. 168. 1. 4 | 192. 168. 1. 5 / 192. 168. 1. 6 | 192. 168. 1. 7
3 | 192. 168. 1. 8 | 192. 168. 1. 9 / 192. 168. 1. 10 | 192. 168. 1. 11    
4 | 192. 168. 1. 12 | 192. 168. 1. 13 / 192. 168. 1. 14 | 192. 168. 1. 15    
 
Tu peut retrouver cela sur http://www.nt-conseil.com/TCP_Calcul_SR.asp
 
Ceci dit, dans un premier temps, tu peut t'assurer que les adresses reste identique en utilisant --ifconfig-pool-persist addresseip.txt
et pour affecter une ip definit a chaque client, il te faudra utiliser
--client-config-dir ccd
--ifconfig-push 10.9.0.1 10.9.0.2
Mais attention au probleme des 4 adresse, il faudra que tes adresses tombe juste !
 
Ah oui, evidemment ces modif se font sur le serveur uniquement ! (Si tout les clients demande la meme IP, a qui je la donne ?, au pirate ? ;-))


Message édité par mugnier102 le 24-05-2007 à 12:03:22
n°281254
tigermick
Posté le 24-05-2007 à 20:18:49  profilanswer
 

Bon en fait je me demande si mon problème viens pas simplement du fais que je suis obligé de faire un pont sur la connexion d'un client pour que command and conquer voit la connexion si il cherche sur la carte réseau plutot que sur l'interface virtuelle!!!!
n'y aurait il pas un moyen de dire que l'interface réseau virtuelle openvpn est la connexion par défaut ou un truc du style(hamachi est apparemment reconnu comme ça car cnc3 recherche direct sur l'interface hamachi et pas sur l'interface reseau physique!!!)

n°281295
mugnier102
Posté le 25-05-2007 à 00:31:12  profilanswer
 

Si ton pont est correcte, tu n'a plus acces a 2 carte reseau mais une seule interface qui regroupe les 2 cartes... (Je dirai les 2 prises qui maintenant se comporte comme un hub).
Par contre il est difficile de faire le pont des 2 coté ! Il deviendrai alors difficile de se reperer entre les 2 connections...
 
Je me demande comment ferai C&C sur ma becane avec 2 carte physique + 2 carte virtuel ! et je pense qu'il saura trouve...
Red Alert prenait déjà les IP... donc le routage ne devrait pas le perturber !
Je pense que ton prb vient de ton utilisation de CC et de ces options...


Message édité par mugnier102 le 25-05-2007 à 00:32:22
n°281359
Florent42
Posté le 25-05-2007 à 16:08:33  profilanswer
 

rebonjour,
 
en réponse voici mes logs (desole j ai été un peu absent ces temps-ci)
coté client:

Code :
  1. Fri May 25 16:03:31 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2006
  2. Fri May 25 16:03:31 2007 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
  3. Fri May 25 16:03:31 2007 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
  4. Fri May 25 16:03:31 2007 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
  5. Fri May 25 16:03:31 2007 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
  6. Fri May 25 16:03:31 2007 LZO compression initialized
  7. Fri May 25 16:03:31 2007 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
  8. Fri May 25 16:03:31 2007 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
  9. Fri May 25 16:03:31 2007 Local Options hash (VER=V4): '504e774e'
  10. Fri May 25 16:03:31 2007 Expected Remote Options hash (VER=V4): '14168603'
  11. Fri May 25 16:03:31 2007 UDPv4 link local: [undef]
  12. Fri May 25 16:03:31 2007 UDPv4 link remote: 192.168.120.2:1194
  13. Fri May 25 16:03:31 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
  14. Fri May 25 16:03:33 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
  15. Fri May 25 16:03:35 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
  16. Fri May 25 16:03:37 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
  17. Fri May 25 16:03:39 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
  18. Fri May 25 16:03:41 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
  19. Fri May 25 16:03:43 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
  20. Fri May 25 16:03:54 2007 TLS: Initial packet from 192.168.120.2:1194, sid=df22680d f46551ac
  21. Fri May 25 16:03:54 2007 VERIFY OK: depth=1, /C=FR/ST=RA/L=Sane/O=Tele/CN=telat/emailAddress=mail@host.domain
  22. Fri May 25 16:03:54 2007 VERIFY OK: nsCertType=SERVER
  23. Fri May 25 16:03:54 2007 VERIFY OK: depth=0, /C=FR/ST=RA/O=Telephoniedupilat/CN=server/emailAddress=mail@host.domain
  24. Fri May 25 16:03:54 2007 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
  25. Fri May 25 16:03:54 2007 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
  26. Fri May 25 16:03:54 2007 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
  27. Fri May 25 16:03:54 2007 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
  28. Fri May 25 16:03:54 2007 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
  29. Fri May 25 16:03:54 2007 [server] Peer Connection Initiated with 192.168.120.2:1194
  30. Fri May 25 16:03:55 2007 TCP/UDP: Closing socket
  31. Fri May 25 16:03:55 2007 SIGTERM[hard,] received, process exiting
  32. Fri May 25 16:03:55 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2006
  33. Fri May 25 16:03:55 2007 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
  34. Fri May 25 16:03:55 2007 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
  35. Fri May 25 16:03:55 2007 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
  36. Fri May 25 16:03:55 2007 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
  37. Fri May 25 16:03:55 2007 LZO compression initialized
  38. Fri May 25 16:03:55 2007 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
  39. Fri May 25 16:03:55 2007 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
  40. Fri May 25 16:03:55 2007 Local Options hash (VER=V4): '504e774e'
  41. Fri May 25 16:03:55 2007 Expected Remote Options hash (VER=V4): '14168603'
  42. Fri May 25 16:03:55 2007 UDPv4 link local: [undef]
  43. Fri May 25 16:03:55 2007 UDPv4 link remote: 192.168.120.2:1194
  44. Fri May 25 16:03:55 2007 TLS: Initial packet from 192.168.120.2:1194, sid=708cd168 e10bfac9
  45. Fri May 25 16:03:55 2007 VERIFY OK: depth=1, /C=FR/ST=RA/L=Sane/O=Telet/CN=teat/emailAddress=mail@host.domain
  46. Fri May 25 16:03:55 2007 VERIFY OK: nsCertType=SERVER
  47. Fri May 25 16:03:55 2007 VERIFY OK: depth=0, /C=FR/ST=RA/O=Teleat/CN=server/emailAddress=mail@host.domain
  48. Fri May 25 16:03:55 2007 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
  49. Fri May 25 16:03:55 2007 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
  50. Fri May 25 16:03:55 2007 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
  51. Fri May 25 16:03:55 2007 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
  52. Fri May 25 16:03:55 2007 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
  53. Fri May 25 16:03:55 2007 [server] Peer Connection Initiated with 192.168.120.2:1194
  54. Fri May 25 16:03:57 2007 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
  55. Fri May 25 16:03:57 2007 PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
  56. Fri May 25 16:03:57 2007 OPTIONS IMPORT: timers and/or timeouts modified
  57. Fri May 25 16:03:57 2007 OPTIONS IMPORT: --ifconfig/up options modified
  58. Fri May 25 16:03:57 2007 OPTIONS IMPORT: route options modified
  59. Fri May 25 16:03:57 2007 TAP-WIN32 device [Connexion au réseau local 3] opened: \\.\Global\{18D28907-2879-49BD-B947-088EC44C6877}.tap
  60. Fri May 25 16:03:57 2007 TAP-Win32 Driver Version 8.4
  61. Fri May 25 16:03:57 2007 TAP-Win32 MTU=1500
  62. Fri May 25 16:03:57 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {18D28907-2879-49BD-B947-088EC44C6877} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
  63. Fri May 25 16:03:57 2007 Successful ARP Flush on interface [4] {18D28907-2879-49BD-B947-088EC44C6877}
  64. Fri May 25 16:03:57 2007 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
  65. Fri May 25 16:03:57 2007 Route: Waiting for TUN/TAP interface to come up...
  66. Fri May 25 16:03:58 2007 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
  67. Fri May 25 16:03:58 2007 Route: Waiting for TUN/TAP interface to come up...
  68. Fri May 25 16:03:59 2007 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
  69. Fri May 25 16:03:59 2007 Route: Waiting for TUN/TAP interface to come up...
  70. Fri May 25 16:04:00 2007 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
  71. Fri May 25 16:04:00 2007 Route: Waiting for TUN/TAP interface to come up...
  72. Fri May 25 16:04:01 2007 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
  73. Fri May 25 16:04:01 2007 route ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.5
  74. Fri May 25 16:04:01 2007 Route addition via IPAPI succeeded
  75. Fri May 25 16:04:01 2007 Initialization Sequence Completed


 
coté serveur:

Code :
  1. Fri May 25 16:08:39 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2006
  2. Fri May 25 16:08:39 2007 Diffie-Hellman initialized with 1024 bit key
  3. Fri May 25 16:08:39 2007 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
  4. Fri May 25 16:08:39 2007 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
  5. Fri May 25 16:08:39 2007 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
  6. Fri May 25 16:08:39 2007 TLS-Auth MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
  7. Fri May 25 16:08:39 2007 TAP-WIN32 device [Connexion au réseau local 2] opened: \\.\Global\{528FDC5A-E0F4-4508-8B60-15BF2BB56EF4}.tap
  8. Fri May 25 16:08:39 2007 TAP-Win32 Driver Version 8.4
  9. Fri May 25 16:08:39 2007 TAP-Win32 MTU=1500
  10. Fri May 25 16:08:39 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.8.0.1/255.255.255.252 on interface {528FDC5A-E0F4-4508-8B60-15BF2BB56EF4} [DHCP-serv: 10.8.0.2, lease-time: 31536000]
  11. Fri May 25 16:08:39 2007 Sleeping for 10 seconds...
  12. Fri May 25 16:08:49 2007 NOTE: FlushIpNetTable failed on interface [2] {528FDC5A-E0F4-4508-8B60-15BF2BB56EF4} (status=1413) : Index incorrect. 
  13. Fri May 25 16:08:49 2007 route ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.2
  14. Fri May 25 16:08:49 2007 Route addition via IPAPI succeeded
  15. Fri May 25 16:08:49 2007 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
  16. Fri May 25 16:08:49 2007 UDPv4 link local (bound): [undef]:1194
  17. Fri May 25 16:08:49 2007 UDPv4 link remote: [undef]
  18. Fri May 25 16:08:49 2007 MULTI: multi_init called, r=256 v=256
  19. Fri May 25 16:08:49 2007 IFCONFIG POOL: base=10.8.0.4 size=62
  20. Fri May 25 16:08:49 2007 IFCONFIG POOL LIST
  21. Fri May 25 16:08:49 2007 client,10.8.0.4
  22. Fri May 25 16:08:49 2007 Initialization Sequence Completed
  23. Fri May 25 16:08:49 2007 MULTI: multi_create_instance called
  24. Fri May 25 16:08:49 2007 192.168.120.13:1217 Re-using SSL/TLS context
  25. Fri May 25 16:08:49 2007 192.168.120.13:1217 LZO compression initialized
  26. Fri May 25 16:08:49 2007 192.168.120.13:1217 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
  27. Fri May 25 16:08:49 2007 192.168.120.13:1217 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
  28. Fri May 25 16:08:49 2007 192.168.120.13:1217 Local Options hash (VER=V4): '14168603'
  29. Fri May 25 16:08:49 2007 192.168.120.13:1217 Expected Remote Options hash (VER=V4): '504e774e'
  30. Fri May 25 16:08:49 2007 192.168.120.13:1217 TLS: Initial packet from 192.168.120.13:1217, sid=d8c3b147 e2c03dbe
  31. Fri May 25 16:08:50 2007 192.168.120.13:1217 VERIFY OK: depth=1, /C=FR/ST=RA/L=Sane/O=Telilat/CN=teat/emailAddress=mail@host.domain
  32. Fri May 25 16:08:50 2007 192.168.120.13:1217 VERIFY OK: depth=0, /C=FR/ST=RA/O=Telilat/CN=client/emailAddress=mail@host.domain
  33. Fri May 25 16:08:50 2007 192.168.120.13:1217 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
  34. Fri May 25 16:08:50 2007 192.168.120.13:1217 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
  35. Fri May 25 16:08:50 2007 192.168.120.13:1217 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
  36. Fri May 25 16:08:50 2007 192.168.120.13:1217 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
  37. Fri May 25 16:08:50 2007 192.168.120.13:1217 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
  38. Fri May 25 16:08:50 2007 192.168.120.13:1217 [client] Peer Connection Initiated with 192.168.120.13:1217
  39. Fri May 25 16:08:50 2007 client/192.168.120.13:1217 MULTI: Learn: 10.8.0.6 -> client/192.168.120.13:1217
  40. Fri May 25 16:08:50 2007 client/192.168.120.13:1217 MULTI: primary virtual IP for client/192.168.120.13:1217: 10.8.0.6
  41. Fri May 25 16:08:51 2007 MULTI: multi_create_instance called
  42. Fri May 25 16:08:51 2007 192.168.120.13:1226 Re-using SSL/TLS context
  43. Fri May 25 16:08:51 2007 192.168.120.13:1226 LZO compression initialized
  44. Fri May 25 16:08:51 2007 192.168.120.13:1226 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
  45. Fri May 25 16:08:51 2007 192.168.120.13:1226 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
  46. Fri May 25 16:08:51 2007 192.168.120.13:1226 Local Options hash (VER=V4): '14168603'
  47. Fri May 25 16:08:51 2007 192.168.120.13:1226 Expected Remote Options hash (VER=V4): '504e774e'
  48. Fri May 25 16:08:51 2007 192.168.120.13:1226 TLS: Initial packet from 192.168.120.13:1226, sid=1433a985 8d60081c
  49. Fri May 25 16:08:52 2007 192.168.120.13:1226 VERIFY OK: depth=1, /C=FR/ST=RA/L=Sane/O=Tellat/CN=telat/emailAddress=mail@host.domain
  50. Fri May 25 16:08:52 2007 192.168.120.13:1226 VERIFY OK: depth=0, /C=FR/ST=RA/O=Telat/CN=client/emailAddress=mail@host.domain
  51. Fri May 25 16:08:52 2007 192.168.120.13:1226 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
  52. Fri May 25 16:08:52 2007 192.168.120.13:1226 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
  53. Fri May 25 16:08:52 2007 192.168.120.13:1226 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
  54. Fri May 25 16:08:52 2007 192.168.120.13:1226 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
  55. Fri May 25 16:08:52 2007 192.168.120.13:1226 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
  56. Fri May 25 16:08:52 2007 192.168.120.13:1226 [client] Peer Connection Initiated with 192.168.120.13:1226
  57. Fri May 25 16:08:52 2007 MULTI: new connection by client 'client' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
  58. Fri May 25 16:08:52 2007 MULTI: Learn: 10.8.0.6 -> client/192.168.120.13:1226
  59. Fri May 25 16:08:52 2007 MULTI: primary virtual IP for client/192.168.120.13:1226: 10.8.0.6
  60. Fri May 25 16:08:53 2007 client/192.168.120.13:1226 PUSH: Received control message: 'PUSH_REQUEST'
  61. Fri May 25 16:08:53 2007 client/192.168.120.13:1226 SENT CONTROL [client]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)


 
merci


Message édité par Florent42 le 25-05-2007 à 16:11:42
n°281360
tigermick
Posté le 25-05-2007 à 16:12:26  profilanswer
 

Moi je pense que ça vient du pont car j'ai reussit à y jouer à travers mon vpn en faisant ceci :
desactiver mon interface reseau physique (pour internet)
démarrer le jeu, entrer dans la partie réseau du jeu (donc là il voit que ma carte virtuelle)
je minimise le jeu, j'active mon interface réseau physique.
je remaximise le jeu, là je vois enfin les joueurs dans le réseau où se trouve le serveur vpn en mode bridge...
je démarre la partie et tout marche bien. Une fois la partie terminée, je reviens automatiquement dans la partie réseau et là rebelotte je dois refaire la manip si je veux voir les autres joueurs qui sont dans le réseau local où il y a le serveur vpn.

n°281386
mugnier102
Posté le 25-05-2007 à 18:07:14  profilanswer
 

Tigermick =>Et que donne le lag ?
 
Florian42 => Bon... a la vue des log, tu est en DHCP...
je te conseil un ping sur l'IP 10.8.0.1 depuis le client et 10.8.0.6 depuis le serveur... a priori, il n'y a pas de raison que ces IP ne marche pas !

n°281388
Florent42
Posté le 25-05-2007 à 18:19:51  profilanswer
 

oui je suis en DHCP tout simplement et ca me va tres bien.
Malheureusement le ping ne passe pas...ni du client vers serveir, ni du serveur vers le client
(et je persiste il n y a aucun firewall activé!)

n°281392
mugnier102
Posté le 25-05-2007 à 18:44:34  profilanswer
 

Ok... Je regarde tes fichiers de config...

n°281409
tigermick
Posté le 25-05-2007 à 20:02:09  profilanswer
 

que donne le lag???? peux tu etre un peu plus expicite? je comprend pas ce que tu ve dire par là

n°281421
mugnier102
Posté le 25-05-2007 à 21:10:27  profilanswer
 

Les temps de reponse... Google te donnera une definition plus precise.

n°281455
tigermick
Posté le 26-05-2007 à 08:36:13  profilanswer
 

les temps de reponse son plutot normal finalement meme s'il paraisse elevé j'ai remarqué que j'ai un pote qui à une reponse au ping de 150ms rienq ue pour pinger google donc....
meme 200ms pour client à client à travers mon vpn ça devrais etre bon....
à mon avis fodrait que je sache dire à windows que l'interface reseau virtuelle est l'interface reseau principal ou par defaut ou un truc comme ça!!!!

n°281482
mugnier102
Posté le 26-05-2007 à 11:28:22  profilanswer
 

Je ne sais pas comment le moteur du jeux est fait... Mais windows n'a pas d'interface par defaut. Il a une passerelle par defaut.
Par contre si tu met la carte reseau en passerelle par defaut, cela risque d'etre joyeux: Tu n'aura plus d'internet donc plus de VPN...
Je ne vois pas trop comment t'aider plus...
PS: 60ms sur de l'adsl est normal... mais 150ms pour ton pote pas vraiment !


Message édité par mugnier102 le 26-05-2007 à 11:30:20
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  10  11  12  ..  42  43  44  45  46  47

Aller à :
Ajouter une réponse
 

Sujets relatifs
*** Réseau domestique et partage de connexion Internet 
Plus de sujets relatifs à : Réseau privé virtuel sous Windows - OpenVPN - Tutoriels.


Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)