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

Recherche :

Mot : Pseudo : Filtrer Aller à la page :
Page : 1 2 3 4 5 .. 18 19 20 .. 42 43 44 45 46 47 Page Suivante Page Précédente Bas de page
Auteur	Sujet : Réseau privé virtuel sous Windows - OpenVPN - Tutoriels.

argh et re argh

Reprise du message précédent :
Suite du post précédent :
j'ai lu dans la pages précédentes qu'il fallait créer une route manuellement pour vista mais
- est ce côtés client ou serveur
- où la créer ? ( nom exact du fichier)
- dois je installer openvpn version vista sur le serveur aussi ( qui tourne sous xp) pour que ce dernier daigne fonctionner ou pas ?
Je précise que la connexion ne se fait pas du tout sur le client , pas possible de pinger , pas d'adresse attribuée rien.
Le firewall sur le client en vista est désactivé, pas de norton, pas d'antivirus non plus.
Voilà, n'hésitez à m posez vos qurestions si ça peut m'aider et non je ne peux pas passer ces postes en xp .

merki

Publicité

mugnier102

Au lieu de Vista et XP, merci de donner du numero de version,

A version =, tu ne devrai pas avoir de prb. A version inegale, il est encore possible que cela marche, je n'ai pas essayer.
Mais cela me semble devoir fonctionner.

Sinon, le serveur se lance correctement sur vista ? Le client apparait dans le log ?

Likai

C'est au pied du mur...

A Mugnier,
Bonjour et désolé du retard de la réponse. J'ai eu une longue coupure de la part de mon FAI. Finalement tout fonctionne bien, j'ai testé ma config sur plusieurs postes en local et en distant, tout est ok sauf pour un qui m'affiche toujours cette histoire de 'le nom réseau spécifié n'est plus disponible". J'en déduis que le Windows XP SP1 qui est dessus doit avoir un pb réseau mais je n'arrive vraiment pas à le cerner, pas grave, chez le client ça marche...J'utilise un programme réseau client qui vient se connecter à la base de données du serveur via Openvpn, c'est un peu lent mais je suppose que c'est le débit de l'upload qui limite tout ça.
Merci pour ton aide en tout cas.

mugnier102

Tu peut jeter un coup d'oeil sur l'utilisation du reseau pour avoir une idée.
Je te propose sur le PC déconnant de supprimer tout ce qui se trouve dans les propriete de la carte (voir des cartes) reseau concerné puis de supprimer la carte et de terminer par un reboot et une reinstallation (en generale, windows en fait la moitié tout seul....)
Il arrive tres souvent que la pile reseau de windows se retrouve buggé.

argh et re argh

hello,
dsl mugnier mais j'étais pris donc je réponds à ta question : le problème venait de mon installation d'openvpn : mal installé donc maintenant ca fonctionne avec client sous vista et le serveur sous xp.
Mais pour faire un post utile j'ai deux questions :
- peut on avoir un pc qui serait client d'un serveur ( cas habituel) mais aussi serveur pour des clients, en même temps ?
- peut avoir un poste qui serait client mais de plusieurs serveurs éloignés géographiquement, simultanément ou pas ?
J'avoue je demande ça sans avoir épluché les 20 pages précédentes ;-)
Merciiii

radeon4ever

Chasseur de specs

superbe tuto, vraiment excellent, bien réalisé et bien expliqué, du premier coup j'ai réussi a monter mon VPN alors que je ne connaissais vraiment que les bases

merci

---------------
(VDS) XPS 17 9730 - i9 - RTX 4080 - 64Go - 1To - 17' 4K

zarwal

Le tuto est très clair et tout s'est bien passé jusqu'à la génération de la clef "client". Les fichiers ca.crt, ca.key et homewz.csr (nom du client avec common name identique) sont bien dans le répertoire c:\program files\openvpn\easy-rsa\keys. Les vars sont correctes et complètes.
Le lancement de sign-req homewz se passe bien jusqu'à la confirmation de signature. Les lignes suivantes apparaissent alors:

sign the certificate? [y/n]:y
failed to update database
TXT_DB error number 2

et le fichier homewz.crt se crée avec une longuer de 0 bytes.

mugnier102

@Zarwal: A tu suivi la procedure en une seule fois ?
Sinon, il vaut relancer vars.bat avant de reprendre...

Si tu ne fais pas tout cela sur le meme ordinateur, il te faudra egalement lancer init-config sur le deuxieme ordinateur et editer vars.bat

Ton fichier CRT doit être supérieur a 0 octet avant de continuer...

Florent42

une question je pense que d'autres ont le problème:

voila j ai créé une certificat et une clé pour un client tout testé tout marche bien.

Maintenant j ai une autre poste client et j'aimerais lui aussi lui creer un certificat...je relance donc build-key mais le drame il me donne toute une liste d'argument de "req" et finit par dire "impossible de trouver c*.old"

de plus imaginons le cas ou un des pc portacle client se fait voler....comment annuler le certificat du client sur le serveur?

merci

mugnier102

Rappel 1: Les Cle des autre clients doivent etre cree sur l'authorité de certification (en gros l'ordi qui a servi a creer les premieres clé...)
Rappel 2: Avant tout nouvelle appel a l'un des script, il faut relancer le fichier vars.bat

Pour l'annulation, on apelle cela revocation... Il te faut, le fichier publique a revoquer (fichier .crt). Le script revoke full te permet de faire la revocation... Reste plus qu'a copier le fichier crl.pem qui vient d'être créé dans le repertoire du serveur et d'activer la verification avec l'option "crl-verify crl.pem"
Voila....

Dit moi si ton prb persiste...

Message édité par mugnier102 le 31-10-2007 à 20:00:40

Publicité

Florent42

pas de soucis pour le rappel 1, car je suis bien sur le pc qui a crée les premières clé

Et j ai également fait un init-config, mais le problème demeure

faut il tout relancer (ca, server.key,...)?

De plus en meme temps:
Imaginons on crée a chaque fois un vars.bat différents (en gros le premier on est en en rhones alpes a lyon, le 2eme ile de france a paris,...), avec un nom de reseau différent. ca gene ensuite pour le fonctionnement?

mugnier102

SI tu a refait un init-config, tu a foutu toute l'installation en l'air.... donc il te faut tout recommencer !!

En fait, tu cree une autorité de certifications. (ca.key et ca.crt)
Tous les certificat signé avec cette authorité de certification seront valables pour cette autorite.

Il te faut changer le fichier ca.key et ca.crt pour passer d'une autorité a l'autre.... Quand a changer le fichier vars.bat, c'est un detail. Tu peut le renomer en vars1, vars2....

Florent42

oui effectivement je m'étais planté

la tout marche bien. C'était effectivement la reexecution de vars.bat qui n'avais pas marché je ne sais pas pourquoi...

la tout va bien!

merci

canigou4

siteman ...

très bon tuto, drapal par la même occasion

Message édité par canigou4 le 05-11-2007 à 00:58:51

canigou4

siteman ...

Bonjour,

je viens de mettre en place ce système et j'ai un petit problème

Code :

Mon Nov 05 00:57:05 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006
Mon Nov 05 00:57:05 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.
Mon Nov 05 00:57:05 2007 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Mon Nov 05 00:57:05 2007 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Nov 05 00:57:05 2007 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Nov 05 00:57:05 2007 LZO compression initialized
Mon Nov 05 00:57:05 2007 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
Mon Nov 05 00:57:05 2007 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Mon Nov 05 00:57:05 2007 Local Options hash (VER=V4): '13a273ba'
Mon Nov 05 00:57:05 2007 Expected Remote Options hash (VER=V4): '360696c5'
Mon Nov 05 00:57:05 2007 UDPv4 link local: [undef]
Mon Nov 05 00:57:05 2007 UDPv4 link remote: IP:1194
Mon Nov 05 00:57:05 2007 TLS: Initial packet from IP:1194, sid=02799c91 ddcdaad0
Mon Nov 05 00:57:06 2007 VERIFY OK: depth=1, /C=FR/ST=AL/L=Strasbourg/O=nom/CN=nom/emailAddress=mail
Mon Nov 05 00:57:06 2007 VERIFY OK: nsCertType=SERVER
Mon Nov 05 00:57:06 2007 VERIFY OK: depth=0, /C=FR/ST=AL/O=nom/CN=server/emailAddress=mail
Mon Nov 05 00:57:06 2007 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Nov 05 00:57:06 2007 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Nov 05 00:57:06 2007 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Nov 05 00:57:06 2007 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Nov 05 00:57:06 2007 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Nov 05 00:57:06 2007 [server] Peer Connection Initiated with IP:1194
Mon Nov 05 00:57:08 2007 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Mon Nov 05 00:57:08 2007 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.0.2,ping 10,ping-restart 120,ifconfig 192.168.0.161 255.255.255.0'
Mon Nov 05 00:57:08 2007 OPTIONS IMPORT: timers and/or timeouts modified
Mon Nov 05 00:57:08 2007 OPTIONS IMPORT: --ifconfig/up options modified
Mon Nov 05 00:57:08 2007 OPTIONS IMPORT: route options modified
Mon Nov 05 00:57:08 2007 TAP-WIN32 device [OpenVPN] opened: \\.\Global\{C34C3E4E-8A89-4003-8366-5BFE9CB64AF9}.tap
Mon Nov 05 00:57:08 2007 TAP-Win32 Driver Version 8.4
Mon Nov 05 00:57:08 2007 TAP-Win32 MTU=1500
Mon Nov 05 00:57:08 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.0.161/255.255.255.0 on interface {C34C3E4E-8A89-4003-8366-5BFE9CB64AF9} [DHCP-serv: 192.168.0.0, lease-time: 31536000]
Mon Nov 05 00:57:08 2007 Successful ARP Flush on interface [131076] {C34C3E4E-8A89-4003-8366-5BFE9CB64AF9}
Mon Nov 05 00:57:12 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:12 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:12 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:12 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:12 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:12 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:13 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:13 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:14 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:14 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:15 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:15 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:16 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:16 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:17 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:17 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:18 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:18 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:19 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:19 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:20 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:20 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:21 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:21 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:22 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:22 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:23 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:23 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:24 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:24 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:25 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:25 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:26 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:26 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:28 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:28 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:28 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:28 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:30 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:30 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:30 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:30 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:32 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:32 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:32 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:32 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:34 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:34 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:34 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:34 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:36 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:36 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:36 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:36 2007 Route: Waiting for TUN/TAP interface to come up...
Mon Nov 05 00:57:37 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Nov 05 00:57:37 2007 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )

Voici ce que le client m'indique, je suis bien allez voir le lien, j'ai bien suivi les indiques (firewall, dhcp, etc), mais rien n'y fait,

quand je clique sur l'interface réseau, j'ai x paquets envoyés mais 0 recus

Pour infos, j'ai configuré mon serveur comme indiqué dans le tuto et en mode "bridge"

Message édité par canigou4 le 05-11-2007 à 18:12:05

mugnier102

Donne tes config serveur et clients en privé... (et efface les IP sur le site pour un peu plus de confidentialité ou en tout cas l'email qui apparait dans les log !)

xFlasH

Bonjour à tous.

Vraiment un grand bravo et un merci pour ce très bon article sur ce sujet Ô combien épineux qu'est le VPN
Cependant, j'ai un petit soucis de finalisation de la mise en oeuvre de cette architecture.

J'ai un serveur hébergé chez Ovh (debian 4) : H0 avec une adresse publique 91.X.X.X/8
VMware server est installé dessus et plusieurs vmware guest y sont présentes: H1, H2, H3, dans un sous-reseau privé NAT-é: 192.168.28.x/8

J'ai 3 portables nomades P0 avec vmware server aussi dessus
Ces P0 ont des adresses locales privées liées au sous-reseau wifi dans lequel on peut se trouver 192.168.0.x/8, ...
et chacun ont des vmware guest dessus: P1, P2, P3 dans un sous-reseau privé NAT-é: 192.168.246.x/8

je souhaite pouvoir faire communiquer P1 (WinXP) avec H1 (Debian 4 en PDC/LDAP) via une integration a un domaine NT.

J'ai donc mis en oeuvre sur une vmware H2 un serveur VPN en mode bridged:

local 192.168.28.50
port 1194
proto udp

dev tap0

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

server-bridge 192.168.28.50 255.255.255.0 192.168.28.110 192.168.28.127
;mode server
;tls-server

client-to-client
keepalive 10 120
tls-auth ta.key 0

comp-lzo

persist-key
;persist-tun

status /var/log/openvpn-status.log
log /var/log/openvpn.log
verb 3

et coté client:

client
dev tap0
proto udp

remote 91.X.X.X 1194
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
comp-lzo

verb 3

Mon serveur H0 redirige le port UDP 1194 sur le meme port de H2 192.168.28.50 (le serveur VPN)

Aujourd'hui la communication s'établit apparemment sans soucis, mais (il ya toujours un mais ;-) )
Mon client, P1 : 192.168.28.110 (ip obtenue via le bridge) ne peut pinger que H2

Des captures avec wireshark sur P1 montrent bien mes broadcast ARP (ping) mais sans reply, mais encore plus étrange on y voit les broadcast d'autres machines H2, H3 ...

Quelqu'un parmi vous aurait-il une idée sur ce qui pourrait dérailler dans l'architecure?

Merci a vous.

-R-

mugnier102

Je propose:
activation du forwarding sur le serveur linux du genre:
echo "1" > /proc/sys/net/ipv4/ip_forward

Car, je suis sur que la trame arrive sur l'interface reseau reelle mais pas sur l'interface VPN. De plus, l'interface VPN communique avec un moteur (le vrai serveur) et que lui risque d'avoir besoin de forwarder les paquets.

xFlasH

@Olivier: Merci tout d'adord de ta réponse. Mais je monte mon vpn avec 2 scripts, un pour monter le bridge et un pour le vpn en question.
pour celui-ci j'ai bien mis le forwarding IP:

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

La question ne serait-elle pas d'activer ce parametre sur toutes les machines H1, H2, H3... ?

Merci encore de ton eclairage.

-R-

xFlasH

Bon double post, mais c'est pour étayer la conversation.
J'ai remplacé mon script de "bridging" par un mecanisme un peu plus "standard" dans /etc/network/interfaces:

# The loopback network interface
auto lo
iface lo inet loopback

#The bridge TAP0-ETH0 interface
auto br0
iface br0 inet static
address 192.168.28.50
netmask 255.255.255.0
pre-up /usr/sbin/openvpn --mktun --dev tap0
pre-up /sbin/ip link set tap0 up
pre-up /sbin/ip link set eth0 up
pre-up /usr/sbin/brctl addbr br0
pre-up /usr/sbin/brctl addif br0 eth0
pre-up /usr/sbin/brctl addif br0 tap0
pre-down /usr/sbin/brctl delif br0 eth0
pre-down /sbin/ip link set eth0 down
pre-down /usr/sbin/brctl delif br0 tap0
pre-down /sbin/ip link set tap0 down
post-down /usr/sbin/brctl delbr br0
post-down /usr/sbin/openvpn --rmtun --dev tap0

Et ca marche très bien. Au cas ou ca serve a quelqu'un.

Par contre c'est la ou je me suis rappelé que du coup je n'avais plus de default gateway sur ce serveur H2 et que j'avais du coup rajouté un :

gateway 192.168.28.2

sinon le tunnel ne se montait pas. ("Network is unreachable" en boucle sur la tentative de connexion client.

Autre chose, depuis un des autres serveurs H3, ou H4, je ping très bien le serveur VPN H2, mais pas du tout le client P1 ? comme si le routage ne se faisait pas...

Merci de votre aide.

-R-

mugnier102

Pour mon indication visiblement elle n'était pas utile. J'avoue ne pas maîtrisé complètement le mode Bridge. Je prefere nettement le mode route qui permet de gérer de plus prés les autorisations (Plan d'adressage spécifique et Par feu a la volé eventuel). Et d'éviter de charger le lien VPN avec du trafic inutile en broadcast.
Ton problème venait sûrement d'une route mal écrite ou manquante (Peut être la passerelle ? Arrivait tu a accéder a Internet sur le serveur ?)
A tu un par feu sur le client ? Quelle IP ping tu ?
Attention sous windows, le plan d'adressage du VPN est un peu spécial:
Une adresse IP pour le réseau, une adresse broadcast, Une adresse Client et une adresse serveur.... Soit 4 IP par client.
Si le paquet est correctement routé, tu ne devrait pas avoir besoin d'activer le routage sur les autres serveurs. Au plus, tu devra rajouter une route. Cependant, normalement tu ne doit pas en avoir besoin

xFlasH

@Olivier, Mais mon problème reste entier. en fait l'absence de la gateway empechait simplement toute initialisation coté client du VPN, sans pour autant que ce soit expliquable. avec des erreurs ("Network is unreachable" ) dans les logs du serveur.

Je n'ai pas de pare-feu sur les clients. l'ip que je cherche a pinger est (depuis P1) H2 (192.168.28.100) ou H0 (192.168.28.1) ou meme la gateway (192.168.28.2). Ce client ne voit que 192.168.28.50, le serveur VPN... snif'

Merci pour ton information sur le plan d'adressage WinXP. Donc si je comprends bien, mon client P1 en 192.168.28.110 utilise 3 autres adresses dans la plage decrite par mon serveur VPN 192.168.28.111, 192.168.28.112, 192.168.28.113?

J'ai essayé de dumper sur H2 avec tcpdump les trames y transitant lors d'un ping, on voit bien les requetes ICMP question et reponse.... mais cette réponse doit certainement être avalée par un ver géant sur Arakis, car personne ne la voit...

J'avais bien essayé le mode "routed" au début, mais les broadcast netbios, necessaires a une integration dans un domaine NT (SMB) de mes clients ne passaient pas... A moins qu'il y ait une ruse de sioux pour ca ?

Merci de ton aide.

-R-

mugnier102

Balance ta table de routage (de H1), je suis sur a 90% que ton problème vient de la.

xFlasH

@Olivier:

vpn:~# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.28.0 * 255.255.255.0 U 0 0 0 br0
default 192.168.28.2 0.0.0.0 UG 0 0 0 br0

Message édité par xFlasH le 12-11-2007 à 20:26:42

mugnier102

Vu cette table, tout semble être correcte... Je doit vraiment être fatigué pour ne pas voir le prb.

Bon ecoute, je te propose un truc... car sinon je ne suis pas sur de pouvoir t'aider plus.

On passe en routed.

En routed, il te faudra une plage d'ip nouvelle differente du reseau interne et du reseau du client. Deplus, n'oublit pas que avec 4 adresses par client, il te faudra bien dimensionner la plage.

Pour le netbios et les partages samba, le contrôleur de domaine sera amplement suffisant.
Il faut savoir que sous windows 9x ce problème existait car dans 9x le protocole de partage de fichier utilisait la diffusion. Cependant la technologie XP utilise maintenant le port 445 et le protocol TCP/IP permettant au échange de transiter sans prb a travers les routeurs.

Pour tes essais, tu peut d'ailleurs toujours utilisé (et sans rien touché) un lien de la forme \\ip.du.serv.eur
Cela fonctionne parfaitement sans serveur wins.
Le serveur wins te permettra simplement d'avoir l'équivalent d'un dns
Note également que si le dns est correcte, il peut également être utilisé en lieu et place du wins.

xFlasH

Oki. Je teste.
Merci encore de ton temps.

-R-

xFlasH

bon retour donc en mode routed. mais pas mieux...
J'ai donc repris ma conf server:

;dev tap0
dev tun

;server-bridge 192.168.28.50 255.255.255.0 192.168.28.110 192.168.28.127
server 10.8.0.0 255.255.255.0

desactive l'interface bridgé. un ifconfig sur le serveur me donne:

vpn:~# ifconfig
eth0 Lien encap:Ethernet HWaddr 00:0C:29:D3:F6:36
inet adr:192.168.28.50 Bcast:192.168.28.255 Masque:255.255.255.0
adr inet6: fe80::20c:29ff:fed3:f636/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1962 errors:0 dropped:0 overruns:0 frame:0
TX packets:1499 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:185033 (180.6 KiB) TX bytes:234798 (229.2 KiB)
Interruption:177 Adresse de base:0x1400

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:67 errors:0 dropped:0 overruns:0 frame:0
TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:9969 (9.7 KiB) TX bytes:9969 (9.7 KiB)

tun0 Lien encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:10.8.0.1 P-t-P:10.8.0.2 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:100
RX bytes:480 (480.0 b) TX bytes:480 (480.0 b)

et la table de routage maintenant coté serveur est :

vpn:~# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.28.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.28.2 0.0.0.0 UG 0 0 0 eth0

coté client j'ai reactivé dans la conf le parametre de dev a l'identique que coté serveur

;dev tap0
dev tun

le tuyau se monte apparemment bien.
un ipconfig coté client me donne:

Configuration IP de Windows

Carte Ethernet Connexion au réseau local:

Suffixe DNS propre à la connexion : localdomain
Adresse IP. . . . . . . . . . . . : 192.168.246.131
Masque de sous-réseau . . . . . . : 255.255.255.0
Passerelle par défaut . . . . . . : 192.168.246.2

Carte Ethernet Connexion au réseau local 2:

Suffixe DNS propre à la connexion :
Adresse IP. . . . . . . . . . . . : 10.8.0.6
Masque de sous-réseau . . . . . . : 255.255.255.252
Passerelle par défaut . . . . . . :

et la table de routage:

===========================================================================
Liste d'Interfaces
0x1 ........................... MS TCP Loopback interface
0x2 ...00 0c 29 ee b7 4f ...... VMware Accelerated AMD PCNet Adapter - Miniport d'ordonnancement de paquets
0x20003 ...00 ff 27 3d 48 8f ...... TAP-Win32 Adapter V8 - Miniport d'ordonnancement de paquets
===========================================================================
===========================================================================
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 192.168.246.2 192.168.246.131 10
10.8.0.0 255.255.255.0 10.8.0.5 10.8.0.6 1
10.8.0.4 255.255.255.252 10.8.0.6 10.8.0.6 30
10.8.0.6 255.255.255.255 127.0.0.1 127.0.0.1 30
10.255.255.255 255.255.255.255 10.8.0.6 10.8.0.6 30
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.246.0 255.255.255.0 192.168.246.131 192.168.246.131 10
192.168.246.131 255.255.255.255 127.0.0.1 127.0.0.1 10
192.168.246.255 255.255.255.255 192.168.246.131 192.168.246.131 10
224.0.0.0 240.0.0.0 10.8.0.6 10.8.0.6 30
224.0.0.0 240.0.0.0 192.168.246.131 192.168.246.131 10
255.255.255.255 255.255.255.255 10.8.0.6 10.8.0.6 1
255.255.255.255 255.255.255.255 192.168.246.131 192.168.246.131 1
Passerelle par défaut : 192.168.246.2
===========================================================================
Itinéraires persistants :
Aucun

je ne ping pas de serveur en 192.168.28.x car je n'ai pas de route

route add 192.168.28.0 mask 255.255.255.0 10.8.0.6

mais toujours pas de ping.

As-tu une idée?

Merci

-R-

Message édité par xFlasH le 12-11-2007 à 21:51:00

mugnier102

Depuis le Client
Essaye de pinger 10.8.0.6
puis 10.8.0.1
Depuis le serveur 10.8.0.1
puis 10.8.0.6

Toujours sur le serveur
ping 192.168.28.50
puis un echo /proc/sys/net/ipv4/ip_forward
(ou la commande equivalente, je n'ai pas de linux sous la main... Au passage, je remarque que tu a négliger les guillemets...)

Dit moi ce que tout cela te donne dans un premier temps.

PS: Je prefere utilisé OpenVPN pour rajouter la commande dans la table de routage, c'est plus pratique que la ligne de commande ;-)

xFlasH

Depuis le client 10.8.0.6 je ping bien 10.8.0.6 (ouf' )
je ping bien aussi 10.8.0.1

Depuis le serveur, je ping bien 10.8.0.6 et aussi moi-meme autant sur 10.8.0.1 que sur 192.168.28.50

vpn:~# cat /proc/sys/net/ipv4/ip_forward
1

Et j'ai effectivé configuré openvpn sur le serveur pour qu'il "pousse" la route sur 192.168.28.0 avec un

push "route 192.168.28.0 255.255.255.0"

-R-

mugnier102

(Et merde, de nouveau le chômage pour moi !!
Enfin presque.... parqu'il manque les PC derriere le PC client... :pfff: ;-)
Sauf que dans ce cas, il n'y en a pas... :sweat: !-) )

Bon. aller, pour finir il manque qd meme le ping du serveur depuis le client puisque la route est maintenant installé...

Pour finir de configurer l'accès au autre serveurs, le plus simple est d'ajouté une route dans la table de routage du routeur de sortie
avec pour règle 10.8.0.0 Masque 255.255.255.0 vers 192.168.28.50
Et tu pourra ensuite essayer de pinger n'importe quel adresse interne.

et hop, terminé en 2h de boulot ! :bounce:

Message édité par mugnier102 le 12-11-2007 à 23:26:51

mugnier102

Le premier ping permet de verifier asser simplement l'existence de prb de par feu. En general 127.0.0.1 passe mais pas l'I.P.Ext.erne de la machine

xFlasH

avec la route coté client poussé par le server, le ping depuis le client de :
-10.8.0.6 ok
-10.8.0.1 ok
-192.168.28.50 ok

la table de routage du serveur est :

route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.28.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.28.2 0.0.0.0 UG 0 0 0 eth0

Si je rajoute ta route, (sur le serveur VPN ?) avec:

route add -net 10.8.0.0 netmask 255.255.255.0 gw 192.168.28.50

Je ne ping toujours pas 192.168.28.2 depuis le client ... ?

Euh et désolé pour toi sur la premiere partie de ton post.

-R-

mugnier102

Pas sur le serveur VPN, sur le routeur d'accès Internet ou sur tout les serveur sauf le serveur VPN

xFlasH

donc dans mon archi, sur H0 ?

mugnier102

Le serveur VPN est le seul a connaître où envoyer les paquet 10.8.x.x, par contre les autres serveurs ne le savent pas. Donc un serveur autre que VPN envoie sur la route par defaut, soit le routeur, le routeur ne sachant rien envoie vers internet (ou bloque si grand public car IP privé) Et internet de toute façon fini par jeter ces paquets faisant parti des plage réservés au usage interne.

mugnier102

Sur 192.168.28.2

xFlasH

la table de routage de H0 (192.168.28.2):

Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
91.x.x.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.8.0.0 192.168.28.50 255.255.255.0 UG 0 0 0 vmnet8
192.168.28.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
0.0.0.0 91.x.x.254 0.0.0.0 UG 0 0 0 eth0

mais pas mieux . snif'

Message édité par xFlasH le 12-11-2007 à 23:56:07

mugnier102

(Bravo pour le masquage de l'ip)
POurtant, il n'y a pas de raison... Je ne sais pas trop ce qu'est le UG qui traine... Je dirai qu'il ne me plait qu'a moitié..
Ensuite, tu peut peut-etre essayer de mettre 0.0.0.0 pour la passerelle.... et regarder si tu n'a pas une autre table de routage pour le noyau vmnet

Ton dernier problème n'est a mon avis plus de l'ordre du VPN mais plutôt du noyau VMWARE
Connaissant peut l'outil, je ne saurait trop me prononcer.