VPN client Windows -> Serveur Debian

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

VPN client Windows -> Serveur Debian

Tekpi
Bonjour à tous,

je dois mettre en place un vpn sur un serveur debian pour une connexion à distance sur des postes Windows XP Pro.

J'ai testé toute la journée des configs de PPTP (poptop), sans succès, apparemment le protocole GRE est mal géré par le nat de mon routeur.

Quelle solution me proposez vous?
Le client se connectera à la demande via son Windows.

La config est :

Client Windows XP Pro -> Routeur provider (gene livebox) -> Internet -> Routeur entreprise -> Debian noyau 2.6.20 -> lan

A moins que vous n'ayez une idée pour le pptp.

merci pour vos réponses
Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Pascal Hambourg
Salut,

Tekpi a écrit :
>
> je dois mettre en place un vpn sur un serveur debian pour une connexion à
> distance sur des postes Windows XP Pro.
>
> J'ai testé toute la journée des configs de PPTP (poptop), sans succès,
> apparemment le protocole GRE est mal géré par le nat de mon routeur.

Il arrive effectivement que certains routeurs/firewalls/NAT aient du mal
avec les protocoles IP autres que TCP, UDP et ICMP tels que GRE. Pas
d'option "PPTP pass-through" ou "VPN pass-through" ? Si ça concerne le
routeur côté serveur, redirection du port TCP 1723 et du protocole GRE
vers le serveur, ou bien mise en "DMZ" du serveur ?

Accessoirement, garder à l'esprit que PPTP est plus un protocole de
tunnel pour transporter PPP qu'un VPN. La confidentialité doit être
assurée au niveau des options de la session PPP.

> Quelle solution me proposez vous?
> Le client se connectera à la demande via son Windows.

OpenVPN. Disponible sur les deux OS parmi d'autres, transport UDP ou TCP
facile à NATer, chiffrement SSL, fonctionnement en émulation ethernet
(TAP) ou en liaison routée point à point (TUN) supportant IPv4 et IPv6,
exécution de scripts, possibilité pour le serveur de "pousser" des
routes sur le client...

Il y a bien le VPN L2TP/IPSec intégré à Windows, mais j'ai cru
comprendre que c'était un peu l'usine à gaz à faire marcher sous Linux.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Vincent Bernat
OoO  Lors de  la soirée  naissante du  vendredi 02  novembre  2007, vers
17:22, Pascal Hambourg <[hidden email]> disait:

> Il y a bien le VPN L2TP/IPSec intégré à Windows, mais j'ai cru
> comprendre que c'était un peu l'usine à gaz à faire marcher sous
> Linux.

Les projets  de type l2tpd me  semblent également au  point mort. Debian
dispose de xl2tpd qui semble encore maintenu. À essayer.
--
Choose variable names that won't be confused.
            - The Elements of Programming Style (Kernighan & Plauger)


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Jean-Yves F. Barbier
In reply to this post by Pascal Hambourg
je confirme ce que dit Pascal: OpenVPN

C'est vrai que c'est un peu chibavant à mettre au point (je peux te passer
mes fichiers de conf/démarrage auto hors liste si tu veux)
mais une fois règlé, et avec OpenVPN-GUI sur les XP (et un ch'tit raccourci
dans le groupe démarrage pour une exé auto), c'est un vrai régal
et tu oublies vite le temps passé en mise-au-point (et ça arrive même
à passer sans PB à travers les routers de SFR :)

JY

Pascal Hambourg a écrit :

> Salut,
>
> Tekpi a écrit :
>>
>> je dois mettre en place un vpn sur un serveur debian pour une connexion à
>> distance sur des postes Windows XP Pro.
>>
>> J'ai testé toute la journée des configs de PPTP (poptop), sans succès,
>> apparemment le protocole GRE est mal géré par le nat de mon routeur.
>
> Il arrive effectivement que certains routeurs/firewalls/NAT aient du mal
> avec les protocoles IP autres que TCP, UDP et ICMP tels que GRE. Pas
> d'option "PPTP pass-through" ou "VPN pass-through" ? Si ça concerne le
> routeur côté serveur, redirection du port TCP 1723 et du protocole GRE
> vers le serveur, ou bien mise en "DMZ" du serveur ?
>
> Accessoirement, garder à l'esprit que PPTP est plus un protocole de
> tunnel pour transporter PPP qu'un VPN. La confidentialité doit être
> assurée au niveau des options de la session PPP.
>
>> Quelle solution me proposez vous?
>> Le client se connectera à la demande via son Windows.
>
> OpenVPN. Disponible sur les deux OS parmi d'autres, transport UDP ou TCP
> facile à NATer, chiffrement SSL, fonctionnement en émulation ethernet
> (TAP) ou en liaison routée point à point (TUN) supportant IPv4 et IPv6,
> exécution de scripts, possibilité pour le serveur de "pousser" des
> routes sur le client...
>
> Il y a bien le VPN L2TP/IPSec intégré à Windows, mais j'ai cru
> comprendre que c'était un peu l'usine à gaz à faire marcher sous Linux.
>
>

--
Hamburg was fantastic. Between the whores and the groupies our dicks
all just about dropped off.
                -- John Lennon, on the Beatles' early career in Germany

Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Tekpi
merci pour ces infos.

Je m'y mets demain, j'ai potassé tout le w-e sur le sujet, + les avis sur mon post, et je trouve que c'est un outil fort intéressant (openvpn).
Je n'ai rien vu de compliqué à la mise en place, ceci dit, c'est parce que je ne suis pas devant mon linux lol.

Je te tiens au courant et merci pour tes infos.

++


Jean-Yves F. Barbier wrote
je confirme ce que dit Pascal: OpenVPN

C'est vrai que c'est un peu chibavant à mettre au point (je peux te passer
mes fichiers de conf/démarrage auto hors liste si tu veux)
mais une fois règlé, et avec OpenVPN-GUI sur les XP (et un ch'tit raccourci
dans le groupe démarrage pour une exé auto), c'est un vrai régal
et tu oublies vite le temps passé en mise-au-point (et ça arrive même
à passer sans PB à travers les routers de SFR :)

JY

Pascal Hambourg a écrit :
> Salut,
>
> Tekpi a écrit :
>>
>> je dois mettre en place un vpn sur un serveur debian pour une connexion à
>> distance sur des postes Windows XP Pro.
>>
>> J'ai testé toute la journée des configs de PPTP (poptop), sans succès,
>> apparemment le protocole GRE est mal géré par le nat de mon routeur.
>
> Il arrive effectivement que certains routeurs/firewalls/NAT aient du mal
> avec les protocoles IP autres que TCP, UDP et ICMP tels que GRE. Pas
> d'option "PPTP pass-through" ou "VPN pass-through" ? Si ça concerne le
> routeur côté serveur, redirection du port TCP 1723 et du protocole GRE
> vers le serveur, ou bien mise en "DMZ" du serveur ?
>
> Accessoirement, garder à l'esprit que PPTP est plus un protocole de
> tunnel pour transporter PPP qu'un VPN. La confidentialité doit être
> assurée au niveau des options de la session PPP.
>
>> Quelle solution me proposez vous?
>> Le client se connectera à la demande via son Windows.
>
> OpenVPN. Disponible sur les deux OS parmi d'autres, transport UDP ou TCP
> facile à NATer, chiffrement SSL, fonctionnement en émulation ethernet
> (TAP) ou en liaison routée point à point (TUN) supportant IPv4 et IPv6,
> exécution de scripts, possibilité pour le serveur de "pousser" des
> routes sur le client...
>
> Il y a bien le VPN L2TP/IPSec intégré à Windows, mais j'ai cru
> comprendre que c'était un peu l'usine à gaz à faire marcher sous Linux.
>
>

--
Hamburg was fantastic. Between the whores and the groupies our dicks
all just about dropped off.
                -- John Lennon, on the Beatles' early career in Germany
Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Tekpi
In reply to this post by Pascal Hambourg
Bonsoir,

mon routeur est bien configuré en vpn pass-through pour les connexions vpn de type ipsec, pptp, l2tp, malheureusement je vois mon linux qui envoie des requêtes lcp sans réponses... j'en conclue qu'il y a un pb de nat entre mon routeur et mon linux.

Je vais donc passer par du openvpn, suite à ton conseil et ce de mon post.

Merci d'avoir pris le temps de me répondre

++


Pascal Hambourg wrote
Salut,

Tekpi a écrit :
>
> je dois mettre en place un vpn sur un serveur debian pour une connexion à
> distance sur des postes Windows XP Pro.
>
> J'ai testé toute la journée des configs de PPTP (poptop), sans succès,
> apparemment le protocole GRE est mal géré par le nat de mon routeur.

Il arrive effectivement que certains routeurs/firewalls/NAT aient du mal
avec les protocoles IP autres que TCP, UDP et ICMP tels que GRE. Pas
d'option "PPTP pass-through" ou "VPN pass-through" ? Si ça concerne le
routeur côté serveur, redirection du port TCP 1723 et du protocole GRE
vers le serveur, ou bien mise en "DMZ" du serveur ?

Accessoirement, garder à l'esprit que PPTP est plus un protocole de
tunnel pour transporter PPP qu'un VPN. La confidentialité doit être
assurée au niveau des options de la session PPP.

> Quelle solution me proposez vous?
> Le client se connectera à la demande via son Windows.

OpenVPN. Disponible sur les deux OS parmi d'autres, transport UDP ou TCP
facile à NATer, chiffrement SSL, fonctionnement en émulation ethernet
(TAP) ou en liaison routée point à point (TUN) supportant IPv4 et IPv6,
exécution de scripts, possibilité pour le serveur de "pousser" des
routes sur le client...

Il y a bien le VPN L2TP/IPSec intégré à Windows, mais j'ai cru
comprendre que c'était un peu l'usine à gaz à faire marcher sous Linux.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Tekpi
In reply to this post by Pascal Hambourg
Bonjour à tous,

je viens de terminer la configuration de mon openvpn en mode bridge (le but étant d'attaquer un server se trouvant derrière le linux).
Il tourne sous Ubuntu dernière version serveur.

Lorsque je lance ma connexion via mon windows XP en ligne de commande, tout s'effectue correctement, il me dit, après plusieurs lignes : Initialization Sequence completed.
En effet, lorsque je fais un ipconfig sous Dos, j'ai bien l'ip qui m'est retourné, je peux la pinger. Cependant impossible de pinger mon linux via la connexion openvpn.

Voici mon fichier de conf linux :

local 192.168.5.33
port 500
proto tcp
dev tap
mode server
tls-server
tun-mtu 1500
mssfix
persist-key
persist-tun
ca /keys/ca.crt
cert /keys/openvpn.crt
key /keys/openvpn.key
dh /keys/dh1024.pem
tls-auth /keys/ta.key 0
server-bridge 192.168.5.33 255.255.255.0 192.168.5.50 192.168.5.55
#ifconfig-pool-persist /etc/openvpn/log/ipp.txt
client-to-client
keepalive 10 120
comp-lzo
max-clients 15
user nobody
group nobody
chroot /etc/openvpn
status /var/log/status.log
log-append /var/log/openvpn.log
verb 4
mute 10
push "route 192.168.5.0 255.255.255.0"

et mon openvpn.conf côté windows :

client
dev tap
proto tcp
remote [ip remoteserver] 500 #bien entendu j'ai remplacé ip remote server par la bonne ip
resolv-retry infinite
nobind
tls-client
persist-key
persist-tun
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\client1.crt"
key "C:\\Program Files\\OpenVPN\\config\\client1.key"
ns-cert-type server
tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 1
comp-lzo
verb 2
mute 5

Une idée ou une piste?



Pascal Hambourg wrote
Salut,

Tekpi a écrit :
>
> je dois mettre en place un vpn sur un serveur debian pour une connexion à
> distance sur des postes Windows XP Pro.
>
> J'ai testé toute la journée des configs de PPTP (poptop), sans succès,
> apparemment le protocole GRE est mal géré par le nat de mon routeur.

Il arrive effectivement que certains routeurs/firewalls/NAT aient du mal
avec les protocoles IP autres que TCP, UDP et ICMP tels que GRE. Pas
d'option "PPTP pass-through" ou "VPN pass-through" ? Si ça concerne le
routeur côté serveur, redirection du port TCP 1723 et du protocole GRE
vers le serveur, ou bien mise en "DMZ" du serveur ?

Accessoirement, garder à l'esprit que PPTP est plus un protocole de
tunnel pour transporter PPP qu'un VPN. La confidentialité doit être
assurée au niveau des options de la session PPP.

> Quelle solution me proposez vous?
> Le client se connectera à la demande via son Windows.

OpenVPN. Disponible sur les deux OS parmi d'autres, transport UDP ou TCP
facile à NATer, chiffrement SSL, fonctionnement en émulation ethernet
(TAP) ou en liaison routée point à point (TUN) supportant IPv4 et IPv6,
exécution de scripts, possibilité pour le serveur de "pousser" des
routes sur le client...

Il y a bien le VPN L2TP/IPSec intégré à Windows, mais j'ai cru
comprendre que c'était un peu l'usine à gaz à faire marcher sous Linux.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Jean-Yves F. Barbier
Voila les miens; pour différentes raisons, je n'utilise pas le dhcp
intégré, et les stations ont donc leurs propres adresses IP.

###   Mode: BRIDGED   ###
mode server
tls-server
tls-exit
local 192.168.1.103
port 443
proto udp
dev tap0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key   /etc/openvpn/keys/server.key  # This file should be kept secret
tls-auth /etc/openvpn/keys/ta.key 0
dh   /etc/openvpn/keys/dh2048.pem
status /etc/openvpn/logs/status-TAP.log
log   /etc/openvpn/logs/openvpn-TAP.log
verb 4
;ifconfig-pool-persist /etc/openvpn/logs/ipp.txt
;server-bridge 192.168.1.103 255.255.255.0 192.168.1.221 192.168.1.224
;push "redirect-gateway def1"
;client-config-dir /etc/openvpn/ccd_BRIDGE
;push "dhcp-option DNS 192.168.1.103"
;push "dhcp-option WINS 192.168.1.103"
client-to-client
keepalive 10 120
cipher BF-CBC        # Blowfish (default)
comp-lzo
max-clients 4
user nobody
group nogroup
persist-key
persist-tun

#############################################################################

# Station Linux

###   Mode: BRIDGED   ###
client
tls-exit
# 222 = IP fixe de cette station
ifconfig 192.168.1.222 255.255.255.0
ifconfig-nowarn
dev tap0
proto udp
remote 111.222.333.444 443
keepalive 10 120
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca   /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/JYVES.crt
key   /etc/openvpn/keys/JYVES.key
tls-auth /etc/openvpn/keys/ta.key 1
status /etc/openvpn/logs/status.log
log /etc/openvpn/logs/openvpn.log
ns-cert-type server
cipher BF-CBC
comp-lzo
verb 3

#############################################################################

je n'ai pas les fichiers pour stations m$ sous la main, mais c'est pareil.

par ailleurs, j'ai eu des PBs de netbios browsing avec "cipher AES-192-CBC"
(mais peut-être était-ce dû à un PB de conf à ce moment là),
d'ailleurs, je ne vois pas de ligne "cipher" dans tes confs??!

* tu indiques "tap" dans la conf Linux; je crois plutôt que c'est "tap0"

* "tun-mtu" & "mssfix" n'ont de sens que si tu as *vraiment* des PBs de MTU

* les paths sont incomplets (/etc/openvpn/keys) il vaut mieux les indiquer à
    partir de la racine

* il n'y a aucun intérêt à utiliser le protocole TCP au lieu de UDP (packets
    plus petits)

* il-y-a une incohérence entre le nombre de clients que tu déclares (15) et
   la plage dhcp (50~55 => 6 clients max)

* pas besoin de path dans la conf m$: il sait où aller chercher ses fichiers

JY

Tekpi a écrit :

> Bonjour à tous,
>
> je viens de terminer la configuration de mon openvpn en mode bridge (le but
> étant d'attaquer un server se trouvant derrière le linux).
> Il tourne sous Ubuntu dernière version serveur.
>
> Lorsque je lance ma connexion via mon windows XP en ligne de commande, tout
> s'effectue correctement, il me dit, après plusieurs lignes : Initialization
> Sequence completed.
> En effet, lorsque je fais un ipconfig sous Dos, j'ai bien l'ip qui m'est
> retourné, je peux la pinger. Cependant impossible de pinger mon linux via la
> connexion openvpn.
>
> Voici mon fichier de conf linux :
>
> local 192.168.5.33
> port 500
> proto tcp
> dev tap
> mode server
> tls-server
> tun-mtu 1500
> mssfix
> persist-key
> persist-tun
> ca /keys/ca.crt
> cert /keys/openvpn.crt
> key /keys/openvpn.key
> dh /keys/dh1024.pem
> tls-auth /keys/ta.key 0
> server-bridge 192.168.5.33 255.255.255.0 192.168.5.50 192.168.5.55
> #ifconfig-pool-persist /etc/openvpn/log/ipp.txt
> client-to-client
> keepalive 10 120
> comp-lzo
> max-clients 15
> user nobody
> group nobody
> chroot /etc/openvpn
> status /var/log/status.log
> log-append /var/log/openvpn.log
> verb 4
> mute 10
> push "route 192.168.5.0 255.255.255.0"
>
> et mon openvpn.conf côté windows :
>
> client
> dev tap
> proto tcp
> remote [ip remoteserver] 500 #bien entendu j'ai remplacé ip remote server
> par la bonne ip
> resolv-retry infinite
> nobind
> tls-client
> persist-key
> persist-tun
> ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
> cert "C:\\Program Files\\OpenVPN\\config\\client1.crt"
> key "C:\\Program Files\\OpenVPN\\config\\client1.key"
> ns-cert-type server
> tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 1
> comp-lzo
> verb 2
> mute 5
>
> Une idée ou une piste?

--
Illiterate?  Write today, for free help!

Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Tekpi
Bonjour et merci pour ta réponse. J'ai corrigé effectivement qq incohérence, j'ai suivi aussi tes conseils.

Cependant ça ne fonctionne toujours pas. La connexion s'initialise bien sur mon WinXp, j'ai même l'interface réseau qui me dit connecté au réseau. Par contre impossible de pinger, ni même de faire de connexion sur le linux.

Il se trouve derrière un routeur, je l'ai mis en DMZ et ai activé le vpn pass-through.

Par contre, je viens de remarquer qu'en faisant un ifconfig, je n'ai pas d'interface tun0 ou tap0 sur mon linux, ni même d'interface bridge, mon pb se site peut être là, non?

Merci en tout cas si tu as une réponse


Jean-Yves F. Barbier wrote
Voila les miens; pour différentes raisons, je n'utilise pas le dhcp
intégré, et les stations ont donc leurs propres adresses IP.

###   Mode: BRIDGED   ###
mode server
tls-server
tls-exit
local 192.168.1.103
port 443
proto udp
dev tap0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key   /etc/openvpn/keys/server.key  # This file should be kept secret
tls-auth /etc/openvpn/keys/ta.key 0
dh   /etc/openvpn/keys/dh2048.pem
status /etc/openvpn/logs/status-TAP.log
log   /etc/openvpn/logs/openvpn-TAP.log
verb 4
;ifconfig-pool-persist /etc/openvpn/logs/ipp.txt
;server-bridge 192.168.1.103 255.255.255.0 192.168.1.221 192.168.1.224
;push "redirect-gateway def1"
;client-config-dir /etc/openvpn/ccd_BRIDGE
;push "dhcp-option DNS 192.168.1.103"
;push "dhcp-option WINS 192.168.1.103"
client-to-client
keepalive 10 120
cipher BF-CBC        # Blowfish (default)
comp-lzo
max-clients 4
user nobody
group nogroup
persist-key
persist-tun

#############################################################################

# Station Linux

###   Mode: BRIDGED   ###
client
tls-exit
# 222 = IP fixe de cette station
ifconfig 192.168.1.222 255.255.255.0
ifconfig-nowarn
dev tap0
proto udp
remote 111.222.333.444 443
keepalive 10 120
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca   /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/JYVES.crt
key   /etc/openvpn/keys/JYVES.key
tls-auth /etc/openvpn/keys/ta.key 1
status /etc/openvpn/logs/status.log
log /etc/openvpn/logs/openvpn.log
ns-cert-type server
cipher BF-CBC
comp-lzo
verb 3

#############################################################################

je n'ai pas les fichiers pour stations m$ sous la main, mais c'est pareil.

par ailleurs, j'ai eu des PBs de netbios browsing avec "cipher AES-192-CBC"
(mais peut-être était-ce dû à un PB de conf à ce moment là),
d'ailleurs, je ne vois pas de ligne "cipher" dans tes confs??!

* tu indiques "tap" dans la conf Linux; je crois plutôt que c'est "tap0"

* "tun-mtu" & "mssfix" n'ont de sens que si tu as *vraiment* des PBs de MTU

* les paths sont incomplets (/etc/openvpn/keys) il vaut mieux les indiquer à
    partir de la racine

* il n'y a aucun intérêt à utiliser le protocole TCP au lieu de UDP (packets
    plus petits)

* il-y-a une incohérence entre le nombre de clients que tu déclares (15) et
   la plage dhcp (50~55 => 6 clients max)

* pas besoin de path dans la conf m$: il sait où aller chercher ses fichiers

JY

Tekpi a écrit :
> Bonjour à tous,
>
> je viens de terminer la configuration de mon openvpn en mode bridge (le but
> étant d'attaquer un server se trouvant derrière le linux).
> Il tourne sous Ubuntu dernière version serveur.
>
> Lorsque je lance ma connexion via mon windows XP en ligne de commande, tout
> s'effectue correctement, il me dit, après plusieurs lignes : Initialization
> Sequence completed.
> En effet, lorsque je fais un ipconfig sous Dos, j'ai bien l'ip qui m'est
> retourné, je peux la pinger. Cependant impossible de pinger mon linux via la
> connexion openvpn.
>
> Voici mon fichier de conf linux :
>
> local 192.168.5.33
> port 500
> proto tcp
> dev tap
> mode server
> tls-server
> tun-mtu 1500
> mssfix
> persist-key
> persist-tun
> ca /keys/ca.crt
> cert /keys/openvpn.crt
> key /keys/openvpn.key
> dh /keys/dh1024.pem
> tls-auth /keys/ta.key 0
> server-bridge 192.168.5.33 255.255.255.0 192.168.5.50 192.168.5.55
> #ifconfig-pool-persist /etc/openvpn/log/ipp.txt
> client-to-client
> keepalive 10 120
> comp-lzo
> max-clients 15
> user nobody
> group nobody
> chroot /etc/openvpn
> status /var/log/status.log
> log-append /var/log/openvpn.log
> verb 4
> mute 10
> push "route 192.168.5.0 255.255.255.0"
>
> et mon openvpn.conf côté windows :
>
> client
> dev tap
> proto tcp
> remote [ip remoteserver] 500 #bien entendu j'ai remplacé ip remote server
> par la bonne ip
> resolv-retry infinite
> nobind
> tls-client
> persist-key
> persist-tun
> ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
> cert "C:\\Program Files\\OpenVPN\\config\\client1.crt"
> key "C:\\Program Files\\OpenVPN\\config\\client1.key"
> ns-cert-type server
> tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 1
> comp-lzo
> verb 2
> mute 5
>
> Une idée ou une piste?

--
Illiterate?  Write today, for free help!
Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Pascal Hambourg
Tekpi a écrit :
> Cependant ça ne fonctionne toujours pas. La connexion s'initialise bien sur
> mon WinXp, j'ai même l'interface réseau qui me dit connecté au réseau. Par
> contre impossible de pinger, ni même de faire de connexion sur le linux.
>
> Il se trouve derrière un routeur, je l'ai mis en DMZ et ai activé le vpn
> pass-through.

Je doute que la fonction VPN pass-through soit prévue pour OpenVPN. De
toute façon il n'en a pas besoin pour traverser le routeur, c'est juste
du TCP ou de l'UDP sur un unique port fixe. A ce propos, comme Jean-Yves
je recommande plutôt l'encapsulation UDP que TCP, pas tellement à cause
de la taille des paquets mais parce que l'interaction de deux connexions
TCP imbriquées (celle encapsulant le VPN et celles transportées dans le
VPN) l'une dans l'autre a des effets indésirables connus, notamment en
cas de perte de paquets (time-out, retransmission...). Cependant je ne
dirais pas que l'encapsulation TCP est sans intérêt : TCP est un
protocole de transport connecté, et les notions de début et fin de
connexion sont bien définies et standardisées en TCP (SYN, FIN)
contrairement à UDP, ce qui rend les connexions TCP "durables" plus
facile à gérer par les routeurs NAT et les pare-feu, notamment avec des
délais d'expiration en cas d'inactivité beaucoup plus longs qu'en UDP.

> Par contre, je viens de remarquer qu'en faisant un ifconfig, je n'ai pas
> d'interface tun0 ou tap0 sur mon linux, ni même d'interface bridge, mon pb
> se site peut être là, non?

C'est gênant, effectivement. Que dit ifconfig avec l'option -a pour
afficher même les interfaces inactives ? Avec l'option "dev tap", le nom
de l'interface est dynamique et ne sera pas forcément tap0. Pas de
messages d'erreur dans les logs système ?

PS: Pouvez-vous Jean-Yves et toi élaguer un peu les citations des
messages précédents dans vos réponses SVP, et ne conserver que ce qui
est nécessaire ?


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Tekpi
Bonjour et merci pour ta réponse.

un ifconfig -a me retourne bien l'interface tap0 (sans ip, mais ça je pense que c'est normal)

Lorsque ma connexion s'établit sur mon winxp, si je fais un ifconfig, rien de plus que mon eth0 et mon lo.

aucun retour d'erreur, ni dans les logs server, ni dans les logs clients, la connexion s'établit bien, mais rien ne semble transité dans le tunnel vpn.

J'ai modifié le protocole en udp port 500.

en faisant un openvpn --mktun --dev tap0 me retourne ceci :

#TUN/TAP device /dev/tap0 opened
#Cannot ioctl TUNSETPERSIST tap0 : Inappropriate ioctl for device

lorsque je veux monter mon interface bridge

#brctl addbr br0

il me retourne rien, mais en faisant un ifconfig -a, j'ai bien mon interface (comme le tap0 ci-dessus)

Une idée?

Je continue parallèlement à chercher, heureusement que c'est juste galère à mettre en place et qu'ensuite ça roule lol

Merci



<quote author="Pascal Hambourg">

Je doute que la fonction VPN pass-through soit prévue pour OpenVPN. De
toute façon il n'en a pas besoin pour traverser le routeur, c'est juste
du TCP ou de l'UDP sur un unique port fixe. A ce propos, comme Jean-Yves
je recommande plutôt l'encapsulation UDP que TCP, pas tellement à cause
de la taille des paquets mais parce que l'interaction de deux connexions
TCP imbriquées (celle encapsulant le VPN et celles transportées dans le
VPN) l'une dans l'autre a des effets indésirables connus, notamment en
cas de perte de paquets (time-out, retransmission...). Cependant je ne
dirais pas que l'encapsulation TCP est sans intérêt : TCP est un
protocole de transport connecté, et les notions de début et fin de
connexion sont bien définies et standardisées en TCP (SYN, FIN)
contrairement à UDP, ce qui rend les connexions TCP "durables" plus
facile à gérer par les routeurs NAT et les pare-feu, notamment avec des
délais d'expiration en cas d'inactivité beaucoup plus longs qu'en UDP.

> Par contre, je viens de remarquer qu'en faisant un ifconfig, je n'ai pas
> d'interface tun0 ou tap0 sur mon linux, ni même d'interface bridge, mon pb
> se site peut être là, non?

C'est gênant, effectivement. Que dit ifconfig avec l'option -a pour
afficher même les interfaces inactives ? Avec l'option "dev tap", le nom
de l'interface est dynamique et ne sera pas forcément tap0. Pas de
messages d'erreur dans les logs système ?
Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Pascal Hambourg
Tekpi a écrit :
>
> un ifconfig -a me retourne bien l'interface tap0

Donc elle est bien créée mais pas activée. On peut se demander pourquoi.

> (sans ip, mais ça je pense que c'est normal)

Si cette interface est prévue pour être pontée, c'est bien possible.

[...]
> lorsque je veux monter mon interface bridge
>
> #brctl addbr br0
>
> il me retourne rien, mais en faisant un ifconfig -a, j'ai bien mon interface
> (comme le tap0 ci-dessus)

Il faut ajouter les interfaces à ponter avec 'brctl addif', activer tout
ce bazar (à la fois le pont br0 que ses interfaces), et configurer le
pont br0 avec une adresse IP+masque si celui-ci doit faire office
d'interface locale et non juste de pont. Voir les divers howto sur
l'utilisation du pontage. Note que si tu veux ponter l'interface tap
avec l'interface ethernet de la machine, il ne faut pas lui donner
d'adresse IP, seul le pont doit en avoir une.

Bref, tout ça pour dire qu'avant de faire du pontage, dans un premier
temps il serait peut-être plus simple de vérifier que le VPN fonctionne
juste en configurant les interfaces tap directement, dans un sous-réseau
distinct du LAN (sinon conflit de routage). Ensuite tu pourras le cas
échéant créer et configurer un pont. Je ne sais si OpenVPN a des options
pour automatiser tout ça.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Tekpi
Bon, j'ai avancé sur le sujet.
J'ai finalement créé l'interface tap0 (mknod /dev/tap0 c 36 16) + mon interface bridgée.

Ma question maintenant est la suivante.

En modge bridge, cela me permet de prendre la main sur le réseau derrière le linux.

Donc ma question est :

l'interface eth0 et eth1 de mon serveur linux doivent-elles impérativement être sur le même réseau?

Car actuellement, j'ai configuré mon eth0 en 192.168.5.0/24 et eth1 192.168.1.0/24.

En gros, le schéma :

Client winxp <------> VPN <-----------> eth0 linux eth1 <------------> Lan

mon but étant que mon client winxp se connecte sur un serveur du lan.

merci pour ces informations.
Reply | Threaded
Open this post in threaded view
|

Re: VPN client Windows -> Serveur Debian

Pascal Hambourg
Tekpi a écrit :
> J'ai finalement créé l'interface tap0 (mknod /dev/tap0 c 36 16) + mon
> interface bridgée.

Euh, je ne vois pas trop l'intérêt de créer /dev/tap0. Si je ne m'abuse,
ça servait avec l'ancien module ethertap qui est obsolète depuis que le
module tun, qu'utilise OpenVPN, permet de créer aussi des interface TAP.

> En modge bridge, cela me permet de prendre la main sur le réseau derrière le
> linux.

Qu'entends-tu par "prendre la main" ? Tu n'as probablement pas besoin de
pontage pour communiquer avec les autres machines du LAN, du routage IP
doit suffire (sauf protocole non IP, ou pas très routable, ou à base de
broadcast comme Netbios/SMB).

> l'interface eth0 et eth1 de mon serveur linux doivent-elles impérativement
> être sur le même réseau?
>
> Car actuellement, j'ai configuré mon eth0 en 192.168.5.0/24 et eth1
> 192.168.1.0/24.
>
> En gros, le schéma :
>
> Client winxp <------> VPN <-----------> eth0 linux eth1 <------------> Lan

eth0, c'est quoi ? L'interface WAN vers internet ?

Si pontage : l'interface LAN, eth1, doit être pontée avec l'interface
VPN, tapX. Elles sont de fait sur le même réseau, comme les ports d'un
switch. Elles deviennent les ports d'un switch virtuel constitué par le
pont. D'autre part dans la configuration de la machine l'interface pont
(br0) doit remplacer eth1. Ce n'est plus eth1 mais br0 qui a la
configuration IP, les routes associées, qui est utilisée par le serveur
DHCP le cas échéant, etc. Au niveau réseau, eth1 et tapX seront aussi
invisibles que les ports d'un switch.

Si routage : chaque réseau (VPN, LAN, WAN) doit avoir un sous-réseau
différent. Le serveur OpenVPN doit "pousser" (option push) sur le client
une route vers le sous-réseau du LAN afin que ce dernier sache comment
l'atteindre. Il faut aussi que les machines du LAN sachent comment
atteindre le sous-réseau du VPN pour pouvoir répondre. Pas de problème
si le serveur VPN est aussi la passerelle par défaut pour le LAN.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]