Aide configuration OpenVPN
Bonjour,
J'ai crée un vpn sous Windows (on me dira que je ne suis pas dans la bonne section mais le paquet fonctionne avec les mêmes commandes et je pense que l'aide apportée ici sera d'une plus grande utilité, merci les Nuxiens^^).
Le serveur se lance, le client arrive à se connecter au serveur mais après impossible de pinger l'un ou l'autre (je soupçonne un problème de routes) j'ai effectué toutes les redirections NAT et j'ai ajouté les exceptions au pare feu, je vous joins mon fichier config :
SERVEUR :
____________________________________________
CLIENT
Si un gourou du réseau pouvait m'apporter sa céleste lumière, je lui en serai éternellement reconnaissant.
J'ai crée un vpn sous Windows (on me dira que je ne suis pas dans la bonne section mais le paquet fonctionne avec les mêmes commandes et je pense que l'aide apportée ici sera d'une plus grande utilité, merci les Nuxiens^^).
Le serveur se lance, le client arrive à se connecter au serveur mais après impossible de pinger l'un ou l'autre (je soupçonne un problème de routes) j'ai effectué toutes les redirections NAT et j'ai ajouté les exceptions au pare feu, je vous joins mon fichier config :
SERVEUR :
# Port d'ecoute OpenVPN port 443 # Protocole utilise proto tcp-server # Type d'interface virtuelle dev tun # Authentification ca ca.crt cert server.crt key server.key dh dh1024.pem # Hashage auth MD5 # Adresse du serveur virtuel server 10.8.0.0 255.255.255.0 #Route client vers serveur push "route 192.168.1.0 255.255.255.0" # Indiquer adresse DNS au client push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" # Autoriser la vue sur les autres clients client-to-client # On garde la connexion keepalive 10 120 # Authentification tls-auth ta.key 0 # Methode de cryptage cipher AES-256-CBC # Compression comp-lzo # Nombre de clients max. max-clients 5 # On garde la cle et la connexion persist-key persist-tun # On ecrit dans le fichier log status openvpn-status.log verb 3 mute 20
____________________________________________
CLIENT
client dev tun proto tcp-client remote MON_NOM_DE_DOMAINE 443 resolv-retry infinite nobind persist-key persist-tun # LE CLIENT ACCEPTE LES OPTIONS # DU SERVEUR # Le client devrait accepter les options # poussées par le serveur pull # Wireless networks often produce a lot # of duplicate packets. Set this flag # to silence duplicate packet warnings. mute-replay-warnings # Hashage auth MD5 # Certificats ca ca.crt cert client1.crt key client1.key ns-cert-type server tls-auth ta.key 1 cipher AES-256-CBC # Logs comp-lzo verb 3 mute 20 # Hashage auth MD5 # Routes pour Windows route-method exe route-delay 2
Si un gourou du réseau pouvait m'apporter sa céleste lumière, je lui en serai éternellement reconnaissant.
A voir également:
- Aide configuration OpenVPN
- Ethernet n'a pas de configuration ip valide - Guide
- Panneau de configuration - Guide
- Retablir configuration usine chromecast - Guide
- Connaitre configuration pc - Guide
- Terminer la configuration du compte google play - Forum Gmail
7 réponses
Je ne sais pas si c'est pareil sous linux et sous windows, mais en tout cas sous linux, quand tu crées ta connexion VPN, tu es sensé voir apparaître une interface VPN qui s'appelle généralement soit tap0 soit tun0 selon la manière dont tu te connectes à la passerelle VPN.
Tu es également sensé créer une route VPN qui permet de router les IPs du VPN. Par exemple supposons que je tente de me connecter au réseau 10.1.2.* grâce à une connexion VPN, alors je suis sensé avoir une route qui utilises tun0 ou tap0 pour joindre ces destinations.
À ce stade, tu es sensé pouvoir pinger les IPs de ce réseaux VPN (en admettant quand les pings ne soient pas filtrés et que les machines ciblées répondent aux pings). Bref, sans voir les routes, difficile de répondre...
Bonne chance
/sbin/ifconfig -a
Tu es également sensé créer une route VPN qui permet de router les IPs du VPN. Par exemple supposons que je tente de me connecter au réseau 10.1.2.* grâce à une connexion VPN, alors je suis sensé avoir une route qui utilises tun0 ou tap0 pour joindre ces destinations.
/sbin/route -n
À ce stade, tu es sensé pouvoir pinger les IPs de ce réseaux VPN (en admettant quand les pings ne soient pas filtrés et que les machines ciblées répondent aux pings). Bref, sans voir les routes, difficile de répondre...
Bonne chance
Bonjour mamiemando,
Je te remercie pour ta réponse, mon adaptateur VPN est en mode TUN sur Windows ainsi que dans la configuration VPN client et serveur.
J'ai une Bbox de Bouygues adressée en 192.168.1.254
Mon PC sur lequel tourne OVPN : 192.168.1.3
Mon serveur VPN : 10.8.0.1
Mon IP client : 10.8.0.6
Voici les routes serveur :
Les routes clients :
Je te remercie pour ta réponse, mon adaptateur VPN est en mode TUN sur Windows ainsi que dans la configuration VPN client et serveur.
J'ai une Bbox de Bouygues adressée en 192.168.1.254
Mon PC sur lequel tourne OVPN : 192.168.1.3
Mon serveur VPN : 10.8.0.1
Mon IP client : 10.8.0.6
Voici les routes serveur :
C:\Users\Utilisateur>route print -4
===========================================================================
Liste d'Interfaces
19...00 ff 14 0a 94 5b ......TAP-Windows Adapter V9
13...0c 60 76 41 97 bc ......Carte réseau Broadcom 802.11g
11...d8 d3 85 14 64 66 ......Contrôleur Gigabit Ethernet Marvell Yukon 88E8
PCI-E
1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Carte Microsoft ISATAP
14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
16...00 00 00 00 00 00 00 e0 Carte Microsoft ISATAP #3
===========================================================================
IPv4 Table de routage
===========================================================================
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métriq
0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.3 10
10.8.0.0 255.255.255.0 10.8.0.2 10.8.0.1 30
10.8.0.0 255.255.255.252 On-link 10.8.0.1 286
10.8.0.1 255.255.255.255 On-link 10.8.0.1 286
10.8.0.3 255.255.255.255 On-link 10.8.0.1 286
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 On-link 192.168.1.3 266
192.168.1.3 255.255.255.255 On-link 192.168.1.3 266
192.168.1.255 255.255.255.255 On-link 192.168.1.3 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.1.3 266
224.0.0.0 240.0.0.0 On-link 10.8.0.1 286
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.1.3 266
255.255.255.255 255.255.255.255 On-link 10.8.0.1 286
===========================================================================
Itinéraires persistants :
Aucun
C:\Users\Utilisateur>
Les routes clients :
C:\Users\Benjamin>route print -4
===========================================================================
Liste d'Interfaces
27...00 ff db 0b 7e 1a ......TAP-Windows Adapter V9
18...c8 f7 33 17 5d e0 ......Intel(R) Centrino(R) Advanced-N 6235
12...6c 62 6d 34 46 4d ......Realtek PCIe GBE Family Controller
1...........................Software Loopback Interface 1
14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
15...00 00 00 00 00 00 00 e0 Carte Microsoft ISATAP #2
24...00 00 00 00 00 00 00 e0 Carte Microsoft ISATAP #3
===========================================================================
IPv4 Table de routage
===========================================================================
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 192.168.137.1 192.168.137.160 25
10.8.0.0 255.255.255.0 10.8.0.5 10.8.0.6 31
10.8.0.4 255.255.255.252 On-link 10.8.0.6 286
10.8.0.6 255.255.255.255 On-link 10.8.0.6 286
10.8.0.7 255.255.255.255 On-link 10.8.0.6 286
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 10.8.0.5 10.8.0.6 31
192.168.137.0 255.255.255.0 On-link 192.168.137.160 281
192.168.137.160 255.255.255.255 On-link 192.168.137.160 281
192.168.137.255 255.255.255.255 On-link 192.168.137.160 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 10.8.0.6 286
224.0.0.0 240.0.0.0 On-link 192.168.137.160 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 10.8.0.6 286
255.255.255.255 255.255.255.255 On-link 192.168.137.160 281
===========================================================================
Itinéraires persistants :
Aucun
C:\Users\Benjamin>
Les tables de routages windows... sont toujours aussi horrible :-)
Est-ce que tu arrives à pinguer le serveur depuis le client (avec l'IP au sens VPN 10.8.0.1) ?
Est-ce que tu arrives à pinguer le serveur depuis le client (avec l'IP au sens VPN 10.8.0.1) ?
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Aucune idée... À part te dire de suivre un tutoriel openvpn pour windows je ne sais pas quoi te dire.
https://vpnfacile.net/installer-openvpn-windows-7/
Si déjà tu arrives à faire marcher le client, on pourra ensuite voir si ça vient du serveur. Pour cela tu peux essayer de te connecter à un vpn "public" :
http://www.publicvpn.com/services.php
Bonne chance
https://vpnfacile.net/installer-openvpn-windows-7/
Si déjà tu arrives à faire marcher le client, on pourra ensuite voir si ça vient du serveur. Pour cela tu peux essayer de te connecter à un vpn "public" :
http://www.publicvpn.com/services.php
Bonne chance
J'ai suivi le tuto, tout fonctionne, le serveur tourne, le client se connecte mais le traffic n'est pas redirigé
Je comprends pas ce que tu appelles "redirigé". À ce stade tu dois pouvoir te connecter aux IPs du VPN, c'est indépendant d'une redirection puisque c'est dicté par une route VPN. Ensuite le fait que le serveur VPN agisse comme une passerelle par exemple pour ta route par défaut c'est une autre considération.
Je prends un exemple. Suppose que je sois chez moi. Je me connecte à un PC via une box dont l'IP est 192.168.1.10. Alors ma table de routage est (avec un vrai système d'exploitation) :
Supposons maintenant que j'établisse une connexion VPN vers le réseau 10.1.2.* via un serveur VPN dont l'IP publique est 1.2.3.4. Alors je vais avoir une route VPN en plus :
Ok donc là maintenant j'ai accès au VPN (10.1.2.*) via mon interface tap0 (mon interface VPN). Cela signifie que je peux désormais router du trafic vers ces IPs (qui sont les IPs d'un réseau local, cf cours sur IPv4), donc que je n'aurais pas pu router autrement. Ça signifie que par exemple si j'ai un serveur dans ce réseau local qui n'a pas d'IP publique, je peux désormais m'y connecter via la passerelle VPN 1.2.3.4.
Cependant, mon trafic a destination d'IP publiques (par exemple www.google.fr) continue d'être routé par cette route :
Donc comme je me connecte à www.google.fr via mon interface eth0, je continue d'apparaître avec l'IP publique de ma box.
Supposons maintenant que je corrige ma route par défaut et que je dise que désormais ma route par défaut passe par la passerelle 1.2.3.4 (je suppose que l'IP locale de cette machine dans le VPN est 10.1.2.1, note au passage que ça peut être une autre machine du réseau VPN que la passerelle VPN) :
- il faut que je continue à router 1.2.3.4 via eth0 sinon ma connexion VPN va tomber,
- il faut que je route par défaut le trafic via 10.1.2.1 qui sera désormais ma passerelle par défaut au lieu de 192.168.1.1
Je vais donc supprimer la route par défaut (via eth0) et en créer une nouvelle (via tap0) après avoir créer une route via eth0 qui me permet de continuer à atteindre ma passerelle VPN (1.2.3.4).
Du coup ma table de routage ressemblerait à ceci :
Amélioration : inspirée de https://bbs.archlinux.org/viewtopic.php?id=91071
Le problème de la table de routage ci-dessous, c'est que si 1.2.3.4 et/ou 10.1.2.0 tombe, alors ma route par défaut va tomber. Dans ce cas je me retrouve à ne plus pouvoir router que les machines de mon réseau local (192.168.1.*) alors qu'en réalité, je sais très bien que je pourrais router les IPs publiques via eth0. Je devrais alors rétablir à la main la route par défaut via eth0.
Bon c'est un peu dommage parce que dans ce cas on se retrouve à reconfigurer la route qu'on a dégagé juste avant...
Du coup, plutôt que de supprimer la route par défaut via eth0 pour la remplacer par une route par défaut via tap0, on peut garder la route via eth0, mais en la pénalisant par rapport à celle de tap0. Ainsi, tant que la route via tap0 est valide, mon trafic est routé par cette route ; si elle tombe, je routerai vers eth0. Et ça me donne du coup cette table de routage :
Bonne chance
Je prends un exemple. Suppose que je sois chez moi. Je me connecte à un PC via une box dont l'IP est 192.168.1.10. Alors ma table de routage est (avec un vrai système d'exploitation) :
(mando@silk) (~) $ /sbin/route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Supposons maintenant que j'établisse une connexion VPN vers le réseau 10.1.2.* via un serveur VPN dont l'IP publique est 1.2.3.4. Alors je vais avoir une route VPN en plus :
(mando@silk) (~) $ /sbin/route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 10.1.2.0 1.2.3.4 255.255.255.0 UG 0 0 0 tap0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Ok donc là maintenant j'ai accès au VPN (10.1.2.*) via mon interface tap0 (mon interface VPN). Cela signifie que je peux désormais router du trafic vers ces IPs (qui sont les IPs d'un réseau local, cf cours sur IPv4), donc que je n'aurais pas pu router autrement. Ça signifie que par exemple si j'ai un serveur dans ce réseau local qui n'a pas d'IP publique, je peux désormais m'y connecter via la passerelle VPN 1.2.3.4.
Cependant, mon trafic a destination d'IP publiques (par exemple www.google.fr) continue d'être routé par cette route :
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
Donc comme je me connecte à www.google.fr via mon interface eth0, je continue d'apparaître avec l'IP publique de ma box.
Supposons maintenant que je corrige ma route par défaut et que je dise que désormais ma route par défaut passe par la passerelle 1.2.3.4 (je suppose que l'IP locale de cette machine dans le VPN est 10.1.2.1, note au passage que ça peut être une autre machine du réseau VPN que la passerelle VPN) :
- il faut que je continue à router 1.2.3.4 via eth0 sinon ma connexion VPN va tomber,
- il faut que je route par défaut le trafic via 10.1.2.1 qui sera désormais ma passerelle par défaut au lieu de 192.168.1.1
Je vais donc supprimer la route par défaut (via eth0) et en créer une nouvelle (via tap0) après avoir créer une route via eth0 qui me permet de continuer à atteindre ma passerelle VPN (1.2.3.4).
Du coup ma table de routage ressemblerait à ceci :
(mando@silk) (~) $ /sbin/route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 10.1.2.1 0.0.0.0 UG 0 0 0 tap0 10.1.2.0 1.2.3.4 255.255.255.0 UG 0 0 0 tap0 1.2.3.4 192.168.1.1 255.255.255.255 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Amélioration : inspirée de https://bbs.archlinux.org/viewtopic.php?id=91071
Le problème de la table de routage ci-dessous, c'est que si 1.2.3.4 et/ou 10.1.2.0 tombe, alors ma route par défaut va tomber. Dans ce cas je me retrouve à ne plus pouvoir router que les machines de mon réseau local (192.168.1.*) alors qu'en réalité, je sais très bien que je pourrais router les IPs publiques via eth0. Je devrais alors rétablir à la main la route par défaut via eth0.
Bon c'est un peu dommage parce que dans ce cas on se retrouve à reconfigurer la route qu'on a dégagé juste avant...
Du coup, plutôt que de supprimer la route par défaut via eth0 pour la remplacer par une route par défaut via tap0, on peut garder la route via eth0, mais en la pénalisant par rapport à celle de tap0. Ainsi, tant que la route via tap0 est valide, mon trafic est routé par cette route ; si elle tombe, je routerai vers eth0. Et ça me donne du coup cette table de routage :
(mando@silk) (~) $ /sbin/route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth0 0.0.0.0 10.1.2.1 0.0.0.0 UG 0 0 0 tap0 10.1.2.0 1.2.3.4 255.255.255.0 UG 0 0 0 tap0 1.2.3.4 192.168.1.1 255.255.255.255 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Bonne chance