Réseau local VPN non pingable Mac

FruitSellers

Membre confirmé
27 Juillet 2015
16
0
33
Bonjour,

Je m'arrache les cheveux depuis plusieurs semaine sur la constitution de mon VPN.

Je m'explique, j'ai chez moi un serveur OpenVPN qui tourne sous Débian, j'ai aussi un serveur Windows Home Server dans ce même réseau.

L'idée c'est que je puisse me connecter au VPN pour accéder au donnée du serveur Windows, tout est bien configuré puisque j'accède bien au serveur Windows de mon réseau local depuis l'extérieur (192.168.1.17) lorsque j'utilise un pc Windows (Seven).

Par contre depuis mon Mac, absolument impossible, je suis bien connecté au VPN puisque mon IP publique est celle du réseau distant, mais impossible d'avoir accès au réseau local, comme si les routes était mauvaise, pourtant elles sont bonnes puisque j'y accède depuis un poste sous Windows, j'ai plus l'impression qu'un protocole pose problème.


Si vous avez la moindre idée je suis preneur parce que la je ne trouve plus..
 
Je ne sais pas si j'ai bien compris…
Client VPN Seven—internet—Box—Serveur OpenVPN—Serveur windows (192.168.1.17) Le ping 192.168.1.17 est bon
Client VPN Mac —internet—Box—Serveur OpenVPN—Serveur windows (192.168.1.17) Le ping 192.168.1.17 ne marche pas
C'est ça?
Es-tu sûr que l'adresse IP privée du client VPN Mac n'est pas aussi utilisée sur ton Lan?
C'est le serveur VPN qui attribue des adresses privées sur une plage différente (mais dans le même plan IP) de celles utilisées sur ton Lan?
Si ce n'est pas le serveur qui attribue les adresses, es-tu sûr de la conf réseau côté client?
Le protocole VPN utilisé sur le client Mac est-il le même que celui qui marche avec le client seven?
A partir du client VPN Mac, peux-tu pinguer le serveur VPN où d'autres machines de ton Lan?
As-tu essayé de faire un traceroute 192.168.1.17 pour voir jusqu'où tu vas?

Pas simple. Pour avancer, si tu n'as pas d'idée, sur le client Mac, relève son adresse IP privée (celle en 192.168.1.xxx), puis sur le serveur vpn, fais un:
tcpdump host 192.168.1.xxx
Ensuite, sur le client, fais un ping 192.168.1.17
On verra si on sort bien du serveur VPN.
 
Salut Polo35230,

Tu as bien compris ce que j'ai essayé d'expliquer, pour expliqué un peu plus précisément, j'ai suivi ce tuto la http://blog.nicolargo.com/2010/10/installation-dun-serveur-openvpn-sous-debianubuntu.html

Du coup lors de la configuration du fichier "server.conf" je me retrouve avec des IP de client avec du 10.8.0.xxx (si j'ai bien compris le tuto).
Et apparement c'est le serveur VPN qui translate les IP client avec un forward vers les IP du réseau local du VPN (192.168.1.xxx)

Du coup j'ai comme adresse sur mon client mac 10.8.0.6.

Est ce que je dois faire un tcpdump host 10.8.0.6 sur le serveur VPN?
 
Je viens de faire un essai avec le client Windows, même adresse IP privée que le client Mac et pourtant j'ai bien accès au réseau local distant sur Windows, c'est fou :O
 
Perso, je n'aurais pas fait comme ça.
Le principe du VPN, c'est que ttes les machines (locales et distantes) soient dans le même réseau privé.
Dans ton cas, tu dois avoir un réseau local en 192.168.1.0/24 (masque en 255.255.255.0)
La box à 192.168.1.1 comme adresse IP. Elle doit être serveur DHCP sur ton Lan; Plage distribuée de 10 à 50 par exemple.
Tu peux aussi avoir les machines en IP fixes sur ton Lan (par exemple de 51 à 100).
Maintenant, ton serveur VPN doit distribuer des adresses à partir de 101 à 200 (par exemple)et avec un masque 255.255.255.0.
Tout le monde se trouvera ainsi dans le même réseau local sans risquer d'avoir des adresses en double.

Ta conf peut marcher, mais ce n'est pas vraiment naturel… La partie VPN se trouve sur un plan en 10.8.0.0/16 peut-être, et ton lan en 192.168.1.0/24
Le serveur VPN doit donc avoir deux interfaces; L'une en 10, et l'autre en 192.
Pour moi, le serveur ne natera pas; c'est du routage par interface. Ca doit marcher aussi.

Pour le tcpdump, il faut le faire sur 192.168.1.17.

Maintenant, le pb sur le pc, c'est que l'adresse 192.168.1.17 ne passe pas par le VPN (qui lui est en 10.) alors que pour le mac, ça passe (pourquoi?)
 
Du coup j'ai fait la modification des Ip, tout est en 192.168.1.xxx
Et même problème, le client Windows ping tout le réseau local par contre rien pour le client .Mac, c'est vraiment étrange, j'ai comme l'impression que ma box ou autre chose refuse ou empêche le Mac d'être routé dans le réseau local distant.
 
c'est vraiment étrange, j'ai comme l'impression que ma box ou autre chose refuse ou empêche le Mac d'être routé dans le réseau local distant.
je ne pense pas que ce soit ça.
Un ping, c'est du protocole icmp. Exactement le même message, que ce soit le mac ou un pc qui l'envoie.
Le pb doit être ailleurs.
Il faut essayer de voir où ça coince.

-Sur le client Mac, passer les commandes suivantes:
traceroute 192.168.1.17
ifconfig
netstat -r

-sur le serveur vpn:
tcpdump host 192.168.1.xxx (adresse IP du client)
puis faire un ping 192.168.1.17 à partir du client
 
Je viens de faire ta procédure, alors pour le tcpdump, parfois je vois des choses passé, parfois rien.

Au niveau du ping toujours rien, enfin si j'ai remarqué que le message que m'affiche le terminal est
"ping: sendto: No route to host"
puis
"ping: sendto: Host is down"
 
Peux-tu faire un copier-coller du tcpdump stp?

tcpdump host 192.168.1.106

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

23:17:22.159931 IP 192.168.1.106.56029 > 173.194.135.114.http: Flags [F.], seq 2799739463, ack 2109782072, win 4096, options [nop,nop,TS val 847679439 ecr 162232861], length 0


Ca c'est quand je navigue sur le web depuis le client, lorsque je cherche à ping ou traceroute, rien dans le tcpdump
 
192.168.1.106 c'est le client?
Le tcpdump est bien fait sur le serveur?

-Sur le client Mac, peux-tu faire un copier coller des commandes suivantes:
traceroute 192.168.1.17
ifconfig
netstat -r
 
C'est bien ca, le tcpdump sur le serveur avec l'adresse du client et le client à bien l'adresse 192.168.1.106

Pour le traceroute :
traceroute to 192.168.1.17 (192.168.1.17), 64 hops max, 52 byte packets

1 * * *

2 * * *

3 * *traceroute: sendto: No route to host

traceroute: wrote 192.168.1.17 52 chars, ret=-1

*

traceroute: sendto: Host is down

Pour le ifconfig (juste l'interface du tunnel) :
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500

net 192.168.1.106 --> 192.168.1.105 netmask 0xffffffff

Routing tables



Internet:

Destination Gateway Flags Refs Use Netif Expire

0/1 192.168.1.105 UGSc 63 0 utun0

default 192.168.1.1 UGSc 9 0 en0

192.168.1.1/32 192.168.1.105 UGSc 1 0 utun0

192.168.1.105 192.168.1.106 UHr 90 0 utun0

90.23.146.110/32 192.168.1.1 UGSc 2 0 en0

127 localhost UCS 1 0 lo0

localhost localhost UH 4 32001 lo0

128.0/1 192.168.1.105 UGSc 25 0 utun0

169.254 link#4 UCS 1 0 en0

192.168.1 link#4 UCS 5 0 en0

192.168.1.1 24:95:4:5:82:80 UHLWIir 5 264 en0 1197

192.168.1.17 link#4 UHRLWIi 1 490 en0

192.168.1.45/32 link#4 UCS 2 0 en0

192.168.1.45 60:3:8:96:99:42 UHLWIi 1 1 lo0

192.168.1.74 d0:4f:7e:1c:af:d1 UHLWIi 1 553 en0 1147

192.168.1.255 link#4 UHLWbI 1 693 en0



Internet6:

Destination Gateway Flags Netif Expire

localhost localhost UHL lo0

fe80::%lo0 localhost UcI lo0

localhost link#1 UHLI lo0

fe80::%en0 link#4 UCI en0

apple-tv.local d0:4f:7e:1c:af:d1 UHLWIi en0

macbook-pro-de-ale 60:3:8:96:99:42 UHLI lo0

fe80::%awdl0 link#8 UCI awdl0

macbook-pro-de-ale 22:90:dc:5c:66:b8 UHLI lo0

ff01::%lo0 localhost UmCI lo0

ff01::%en0 link#4 UmCI en0

ff01::%awdl0 link#8 UmCI awdl0

ff02::%lo0 localhost UmCI lo0

ff02::%en0 link#4 UmCI en0

ff02::%awdl0 link#8 UmCI awdl0


En tout cas je te remercie de ta patiente et de ton aide :)
 
Pour moi, si on regarde les tables de routage du client, l'adresse 192.168.1.17 n'est pas routée vers le tunnel.
(192.168.1.17 link#4 UHRLWIi 1 490 en0)
Pour que ça marche, elle ne devrait pas être routée vers en0, mais vers utun0

Curieuse,ta table de routage. Plein de choses.
Il y a dû avoir des routes rajoutées manuellement. Certaines sont redondantes….
Il faudrait mettre à plat la conf réseau du client.
Un ifconfig complet aurait donné plus d'indications sur celle-ci. Quelque chose me dit que l'interface en0 est peut-être aussi sur un plan 192.168.1.0/24

Le traceroute ne donne pas d'indications, si ce n'est que les deux premiers équipements traversés sont configurés pour ne pas répondre, et que le troisième ne peut pas router cette adresse. Ces équipements doivent être sur le Lan du client.
 
Bonjour,

Nous rencontrons actuellement le même problème avec la même configuration que vous.

Nous avons constaté avec un collègue que le problème se rencontre lorsque les utilisateurs ont une box FAI qui leur distribue la même plage d'adresse IP qu'a l'entreprise. (Pas de problème en partage de connexion 4G avec un téléphone portable)

En solution provisoire, nous avons mis en place un petit script qui doit être exécuté par les utilisateurs après la connexion au réseau VPN pour y ajouter une route.

Cette solution reste assez contraignante pour nos utilisateurs, avez-vous une autre méthode pour résoudre cette problématique ?

Vous en remerciant par avance.

Cordialement
Hervé
 
Bonjour,

Nous rencontrons actuellement le même problème avec la même configuration que vous.

Nous avons constaté avec un collègue que le problème se rencontre lorsque les utilisateurs ont une box FAI qui leur distribue la même plage d'adresse IP qu'a l'entreprise. (Pas de problème en partage de connexion 4G avec un téléphone portable)

En solution provisoire, nous avons mis en place un petit script qui doit être exécuté par les utilisateurs après la connexion au réseau VPN pour y ajouter une route.

Cette solution reste assez contraignante pour nos utilisateurs, avez-vous une autre méthode pour résoudre cette problématique ?

Vous en remerciant par avance.

Cordialement
Hervé
Bonjour,
je rencontre le même problème avec un utilisateur Macbook pro... pouvez-vous partager le script que vous avez mis en place?

merci

cdt
 
Bonjour,

Inutile de faire un script
Vous pouvez aussi ajouter une route sur une configuration VPN spécifique avec la commande networksetup.
Exemple :
Pour obtenir la liste des services :
Bloc de code:
networksetup -listallnetworkservices
Pour ajouter la route
Bloc de code:
networksetup -setadditionalroutes <networkservice> [ <dest> <mask> <gateway> ]
Exemple :
Bloc de code:
networksetup -setadditionalroutes "Mon VPN" 10.10.50.0 255.255.255.0 10.10.50.1
Pour vérifer que la route a bien été ajoutée :
Bloc de code:
networksetup -getadditionalroutes "Mon VPN"
Pour supprimer la route (ne pas mettre les arguments)
Bloc de code:
networksetup -setaddtionalroutes "MON VPN"

A noter qu'il n'est donc plus nécessaire d'envoyer tout le trafic sur la connexion VPN
 
Bonsoir,
merci pour votre réponse, n'étant pas spécialiste Mac, je me doutais bien qu'il y avait un problème de route. Je ne comprend pas pourquoi ce même VPN fonctionnera sans créer de route pour un utilisateur Windows...
En tout cas, je testerai cette solution dès lundi et je vous ferais un retour.
Par contre, contrairement à la personne juste au dessus de ma demande, cela ne fonctionne pas même en connexion 4G.

cdt