Re: VPN client Windows -> Serveur Debian

2007-11-06 Par sujet 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: VPN client Windows -> Serveur Debian

2007-11-06 Par sujet 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.

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



Re: VPN client Windows -> Serveur Debian

2007-11-06 Par sujet 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: VPN client Windows -> Serveur Debian

2007-11-06 Par sujet 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





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 ?

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



Re: VPN client Windows -> Serveur Debian

2007-11-06 Par sujet 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: VPN client Windows -> Serveur Debian

2007-11-06 Par sujet 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
>> persis

Re: VPN client Windows -> Serveur Debian

2007-11-05 Par sujet 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!



Re: VPN client Windows -> Serveur Debian

2007-11-05 Par sujet Tekpi

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 [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
> 
> 
> 

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



Re: VPN client Windows -> Serveur Debian

2007-11-04 Par sujet Tekpi

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 [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
> 
> 
> 

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



Re: VPN client Windows -> Serveur Debian

2007-11-04 Par sujet 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
> 
> 
> 

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



Re: VPN client Windows -> Serveur Debian

2007-11-02 Par sujet Jean-Yves F. Barbier

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



Re: VPN client Windows -> Serveur Debian

2007-11-02 Par sujet Vincent Bernat
OoO  Lors de  la soirée  naissante du  vendredi 02  novembre  2007, vers
17:22, Pascal Hambourg <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: VPN client Windows -> Serveur Debian

2007-11-02 Par sujet 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]