Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

sans doute un problème de route avec OpenVpn sous windows

10 réponses
Avatar
jean declercq
Bonjour,

Je croyais avoir compris le principe de fonctionnement des routes,
apparemment ça n'est pas vraiement le cas.

Je tente de monter un tunnel vpn entre un poste de mon réseau
d'entreprise et un pc portable.

J'ai installé la partie serveur de openvpn sur un xp pro du domaine,
idem pour la partie client (ie sur un xp pro aussi).

Après avoir paramétré la connexion de façon correcte (je pense), je
démarre le serveur, puis le client.
J'ai bien sur redirigé le port adéquat dans le routeur du LAN

Le client se connecte bien au serveur (en 192.168.1.48 et 10.8.0.1),
une adresse ip lui est attribuée (10.8.0.6).

Je peux sans soucis faire un ping depuis le client vers le serveur en
10.8.0.1.

Mais un ping vers 192.168.1.48 ne donne rien
Et un ping du serveur vers le client (10.8.0.6) non plus (ça, c'est pas
bien grave, mais je pense que c'est un signe).

Je peux par contre, depuis le client, accéder aux partages du serveur
(pas avec le nom netbios, mais c'est pas bien grave).

Je ne pense pas que le paramétrage du routeur soit en cause, je
pencherais donc plutôt pour un problème de route, et plutôt du coté du
serveur.

Et là je sèche.
Je ne sais pas exactement quoi rajouter/modifier dans le paramétrage du
serveur, ni comment le faire (un route add d'après ce que j'ai compris,
mais je ne suis pas certain).

Le but final étant, pour le pc portable "client", de pouvoir accéder
aux partages des autres machines du réseau (en 192.168.1.x masque
255.255.255.0)

Si une bonne âme pouvait me donner quelques explications, ou un lien
qui me permettrait d'avancer (les docs trouvées sur internet ne m'ont
pas ouvert les yeux).

Merci d'avance

--
Jean Declercq
message écrit sur un spam 100% recyclé

10 réponses

Avatar
jean declercq
jean declercq a écrit le 26/09/2006 dans
:

Bonjour


Je croyais avoir compris le principe de fonctionnement des routes,
apparemment ça n'est pas vraiment le cas.



Ma question n'a visiblement pas inspiré grand'monde.

Peut-être était-elle mal formulée, ou incomplète, voir hors-charte?

Ce qui me chagrine le plus, c'est de ne pas pouvoir pinguer l'adresse
en 192.168 de mon serveur.

Et je dois avouer que j'ai beaucoup de mal à déchiffrer la table de
routage affichée par XP avec un "route print".

Existe-t-il un site expliquant par le détail comment "lire" le résultat
affiché par cette commande ?

Merci d'avance

Si ça peut aider, ci-dessous le résultat du "route print".

****
Microsoft Windows XP [version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

c:>route print
========================================================================== Liste d'Interfaces
0x1 ........................... MS TCP Loopback interface
0x30002 ...00 0d 56 12 95 80 ...... Intel(R) PRO/1000 MT Network
Connection - Mi
niport d'ordonnancement de paquets
0x30003 ...00 ff f7 c4 5b fa ...... TAP-Win32 Adapter V8 - Miniport
d'ordonnance
ment 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.1.155 192.168.1.48
20
10.8.0.0 255.255.255.252 10.8.0.1 10.8.0.1
30
10.8.0.0 255.255.255.0 10.8.0.2 10.8.0.1
1
10.8.0.1 255.255.255.255 127.0.0.1 127.0.0.1
30
10.255.255.255 255.255.255.255 10.8.0.1 10.8.0.1
30
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
1
192.168.1.0 255.255.255.0 192.168.1.48 192.168.1.48
20
192.168.1.48 255.255.255.255 127.0.0.1 127.0.0.1
20
192.168.1.255 255.255.255.255 192.168.1.48 192.168.1.48
20
224.0.0.0 240.0.0.0 10.8.0.1 10.8.0.1
30
224.0.0.0 240.0.0.0 192.168.1.48 192.168.1.48
20
255.255.255.255 255.255.255.255 10.8.0.1 10.8.0.1
1
255.255.255.255 255.255.255.255 192.168.1.48 192.168.1.48
1
Passerelle par défaut : 192.168.1.155
========================================================================== Itinéraires persistants :
Aucun

****

--
Jean Declercq
message écrit sur un spam 100% recyclé

Avatar
Pascal Hambourg
Salut,


Ma question n'a visiblement pas inspiré grand'monde.

Peut-être était-elle mal formulée, ou incomplète, voir hors-charte?


Hors charte, non. Mal formulée, je ne trouve pas. Incomplète, peut-être.
Mais quel exposé peut se vanter d'être exhaustif ? je voudrais bien te
répondre, mais l'ennui c'est que n'utilisant pas OpenVPN - j'en connais
juste le principe et les grandes lignes - je suis mal placé pour en parler.

Et je dois avouer que j'ai beaucoup de mal à déchiffrer la table de
routage affichée par XP avec un "route print".


Sur ce point je pense pouvoir t'aider.

Je pense que tu n'as pas besoin d'explication concernant les colonnes
"Destination réseau" et "Masque réseau" qui spécifient le préfixe de la
destination couverte par une route. La colonne "Adr. interface" est une
façon détournée - va savoir pourquoi - d'indiquer l'interface de sortie
associée à une route. Au lieu de spécifier l'interface par son nom comme
sous Linux par exemple, c'est l'adresse de l'interface qui est indiquée.
Ainsi 127.0.0.1 représente l'interface de loopback ; 192.168.1.48
représente l'interface ethernet du réseau local ; 10.8.0.1 représente
l'interface TUN/TAP d'OpenVPN.

On pourrait penser à première vue que cette adresse est aussi l'adresse
source par défaut qui est utilisée pour communiquer avec la destination
de la route, mais ce n'est pas vrai pour les destinations locales :
l'adresse indiquée est 127.0.0.1 pour représenter l'interface de
loopback, alors que l'adresse source par défaut est identique à
l'adresse destination.

L'adresse de la colonne "Adr. passerelle" peut avoir deux
significations. Si elle est différente de l'adresse d'interface, elle
représente l'adresse de la passerelle pour joindre la destination. Si au
contraire elle identique à l'adresse d'interface, cela signifie qu'il
n'y a pas de passerelle pour cette destination, donc que la route est
directe.

Tout ceci est très logique, cohérent et intuitif, n'est-ce pas ?

Passons à l'examen de la table de routage que tu as eu la bonne idée de
fournir.

Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 192.168.1.155 192.168.1.48 20
10.8.0.0 255.255.255.252 10.8.0.1 10.8.0.1 30
10.8.0.0 255.255.255.0 10.8.0.2 10.8.0.1 1
10.8.0.1 255.255.255.255 127.0.0.1 127.0.0.1 30
10.255.255.255 255.255.255.255 10.8.0.1 10.8.0.1 30
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.1.0 255.255.255.0 192.168.1.48 192.168.1.48 20
192.168.1.48 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.1.255 255.255.255.255 192.168.1.48 192.168.1.48 20
224.0.0.0 240.0.0.0 10.8.0.1 10.8.0.1 30
224.0.0.0 240.0.0.0 192.168.1.48 192.168.1.48 20
255.255.255.255 255.255.255.255 10.8.0.1 10.8.0.1 1
255.255.255.255 255.255.255.255 192.168.1.48 192.168.1.48 1


On passe rapidement sur les destinations 224.0.0.0 et 255.255.255.255
qui sont des destinations multicast et broadcast spéciales.

L'interface ethernet a l'adresse 192.168.1.48, son sous-réseau est
192.168.1.0/24 avec fort logiquement l'adresse de broadcast
192.168.1.255, et la passerelle de la route par défaut 192.168.1.155.

L'interface TUN/TAP d'OpenVPN a l'adresse 10.8.0.1, son sous-réseau est
10.8.0.0/30. L'adresse du client à l'autre bout du VPN devrait donc
logiquement être 10.8.0.2, les deux adresses restants du bloc /30,
10.8.0.0 et 10.8.0.3 étant réservées respectivement comme adresses de
réseau et de broadcast. Ensuite, ça se complique. Il y a une route vers
la destination 10.8.0.0/24 passant par le VPN via une passerelle dont
l'adresse est 10.8.0.2. Et l'adresse de broadcast définie est totalement
farfelue puisqu'elle est 10.255.255.255 alors qu'elle devrait être 10.8.0.3.

Tu dis dans ton premier message que l'adresse VPN affectée au client est
10.8.0.6, ce qui n'est pas cohérent avec la table de routage du serveur.
C'est peut-être pour cela que le ping ne passe que dans un sens. Mais ça
pourrait tout aussi bien venir d'un réglage de pare-feu.
Il serait intéressant que tu fournisses la table de routage du client
ainsi que la sortie de la commande "ipconfig /all" quand le VPN est établi.

Aussi, ton VPN est-il de type ponté (bridged) ou routé ? Il me semble
que les anciennes versions d'OpenVPN ne supportaient que le mode ponté
sous Windows, mais les dernières versions supportent aussi le mode routé.

Ce qui me chagrine le plus, c'est de ne pas pouvoir pinguer l'adresse en
192.168 de mon serveur.


Pour cela, lorsque le VPN est établi, il faut que sur le poste client
soit définie une route vers la destination 192.168.1.0/24 ayant pour
passerelle l'adresse VPN du serveur, 10.8.0.1.

Toutefois pour joindre le réseau local du serveur, il faudra en plus que
le serveur fasse du routage et peut-être du NAT. A moins que tu
choisisses de ponter l'interface VPN et l'interface LAN ensemble, si
c'est possible (ce dont je n'ai pas la moindre idée, n'utilisant ni
OpenVPN ni Windows XP). Dans ce cas, l'interface VPN du client sera vue
comme faisant partie du LAN du serveur.

Avatar
jean declercq
Pascal Hambourg a écrit le 02/10/2006 dans
<efrf83$1t1l$ :


Bonjour Pascal.


Et je dois avouer que j'ai beaucoup de mal à déchiffrer la table de routage
affichée par XP avec un "route print".


Sur ce point je pense pouvoir t'aider.



Génial!

Bien. J'étudie tout ça, j'essaye de bien comprendre tout ce que
m'indiquent les "route print" et "ipconfig/all" des deux machines et je
reviens avec mes réflexions.
Tu l'as sans doute compris, ça ne m'intéresse pas plus que ça de
fournir les données "brutes" et que tu me donnes la soluce toute cuite,
que je pourrais appliquer sans me poser de questions.
Ce que j'aimerais bien, c'est comprendre ce que je fais ;-)

...mais ça m'étonnerai malgré tout que je n'ai pas besoin d'un petit
coup de pouce supplémentaire ;o)

Merci pour les infos.

à ...un peu plus tard.

--
Jean Declercq
message écrit sur un spam 100% recyclé


Avatar
Pascal Hambourg

Tu l'as sans doute compris, ça ne m'intéresse pas plus que ça de fournir
les données "brutes" et que tu me donnes la soluce toute cuite, que je
pourrais appliquer sans me poser de questions.


Je te promets que je ne te donnerai pas de solution toute cuite pour ta
configuration d'OpenVPN. Pas dur, je n'y connais rien. :-D

Avatar
jean declercq
Pascal Hambourg a écrit le 03/10/2006 dans
<eft9np$2l53$ :


Je te promets que je ne te donnerai pas de solution toute cuite pour ta
configuration d'OpenVPN. Pas dur, je n'y connais rien. :-D


Bon, pour l'instant c'est pas gagné.
J'ai du me séparer hier du portable avec lequel je faisais mes essais.
J'en ai récupéré un autre, que j'ai configuré.
Pour l'instant, la connexion client<->serveur se fait, mais l'interface
TUN/TAP ne récupère qu'une adresse apipa.
Il y aurait soit-disant un serveur dhcp en 10.8.0.49...

Ca va occuper mes longues soirées pluvieuses d'automne, je le sens ;-)

--
Jean Declercq
message écrit sur un spam 100% recyclé

Avatar
jean declercq
Pascal Hambourg a écrit le 02/10/2006 dans
<efrf83$1t1l$ :


Bien, ça avance.
Il y a encore pas mal de points un peu confus, mais ça avance.

Avec le deuxième machine, je n'arrivais donc à rien, même pas à pinguer
le serveur openvpn en 10.8.0.1

En désespoir de cause, j'ai désinstallé openvpn, puis réinstallé (la
désinstallation n'efface pas la configuration).
Et bien ça fonctionne (avec donc exactement la même config pour le
client OpenVpn).
Je soupçonne donc un mélange de pinceau de XP, mais je crois que je ne
le saurai jamais vraiment.

Depuis, j'ai rajouté dans la configuration du serveur une route à
transmettre au client (une commande push "route 192.168.1.0
255.255.255.0").
Le résultat: un ping sur 192.168.1.48 (l'adresse "lan" du serveur
openvpn) fonctionne.

Par contre un ping sur d'autres machines du réseau (le W2K server par
exemple en 192.168.1.100) ne fonctionne pas encore.

Je mets ici les configurations des différentes machines:

Le serveur openvpn:
*******************

Nom de l'hôte . . . . . . . . . . : jdexp
Suffixe DNS principal . . . . . . :
Type de noud . . . . . . . . . . : Hybride
Routage IP activé . . . . . . . . : Oui
Proxy WINS activé . . . . . . . . : Non

Carte Ethernet Connexion au réseau local:

Suffixe DNS propre à la connexion :
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT
Network Connect
ion
Adresse physique . . . . . . . . .: 00-0D-56-12-95-80
DHCP activé. . . . . . . . . . . : Non
Adresse IP. . . . . . . . . . . . : 192.168.1.48
Masque de sous-réseau . . . . . . : 255.255.255.0
Passerelle par défaut . . . . . . : 192.168.1.155
Serveurs DNS . . . . . . . . . . : 192.168.1.1
192.168.1.155
Serveur WINS principal. . . . . . : 192.168.1.1

Carte Ethernet Connexion VPN OpenVpn:

Suffixe DNS propre à la connexion :
Description . . . . . . . . . . . : TAP-Win32 Adapter V8
Adresse physique . . . . . . . . .: 00-FF-F7-C4-5B-FA
DHCP activé. . . . . . . . . . . : Oui
Configuration automatique activée . . . . : Oui
Adresse IP. . . . . . . . . . . . : 10.8.0.1
Masque de sous-réseau . . . . . . : 255.255.255.252
Passerelle par défaut . . . . . . :
Serveur DHCP. . . . . . . . . . . : 10.8.0.2
Bail obtenu . . . . . . . . . . . : mercredi 4 octobre 2006
17:53:42
Bail expirant . . . . . . . . . . : jeudi 4 octobre 2007
17:53:42

========================================================================== Liste d'Interfaces
0x1 ........................... MS TCP Loopback interface
0x30002 ...00 0d 56 12 95 80 ...... Intel(R) PRO/1000 MT Network
Connection - Mi
niport d'ordonnancement de paquets
0x50003 ...00 ff f7 c4 5b fa ...... TAP-Win32 Adapter V8 - Miniport
d'ordonnance
ment 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.1.155 192.168.1.48
20
10.8.0.0 255.255.255.252 10.8.0.1 10.8.0.1
30
10.8.0.0 255.255.255.0 10.8.0.2 10.8.0.1
1
10.8.0.1 255.255.255.255 127.0.0.1 127.0.0.1
30
10.255.255.255 255.255.255.255 10.8.0.1 10.8.0.1
30
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
1
192.168.1.0 255.255.255.0 192.168.1.48 192.168.1.48
20
192.168.1.48 255.255.255.255 127.0.0.1 127.0.0.1
20
192.168.1.255 255.255.255.255 192.168.1.48 192.168.1.48
20
224.0.0.0 240.0.0.0 10.8.0.1 10.8.0.1
30
224.0.0.0 240.0.0.0 192.168.1.48 192.168.1.48
20
255.255.255.255 255.255.255.255 10.8.0.1 10.8.0.1
1
255.255.255.255 255.255.255.255 192.168.1.48 192.168.1.48
1
Passerelle par défaut : 192.168.1.155
========================================================================== Itinéraires persistants :
Aucun

Le client openvpn:
******************
Nom de l'hôte . . . . . . . . . . : portablejde
Suffixe DNS principal . . . . . . :
Type de noud . . . . . . . . . . : Hybride
Routage IP activé . . . . . . . . : Non
Proxy WINS activé . . . . . . . . : Non

Carte Ethernet Connexion OpenVPN:

Suffixe DNS propre à la connexion :
Description . . . . . . . . . . . : TAP-Win32 Adapter V8
Adresse physique . . . . . . . . .: 00-FF-09-7B-C2-08
DHCP activé. . . . . . . . . . . : Oui
Configuration automatique activée . . . . : Oui
Adresse IP. . . . . . . . . . . . : 10.8.0.6
Masque de sous-réseau . . . . . . : 255.255.255.252
Passerelle par défaut . . . . . . :
Serveur DHCP. . . . . . . . . . . : 10.8.0.5
Bail obtenu . . . . . . . . . . . : jeudi 5 octobre 2006
10:05:31
Bail expirant . . . . . . . . . . : vendredi 5 octobre 2007
10:05:31

Carte Ethernet Connexion au réseau local:

Statut du média . . . . . . . . . : Média déconnecté
Description . . . . . . . . . . . : National Semiconductor
Corp. DP83815
/816 10/100 MacPhyter PCI Adapter
Adresse physique . . . . . . . . .: 00-0D-9D-CC-2C-9C

Carte PPP Wanadoo accès libre :

Suffixe DNS propre à la connexion :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Adresse physique . . . . . . . . .: 00-53-45-00-00-00
DHCP activé. . . . . . . . . . . : Non
Adresse IP. . . . . . . . . . . . : 193.249.232.113
Masque de sous-réseau . . . . . . : 255.255.255.255
Passerelle par défaut . . . . . . : 193.249.232.113
Serveurs DNS . . . . . . . . . . : 80.10.246.5
80.10.246.136

========================================================================== Liste d'Interfaces
0x1 ........................... MS TCP Loopback interface
0x2 ...00 ff 09 7b c2 08 ...... TAP-Win32 Adapter V8 - Miniport
d'ordonnancement
de paquets
0x10004 ...00 0d 9d cc 2c 9c ...... National Semiconductor Corp.
DP83815/816 10/
100 MacPhyter PCI Adapter - Miniport d'ordonnancement de paquets
0x20005 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
========================================================================== ========================================================================== Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface
Métrique
0.0.0.0 0.0.0.0 193.249.232.113 193.249.232.113
1
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.1.0 255.255.255.0 10.8.0.5 10.8.0.6
1
193.249.232.113 255.255.255.255 127.0.0.1 127.0.0.1
50
193.249.232.255 255.255.255.255 193.249.232.113 193.249.232.113
50
193.251.96.155 255.255.255.255 193.249.232.113 193.249.232.113
1
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 193.249.232.113 193.249.232.113
1
255.255.255.255 255.255.255.255 10.8.0.6 10004
1
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 193.249.232.113 193.249.232.113
1
Passerelle par défaut : 193.249.232.113
========================================================================== Itinéraires persistants :
Aucun

Le W2K server:
**************
Nom de l'hôte . . . . . . . . . . : srvcapri
Suffixe DNS principal . . . . . . : domcapri.local
Type de noud. . . . . . . . . . . : Hybride
Routage IP activé . . . . . . . . : Non
Proxy WINS activé . . . . . . . . : Non
Liste de recherche de suffixe DNS : domcapri.local

Ethernet carte Connexion au réseau local :

Suffixe DNS spéc. à la connexion. :
Description . . . . . . . . . . . : HP NC7760 Gigabit Server
Adapter
Adresse physique. . . . . . . . . : 00-0B-CD-CB-2F-3F
DHCP activé . . . . . . . . . . . : Non
Adresse IP. . . . . . . . . . . . : 192.168.1.100
Masque de sous-réseau . . . . . . : 255.255.255.0
Passerelle par défaut . . . . . . : 192.168.1.155
Serveurs DNS. . . . . . . . . . . : 192.168.1.1
Serveur WINS principal. . . . . . : 192.168.1.1


========================================================================== Liste d'Interfaces
0x1 ........................... MS TCP Loopback interface
0x1000003 ...00 0b cd cb 2f 3f ...... HP NC7760 Gigabit Server Adapter
========================================================================== ========================================================================== 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.1.155 192.168.1.100
1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
1
192.168.1.0 255.255.255.0 192.168.1.100 192.168.1.100
1
192.168.1.100 255.255.255.255 127.0.0.1 127.0.0.1
1
192.168.1.255 255.255.255.255 192.168.1.100 192.168.1.100
1
224.0.0.0 224.0.0.0 192.168.1.100 192.168.1.100
1
255.255.255.255 255.255.255.255 192.168.1.100 192.168.1.100
1
Passerelle par défaut : 192.168.1.155
========================================================================== Itinéraires persistants :
Aucun


Toujours d'après ce que j'ai compris, il faut indiquer sur le W2K (par
exemple) une route pour le retour.
C'est bien ça?

Je vais expliquer avec mes mots à moi que j'ai, et merci de ne pas se
moquer ;o)

Quand 192.168.1.48 (machine A) envoie un ping à 192.168.1.100 (machine
B), B sait qu'il doit renvoyer la réponse à A.
Mais quand c'est 10.8.0.6 (machine C) qui envoie le ping à B, B ne sait
pas comment joindre C et est incapable de répondre.
Il faut donc rajouter une route sur B pour lui indiquer que tout ce qui
vient de 10.8.0.* doit passer par A.

C'est à peu près ça?

Donc, toujours si j'ai bien compris, je rajoute sur B:

destin. masque passerelle interface
10.8.0.0 255.255.255.0 192.168.1.48 192.168.1.48

J'ai un gros doute pour l'interface, je ne dois pas avoir bien saisit
sa signification.


Aussi, ton VPN est-il de type ponté (bridged) ou routé ? Il me semble que les
anciennes versions d'OpenVPN ne supportaient que le mode ponté sous Windows,
mais les dernières versions supportent aussi le mode routé.


Il est routé.


Pour cela, lorsque le VPN est établi, il faut que sur le poste client soit
définie une route vers la destination 192.168.1.0/24 ayant pour passerelle
l'adresse VPN du serveur, 10.8.0.1.


Celle-là c'est bon, je l'ai sur le client, mais pas exactement comme tu
l'indiques.

192.168.1.0 255.255.255.0 10.8.0.5 10.8.0.6



Toutefois pour joindre le réseau local du serveur, il faudra en plus que le
serveur fasse du routage et peut-être du NAT. A moins que tu choisisses de
ponter l'interface VPN et l'interface LAN ensemble, si c'est possible (ce
dont je n'ai pas la moindre idée, n'utilisant ni OpenVPN ni Windows XP). Dans
ce cas, l'interface VPN du client sera vue comme faisant partie du LAN du
serveur.


J'ai activé, comme indiqué dans la doc openvpn, le routage IP sur A, le
serveur openvpn (on le voit dans son "ipconfig").

Si quelqu'un peut confirmer ou corriger la route à rajouter sur B.

Ah oui, aussi:
1/ en utilisant la commande "route add", je dois utiliser le
commutateur -p pour conserver cette route, c'est bien ça?
2/ pour indiquer 'interface, il faut utiliser IF puis le numéro
d'interface. A quoi correspond ce numéro?
3/ il faut indiquer la métrique. Je dois utiliser une métrique plus
grande que 1 ?

Merci d'avance.

--
Jean Declercq
message écrit sur un spam 100% recyclé

Avatar
Pascal Hambourg

Je mets ici les configurations des différentes machines:


[Je coupe pour ne garder que ce qui est utile]

Le serveur openvpn:
*******************
Carte Ethernet Connexion VPN OpenVpn:
Description . . . . . . . . . . . : TAP-Win32 Adapter V8
Adresse physique . . . . . . . . .: 00-FF-F7-C4-5B-FA
DHCP activé. . . . . . . . . . . : Oui
Configuration automatique activée . . . . : Oui
Adresse IP. . . . . . . . . . . . : 10.8.0.1
Masque de sous-réseau . . . . . . : 255.255.255.252
Serveur DHCP. . . . . . . . . . . : 10.8.0.2
========================================================================== > Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
10.8.0.0 255.255.255.252 10.8.0.1 10.8.0.1 30
10.8.0.0 255.255.255.0 10.8.0.2 10.8.0.1 1
10.8.0.1 255.255.255.255 127.0.0.1 127.0.0.1 30

Le client openvpn:
******************
Carte Ethernet Connexion OpenVPN:
Description . . . . . . . . . . . : TAP-Win32 Adapter V8
Adresse physique . . . . . . . . .: 00-FF-09-7B-C2-08
DHCP activé. . . . . . . . . . . : Oui
Configuration automatique activée . . . . : Oui
Adresse IP. . . . . . . . . . . . : 10.8.0.6
Masque de sous-réseau . . . . . . : 255.255.255.252
Serveur DHCP. . . . . . . . . . . : 10.8.0.5
========================================================================== > Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
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
192.168.1.0 255.255.255.0 10.8.0.5 10.8.0.6 1

Le W2K server:
**************
Ethernet carte Connexion au réseau local :
Description . . . . . . . . . . . : HP NC7760 Gigabit Server Adapter
Adresse physique. . . . . . . . . : 00-0B-CD-CB-2F-3F
DHCP activé . . . . . . . . . . . : Non
Adresse IP. . . . . . . . . . . . : 192.168.1.100
Masque de sous-réseau . . . . . . : 255.255.255.0
Passerelle par défaut . . . . . . : 192.168.1.155
========================================================================== > 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.1.155 192.168.1.100 1
192.168.1.0 255.255.255.0 192.168.1.100 192.168.1.100 1
192.168.1.100 255.255.255.255 127.0.0.1 127.0.0.1 1


Je crois que je commence à comprendre.
Donc, si j'ai bien compris :
De chaque côté, OpenVPN émule sur l'autre adresse IP du /30 un hôte
virtuel qui sert à la fois de serveur DHCP pour attribuer l'adresse IP à
l'interface TUN/TAP et de passerelle pour joindre l'autre bout du VPN
10.8.0.0/24. C'est vraiment tordu !

La structure "logique" de la liaison VPN est composée de 3 segments dont
deux sont purement virtuels et émulés de chaque côté :

10.8.0.4/30 10.8.0.0/24 10.8.0.0/30
client ------- DHCP/passerelle ---VPN--- DHCP/passerelle ------- serveur
10.8.0.6/30 10.8.0.5/30 10.8.0.2/30 10.8.0.1/30

Toujours d'après ce que j'ai compris, il faut indiquer sur le W2K (par
exemple) une route pour le retour.
C'est bien ça?


Oui. Ou bien si possible on peut ajouter cette route sur la machine qui
sert de passerelle par défaut. Ainsi pas besoin de l'ajouter sur toutes
les machines du réseau local avec lesquelles le client OpenVPN doit
communiquer.

Je vais expliquer avec mes mots à moi que j'ai, et merci de ne pas se
moquer ;o)

Quand 192.168.1.48 (machine A) envoie un ping à 192.168.1.100 (machine
B), B sait qu'il doit renvoyer la réponse à A.
Mais quand c'est 10.8.0.6 (machine C) qui envoie le ping à B, B ne sait
pas comment joindre C et est incapable de répondre.
Il faut donc rajouter une route sur B pour lui indiquer que tout ce qui
vient de 10.8.0.* doit passer par A.

C'est à peu près ça?


Presque. En fait B sait toujours qu'il doit répondre à A quand A lui
envoie un ping. La question est de savoir *comment* il fait pour envoyer
la réponse. C'est sa table de routage qui donne la réponse. Il recherche
la route la plus précise contenant la destination. En l'absence de route
"explicite", c'est la route par défaut qui est suivie. En l'absence de
route par défaut, A est injoignable.

Donc ici B sait ou du moins croit savoir comment joindre A : via la
passerelle par défaut. Mais si la passerelle par défaut n'a pas la bonne
route pour joindre A, elle va aussi utiliser sa propre route par défaut
et envoyer la réponse se perdre sur internet.

La solution consiste donc à indiquer à B ou à sa passerelle par défaut
quelle est la passerelle pour joindre A.

Donc, toujours si j'ai bien compris, je rajoute sur B:


Ou sur sa passerelle par défaut.

destin. masque passerelle interface
10.8.0.0 255.255.255.0 192.168.1.48 192.168.1.48

J'ai un gros doute pour l'interface, je ne dois pas avoir bien saisit sa
signification.


De toute façon tu n'as pas besoin de t'en occuper. La bonne interface
sera sélectionnée en fonction de l'adresse de passerelle.

Aussi, ton VPN est-il de type ponté (bridged) ou routé ? Il me semble
que les anciennes versions d'OpenVPN ne supportaient que le mode ponté
sous Windows, mais les dernières versions supportent aussi le mode routé.


Il est routé.


C'est bizarre, parce qu'il a une bonne tête de ponté, avec des adresses
MAC, du DHCP et tout et tout. Mais peut-être que sous Windows on ne peut
pas faire autrement (même les interface PPP ont une pseudo-adresse MAC).

Pour cela, lorsque le VPN est établi, il faut que sur le poste client
soit définie une route vers la destination 192.168.1.0/24 ayant pour
passerelle l'adresse VPN du serveur, 10.8.0.1.


Celle-là c'est bon, je l'ai sur le client, mais pas exactement comme tu
l'indiques.

192.168.1.0 255.255.255.0 10.8.0.5 10.8.0.6


Oui, voir plus haut pour l'explication. 10.8.0.6 est une passerelle
virtuelle pour atteindre l'autre bout du VPN.

Ah oui, aussi:
1/ en utilisant la commande "route add", je dois utiliser le commutateur
-p pour conserver cette route, c'est bien ça?


Oui.

2/ pour indiquer 'interface, il faut utiliser IF puis le numéro
d'interface. A quoi correspond ce numéro?


Je ne sais pas vraiment, la gestion des interfaces dans Windows étant
tout sauf claire. Mais de toute façon, comme je l'ai dit plus haut tu
n'as pas besoin de spécifier l'interface.

3/ il faut indiquer la métrique. Je dois utiliser une métrique plus
grande que 1 ?


La métrique n'est pas obligatoire. Elle ne sert qu'à départager
plusieurs routes concurrentes pour une même destination.

Commentaire personnel : apparemment, Windows est aussi à la rue
concernant l'adresse de broadcast dirigé avec la liaison PPP qu'avec la
liaison OpenVPN.

Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
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
193.249.232.113 255.255.255.255 127.0.0.1 127.0.0.1 50
193.249.232.255 255.255.255.255 193.249.232.113 193.249.232.113 50


Alors que l'interface VPN (10.8.0.6/30) devrait avoir pour adresse de
broadcast 10.8.0.7 et que l'interface PPP (193.249.232.113/32) ne
devrait pas avoir d'adresse de broadcast. Vraiment n'importe quoi...


Avatar
jean declercq
Pascal Hambourg a écrit le 05/10/2006 dans
<eg2qkm$1svs$ :


[Je coupe pour ne garder que ce qui est utile]



Pareil ;-)


Je crois que je commence à comprendre.
Donc, si j'ai bien compris :
De chaque côté, OpenVPN émule sur l'autre adresse IP du /30 un hôte virtuel
qui sert à la fois de serveur DHCP pour attribuer l'adresse IP à l'interface
TUN/TAP et de passerelle pour joindre l'autre bout du VPN 10.8.0.0/24. C'est
vraiment tordu !


C'est à peu près ce que j'avais "pressenti" quand je me suis penché
vraiment sur la config qui commençait à fonctionner, mais je ne
l'aurais certainement pas expliqué aussi clairement.


La structure "logique" de la liaison VPN est composée de 3 segments dont deux
sont purement virtuels et émulés de chaque côté :

10.8.0.4/30 10.8.0.0/24 10.8.0.0/30
client ------- DHCP/passerelle ---VPN--- DHCP/passerelle ------- serveur
10.8.0.6/30 10.8.0.5/30 10.8.0.2/30 10.8.0.1/30



Ca, il faut que je laisse refroidir ma p'tite tête avant de me pencher
dessus.
Mon problème, c'est que je comprends "à peu près" ce schéma, mais pour
le réexpliquer, tintin.

Mais ça va viendre, je ne désespère pas ;o)


Oui. Ou bien si possible on peut ajouter cette route sur la machine qui sert
de passerelle par défaut. Ainsi pas besoin de l'ajouter sur toutes les
machines du réseau local avec lesquelles le client OpenVPN doit communiquer.



Génial!

J'ai ça sur mon routeur adsl (la passerelle)
Je suis allé ici:
http://cjoint.com/?kfpeACZeRt

et j'obtiens ça:
http://cjoint.com/?kfpfm6xPos

Et voilà, ça fonctionne.
Je peux atteindre mes machines par leur nom netbios, utiliser les
imprimantes, les sessions TSE fonctionnent.
Bref, le bonheur.

Je vais expliquer avec mes mots à moi que j'ai, et merci de ne pas se
moquer ;o)

C'est à peu près ça?


Presque.


Qu'est-ce que tu parles bien! ;o)
En tout cas c'est très clair.

Donc, toujours si j'ai bien compris, je rajoute sur B:


Ou sur sa passerelle par défaut.


Bien plus facile.
Par contre, dans ce cas, tout mon lan est visible et joignable.
Bof, pas bien grave, les autorisations sont en place.



J'ai un gros doute pour l'interface, je ne dois pas avoir bien saisit sa
signification.


De toute façon tu n'as pas besoin de t'en occuper. La bonne interface sera
sélectionnée en fonction de l'adresse de passerelle.


Alors ça va.
... pour l'instant
Mais il faudra bien que je finisse aussi par comprendre ce que c'est
exactement.

Il est routé.


C'est bizarre, parce qu'il a une bonne tête de ponté, avec des adresses MAC,
du DHCP et tout et tout. Mais peut-être que sous Windows on ne peut pas faire
autrement (même les interface PPP ont une pseudo-adresse MAC).



C'est explicitement indiqué dans le fichier de conf. d'OpenVPN.

1/
2/
3/



Ca, je le garde bien au chaud sous le coude au cas où.
POur l'instant donc je n'en ai pas eu besoin, j'ai créé une route sur
la passerelle par défaut.


Commentaire personnel : apparemment, Windows est aussi à la rue concernant
l'adresse de broadcast dirigé avec la liaison PPP qu'avec la liaison OpenVPN.
Alors que l'interface VPN (10.8.0.6/30) devrait avoir pour adresse de
broadcast 10.8.0.7 et que l'interface PPP (193.249.232.113/32) ne devrait pas
avoir d'adresse de broadcast. Vraiment n'importe quoi...


Il faudrait que je compare avec ce qua ça donne sur d'autres systèmes,
pour pouvoir voir la différence...

En tout cas je te remercie beaucoup pour ton aide, ça fonctionne et en
plus j'ai beaucoup appris (mais y'a encore du boulot ;-) ) avec tes
explications.

Amicalement

--
Jean Declercq
message écrit sur un spam 100% recyclé


Avatar
Pascal Hambourg

[Je coupe pour ne garder que ce qui est utile]


Pareil ;-)


Bien, mais attention à ne pas trop couper. Parfois j'ai dû relire mon
message précédent pour me rappeler à quoi tu répondais.

La structure "logique" de la liaison VPN est composée de 3 segments
dont deux sont purement virtuels et émulés de chaque côté :

10.8.0.4/30 10.8.0.0/24 10.8.0.0/30
client ------- DHCP/passerelle ---VPN--- DHCP/passerelle ------- serveur
10.8.0.6/30 10.8.0.5/30 10.8.0.2/30 10.8.0.1/30


Ca, il faut que je laisse refroidir ma p'tite tête avant de me pencher
dessus.
Mon problème, c'est que je comprends "à peu près" ce schéma, mais pour
le réexpliquer, tintin.


Une précision, peut-être : j'ai mis au dessus des liaisons virtuelles
(représentées par des ---) le sous-réseau IP correspondant, et sous les
noms d'hôtes réels ou virtuels leurs adresse IP et masque. Le tout en
notation CIDR qui ne te pose pas de problème, j'espère.

Je peux atteindre mes machines par leur nom netbios, utiliser les
imprimantes, les sessions TSE fonctionnent.


Je n'aurais pas cru que les noms Netbios fonctionneraient à travers le
VPN. Normalement les annonces de noms Netbios ne traversent pas les
routeurs, et je n'ai pas vu de WINS dans la configuration du client.

Commentaire personnel : apparemment, Windows est aussi à la rue
concernant l'adresse de broadcast dirigé avec la liaison PPP qu'avec
la liaison OpenVPN.
Alors que l'interface VPN (10.8.0.6/30) devrait avoir pour adresse de
broadcast 10.8.0.7 et que l'interface PPP (193.249.232.113/32) ne
devrait pas avoir d'adresse de broadcast. Vraiment n'importe quoi...


Il faudrait que je compare avec ce qua ça donne sur d'autres systèmes,
pour pouvoir voir la différence...


Si tu veux comparer avec Linux, il va falloir aller chercher les routes
broadcast dans une table de routage spéciale nommée 'local', avec la
commande 'ip route list table local type broadcast' d'iproute(2).

En tout cas je te remercie beaucoup pour ton aide, ça fonctionne et en
plus j'ai beaucoup appris (mais y'a encore du boulot ;-) ) avec tes
explications.


De rien, ça change des sempiternels problèmes de partage de connexion
internet, de redirection de port ou de FTP actif/passif. :-)


Avatar
jean declercq
Pascal Hambourg a écrit le 05/10/2006 dans
<eg33s0$20mn$ :


Bien, mais attention à ne pas trop couper. Parfois j'ai dû relire mon message
précédent pour me rappeler à quoi tu répondais.


Quand ça commence à faire du volume, c'est pas toujours simple de bien
choisir où poser la tronçonneuse.
J'aurais glissé ? ;o)



10.8.0.4/30 10.8.0.0/24 10.8.0.0/30
client ------- DHCP/passerelle ---VPN--- DHCP/passerelle ------- serveur
10.8.0.6/30 10.8.0.5/30 10.8.0.2/30 10.8.0.1/30




Une précision, peut-être : j'ai mis au dessus des liaisons virtuelles
(représentées par des ---) le sous-réseau IP correspondant, et sous les noms
d'hôtes réels ou virtuels leurs adresse IP et masque. Le tout en notation
CIDR qui ne te pose pas de problème, j'espère.


Oui, j'ai bien vu que tu t'étais donné du mal.

Pas de soucis pour la notation CIDR, il suffit simplement que je
ressorte le "manuel", une feuille de papier et un crayon :-)


Je peux atteindre mes machines par leur nom netbios, utiliser les
imprimantes, les sessions TSE fonctionnent.


Je n'aurais pas cru que les noms Netbios fonctionneraient à travers le VPN.
Normalement les annonces de noms Netbios ne traversent pas les routeurs, et
je n'ai pas vu de WINS dans la configuration du client.



C'est vrai.
Cette machine (le client) est souvent connectée directement au lan.
Il y aurait des "restes"?


Si tu veux comparer avec Linux, il va falloir aller chercher les routes
broadcast dans une table de routage spéciale nommée 'local', avec la commande
'ip route list table local type broadcast' d'iproute(2).



Tiens, ça pourrait être une idée, puisque OpenVpn tourne aussi
(surtout?) avec Linux.
Mon portable (le client), a un double boot avec une vieille Kaella.

Mais je ne suis déjà pas très à l'aise avec Linux...
Ca risque d'être bien galère.

Merci encore.

--
Jean Declercq
message écrit sur un spam 100% recyclé