OpenVPN connexion impossible sur le même réseau local
Résolu/Fermé
brupala Messages postés 111455 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 9 mai 2025 - 29 sept. 2022 à 13:32
- OpenVPN connexion impossible sur le même réseau local
- Gmail connexion - Guide
- Appdata local - Guide
- Partager un dossier en reseau local - Guide
- Voe.sx n'autorise pas la connexion. ✓ - Forum Réseaux sociaux
- Ip local - Guide
4 réponses
26 sept. 2022 à 11:37
Salut,
je n'ai pas lu tes liens,
tu te connectes au serveur, mais pas au réseau local à travers le vpn ?
il suffit de se connecter à l'adresse lan du serveur, pourtant.
et une fois le vpn établi, il faut le routage activé sur le PC windows.
Tu n'as pas une connexion mobile pour tester à distance ?
26 sept. 2022 à 12:08
Merci pour ta réponse !
Pas de soucis pour les liens, ce n'est que pour de la doc :)
Avec OpenVPN, j'aimerai cibler sur le client l'adresse ip publique du serveur, ce qui marche bien quand le client est sur un réseau différent du serveur. Mais l'appareil que je veux connecter ne possède pas d'antenne wifi, et la connexion n'est pas partageable par USB (c'est un automate), l'astuce du mobile ne fonctionne donc pas. C'est pourquoi je veux faire fonctionner la connexion aussi sur le même réseau local.
L'idée étant de n'autoriser sur l'automate que l'accès via son interface vpn, en désactivant tout autre accès via les autres interfaces.
J'ai trouvé une option "--redirect-gateway local" qui est sensé faire le travail, (autoriser la connexion si les deux appareils sont sur le même sous-réseau) mais ça ne fonctionne apparemment pas, la connexion a fonctionné une fois sur mon pc test Windows, mais n'a plus fonctionné après sur les autres appareils ni sur le pc test.
Le routage est bien activé sur le serveur, et la table de routage me semble cohérente.
Merci pour ton aide en tout cas ! Si tu as d'autres idées, je suis tout ouï ;)
26 sept. 2022 à 13:17
houla,
je pense que tu ne pourras jamais désactiver le réseau local, car le tunnel est encapsulé dedans, il y a des limites à la virtualisation :-)
ou alors passer le réseau local en /30 alors tu n'aurais que 2 adresses, le serveur et le client utilisables, presque du point.
Mais pour ça il faut déconnecter le lan de la box et coller un câble direct, mais bon juste pour un test hein, car avec un câble direct, plus besoin de vpn, on est d'accord, c'est un pn sans le V.
Cet automate est destiné à être connecté à distance ensuite ?
26 sept. 2022 à 13:51
Effectivement, l'idée du VPN sur un réseau local est plutôt pas bien pertinente, mais j'ai vu que ça fonctionnait sur une autre installation !
Je pense que je vais simplement essayer de changer de configuration, et passer mon serveur en câble, j'ai vu autre part que si les deux appareils sont connectés en wifi sur le même réseau ça pouvait poser des problèmes parfois.
A terme, oui, l'automate doit être connecté à distance, d'où l'idée du VPN, mais pour le moment pas moyen de faire ça...
Je te tiens au courant !
Modifié le 26 sept. 2022 à 15:31
Dans un réseau local, on peut faire de l'ipsec direct, sans tunnel VPN.
Par contre, je ne t'expliquerai pas comment, ça remonte trop loin quand j'ai vu ça :-)
Mais bon, ipsec était fait pour ça à la base.
26 sept. 2022 à 15:39
J'ai effectivement vu ça aussi en école. C'est plutôt pas mal comme outil ! ;)
Mais ce n'est pas approprié ici, l'automate n'étant pas compatible (oui je sais, ça fait beaucoup de contraintes cet automate...)
Merci quand même pour l'idée !!
26 sept. 2022 à 13:17
Bonjour,
Que racontent les logs, côté visiteur et serveur ?
26 sept. 2022 à 14:09
Merci pour ta réponse !
Les logs sont au niveau 6 (verb 6) et ils donnent ça :
du côté client
Mon Sep 26 13:59:24 2022 MANAGEMENT: >STATE:1664193564,AUTH,,,,,,
Mon Sep 26 13:59:24 2022 TLS: Initial packet from [AF_INET]ip.publique.serveur:1194, sid=88d792dd 3961a2dc
Mon Sep 26 13:59:24 2022 UDPv4 WRITE [62] to [AF_INET]ip.publique.serveur:1194: P_ACK_V1 kid=0 [ ]
Mon Sep 26 13:59:24 2022 UDPv4 WRITE [331] to [AF_INET]ip.publique.serveur:1194: P_CONTROL_V1 kid=0 [ ] pid=867 DATA len=317
2022-09-26 13:59:26 us=734000 UDPv4 WRITE [331] to [AF_INET]ip.publique.serveur:1194: P_CONTROL_V1 kid=0 [ ] pid=1123 DATA len=317
2022-09-26 13:59:30 us=500000 UDPv4 WRITE [331] to [AF_INET]ip.publique.serveur:1194: P_CONTROL_V1 kid=0 [ ] pid=1379 DATA len=317
2022-09-26 13:59:38 us=718000 UDPv4 WRITE [331] to [AF_INET]ip.publique.serveur:1194: P_CONTROL_V1 kid=0 [ ] pid=1635 DATA len=317
2022-09-26 13:59:54 us=312000 UDPv4 WRITE [331] to [AF_INET]ip.publique.serveur:1194: P_CONTROL_V1 kid=0 [ ] pid=1891 DATA len=317
2022-09-26 14:00:24 us=312000 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2022-09-26 14:00:24 us=312000 TLS Error: TLS handshake failed
2022-09-26 14:00:24 us=312000 TCP/UDP: Closing socket
2022-09-26 14:00:24 us=312000 SIGUSR1[soft,tls-error] received, process restarting
2022-09-26 14:00:24 us=312000 MANAGEMENT: >STATE:1664193624,RECONNECTING,tls-error,,,,,
2022-09-26 14:00:24 us=312000 Restart pause, 5 second(s)
du côté serveur
2022-09-26 13:59:26 us=640000 MULTI: multi_create_instance called
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 Re-using SSL/TLS context
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 Control Channel MTU parms [ L:1621 D:1156 EF:94 EB:0 ET:0 EL:3 ]
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1549,tun-mtu 1500,proto UDPv4,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-server'
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1549,tun-mtu 1500,proto UDPv4,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client'
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 UDPv4 READ [54] from [AF_INET]192.168.1.35:65153: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=355 DATA len=40
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 TLS: Initial packet from [AF_INET]192.168.1.35:65153, sid=ddabca65 35a39a04
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 UDPv4 WRITE [66] to [AF_INET]192.168.1.35:65153: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=355 DATA len=52
2022-09-26 13:59:26 us=640000 192.168.1.35:65153 UDPv4 READ [54] from [AF_INET]192.168.1.35:65153: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=355 DATA len=40
2022-09-26 13:59:29 us=15000 192.168.1.35:65153 UDPv4 WRITE [54] to [AF_INET]192.168.1.35:65153: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=611 DATA len=40
2022-09-26 13:59:33 us=843000 192.168.1.35:65153 UDPv4 WRITE [54] to [AF_INET]192.168.1.35:65153: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=867 DATA len=40
2022-09-26 13:59:41 us=765000 192.168.1.35:65153 UDPv4 WRITE [54] to [AF_INET]192.168.1.35:65153: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=1123 DATA len=40
2022-09-26 13:59:57 us=218000 192.168.1.35:65153 UDPv4 WRITE [54] to [AF_INET]192.168.1.35:65153: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=1379 DATA len=40
2022-09-26 14:00:26 us=640000 192.168.1.35:65153 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2022-09-26 14:00:26 us=640000 192.168.1.35:65153 TLS Error: TLS handshake failed
2022-09-26 14:00:26 us=640000 192.168.1.35:65153 SIGUSR1[soft,tls-error] received, client-instance restarting
Voilà, on voit bien que les deux machines communiquent, mais "TLS key negotiation failed"...
Est-ce que tu vois un détail qui m'aurait échappé ?
Merci !!
Modifié le 26 sept. 2022 à 14:53
Tu n'as pas oublié d'exporter la clé pour le TLS (ta.key) au client ?
26 sept. 2022 à 14:56
Il ne me semble pas, j'utilise tls-crypt avec la clé dans le fichier ovpn pour le client, et clé séparée pour le côté serveur.
D'autant plus que la connexion se fait bien lorsque les deux appareils de test sont sur un réseau différent, donc la négociation TLS aussi ?
26 sept. 2022 à 15:23
tu as testé dans des réseaux différents ?
je croyais que tu ne pouvais pas ...
26 sept. 2022 à 15:31
Je ne suis pas très clair dans ce que j'ai dit effectivement.
Je possède 2 ordis, un automate.
Sur le premier ordi, j'ai configuré un serveur VPN. Celui-ci est connecté en wifi à ma box.
Sur le deuxième ordi (utilisé uniquement pour les tests), j'ai configuré un client VPN. Ce client parvient à se connecter au VPN lorsque je place l'ordi sur un réseau différent du serveur, par exemple ma 4G. Cependant, ce n'est pas l'objectif, je désire le que le VPN fonctionne quand on est sur le même réseau local, or là, la connexion n'aboutit pas, cf. logs dans le message plus haut.
Sur l'automate, j'ai configuré un client VPN. Cet automate ne peut pas se connecter à un wifi ou autre, uniquement en Ethernet, et je n'ai pour le moment pas le moyen de le déplacer pour profiter d'une connexion filaire différente du serveur VPN.
Voilà, j'espère que c'est un peu plus clair et complet ?
29 sept. 2022 à 10:13
Bonne nouvelle aujourd'hui !!
Donc voilà, la connexion fonctionne, pour une raison inconnue.
Premier point important, j'ai modifié la configuration de mon réseau pour câbler le serveur OpenVPN avec Ethernet, plutôt que d'utiliser le wifi, ayant vu que ça pouvait poser des problèmes parfois. Ceci fait, j'ai pu désactiver l'option redirect-gateway qui posait problème aussi, vu que je n'ai pas besoin de rediriger le trafic internet par le VPN, seulement d'établir une connexion distante. Et enfin, j'ai pu faire fonctionner avec cette configuration le fait de se connecter à une adresse ip privée, comme suggéré par @avion-f16, solution qui ne marchait pas auparavant.
Avec tout ça, la connexion VPN s'établit correctement. Seul bémol, la connexion ne permet pas de contacter les machines les unes avec les autres, par ping par exemple.
Un dernier réglage pour corriger ça a été de changer dans le registre les propriétés de l'adaptateur réseau OpenVPN pour le passer d'un réseau public à un réseau privé. Je n'avais pas pensé à ça, mais le firewall de Windows bloque tout sur ces connexions publiques, la manipulation m'a permis d'autoriser le trafic finalement.
Voilà, c'est tout ce que je peux dire. Je reste encore surpris par le fait que la connexion directe en ciblant l'adresse publique sur internet ne fonctionne pas, et que seule l'adresse privée permet la connexion, sachant que depuis une autre installation que j'ai pu tester, cette connexion était possible. Il s'agit donc soit d'un problème de Hairpinning comme suggéré, la box utilisée n'étant pas compatible, soit simplement parce que sur l'autre installation, je cible un nom en ddns, pas une adresse brute... je fais des suppositions sans connaitre les réponses sur ce point.
En tout cas, merci beaucoup pour vos suggestions et votre aide !!
29 sept. 2022 à 10:29
Pour le trafic entre clients,
il ya une option dans le serveur pour ça, là de tête je ne m'en souviens plus, mais tu dois pouvoir trouver.
en fait vite retrouvé, c'est là:
# Uncomment this directive to allow different
# clients to be able to "see" each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server's TUN/TAP interface.
;client-to-client
29 sept. 2022 à 11:45
Merci pour l'idée !
Je me suis mal exprimé, en disant "la connexion ne permet pas de contacter les machines les unes avec les autres, par ping par exemple.", je parlais bien du serveur vers le client et inversement, pas des clients entre eux.
Pour des raisons de sécurité, je ne veux pas que cette option soit activée, mais merci pour l'idée quand même :)
29 sept. 2022 à 12:06
??
Le client est forcément connecté au serveur .
Tu parles du ping sur l'adresse dans le vpn ou de l'adresse sur le réseau local, parce que dans le second cas, il faut activer le routage, quoique sur le même lan, ça ne devrait même pas passer par le vpn :-)
29 sept. 2022 à 13:10
Je parlais du ping sur l'adressage vpn, en 10.8.x.x, mais le problème est corrigé avec la modification de réseau, (de public à privé) qui doit ouvrir le firewall j'imagine...
29 sept. 2022 à 13:32
Oui, bien sûr.