VPN client Windows -> Serveur Debian

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

OoO Lors de la soirée naissante du vendredi 02 novembre 2007, vers
17:22, Pascal Hambourg <pascal.mail@plouf.fr.eu.org> 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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

je confirme ce que dit Pascal: OpenVPN

C'est vrai que c'est un peu chibavant à mettre au point (je peux te pas ser
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 rac courci
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 connexio n à
distance sur des postes Windows XP Pro.

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

Il arrive effectivement que certains routeurs/firewalls/NAT aient du ma l
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 l e
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 TC P
facile à NATer, chiffrement SSL, fonctionnement en émulation ethern et
(TAP) ou en liaison routée point à point (TUN) supportant IPv4 et I Pv6,
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

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't it
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 arriv e 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), san s succès,
apparemment le protocole GRE est mal géré par le nat de mon r outeur.

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 proto cole 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 e thernet
(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'a i cru
comprendre que c'était un peu l'usine à gaz à faire march er 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

--
View this message in context: http://www.nabble.com/VPN-client-Windows--%3E -Serveur-Debian-tf4738184.html#a13579531
Sent from the debian-user-french mailing list archive at Nabble.com.

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 p ost.

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 ro uteur.

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 protoc ole 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 et hernet
(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 marche r 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

--
View this message in context: http://www.nabble.com/VPN-client-Windows--%3E -Serveur-Debian-tf4738184.html#a13579612
Sent from the debian-user-french mailing list archive at Nabble.com.

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 : Initializ ation
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 ser ver
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 ro uteur.

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 protoc ole 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 et hernet
(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 marche r 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

--
View this message in context: http://www.nabble.com/VPN-client-Windows--%3E -Serveur-Debian-tf4738184.html#a13585159
Sent from the debian-user-french mailing list archive at Nabble.com.

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-CB C"
(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 M TU

* les paths sont incomplets (/etc/openvpn/keys) il vaut mieux les indique r à
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 fic hiers

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 : Initiali zation
Sequence completed.
En effet, lorsque je fais un ipconfig sous Dos, j'ai bien l'ip qui m'es t
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 se rver
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!

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

Cependant ça ne fonctionne toujours pas. La connexion s'initialise bie n 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 linu x.

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, mo n 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 secre t
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 "t ap0"

* "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 indique r
à
partir de la racine

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

* il-y-a une incohérence entre le nombre de clients que tu décl ares (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 lin ux 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!

--
View this message in context: http://www.nabble.com/VPN-client-Windows--%3E -Serveur-Debian-tf4738184.html#a13602606
Sent from the debian-user-french mailing list archive at Nabble.com.

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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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, l a
connexion s'établit bien, mais rien ne semble transité dans le tu nnel 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 interfac e
(comme le tap0 ci-dessus)

Une idée?

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

Merci





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 just e
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 d ans 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 d e
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 av ec 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 n om
de l'interface est dynamique et ne sera pas forcément tap0. Pas de
messages d'erreur dans les logs système ?

--
View this message in context: http://www.nabble.com/VPN-client-Windows--%3E -Serveur-Debian-tf4738184.html#a13604067
Sent from the debian-user-french mailing list archive at Nabble.com.