Re: VPN client Windows -> Serveur Debian
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
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
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
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
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
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
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
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
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
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
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
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
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]