web-dev-qa-db-fra.com

Pourquoi mon client OpenVPN ne peut-il pas accéder aux machines sur le même réseau local que le serveur OpenVPN?

J'ai configuré OpenVPN sur mon serveur Linux et mon client Windows conformément aux instructions ici . Mon client peut accéder au serveur, mais ne peut plus accéder au réseau local.

Mon serveur est 10.23.29.64/24, mon sous-réseau OpenVPN est 10.23.30.0/24 et mon client est 10.0.0.71/24, il n'y a donc pas de chevauchement.

Le fichier de configuration de mon serveur est:

port 53
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.23.30.0 255.255.255.0
ifconfig-pool-persist ipp.txt
Push "route 10.23.29.0 255.255.255.0"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

La configuration de mon client est

client
dev tun
proto udp
remote HOSTNAME_REMOVED 53
resolv-retry infinite    
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3

Une fois connecté, mon client obtient le 10.23.30.6/30 et a 4 itinéraires ajoutés:

   10.23.29.0    255.255.255.0       10.23.30.5      10.23.30.6       1
   10.23.30.1  255.255.255.255       10.23.30.5      10.23.30.6       1
   10.23.30.4  255.255.255.252       10.23.30.6      10.23.30.6       30
   10.23.30.6  255.255.255.255        127.0.0.1       127.0.0.1       30

Mon serveur reçoit 10.23.30.1/32 (HAPPAGES CELA IS DU PROBLÈME?)

Mon client peut envoyer une requête ping au serveur le 10.23.30.1 et le 10.23.29.64, mais il ne peut aller plus loin. Que dois-je faire d'autre pour que ce client ait accès au reste de mon réseau local?

METTRE À JOUR:

J'ai ajouté une route statique à mon routeur afin que sa table de routage ressemble à ceci

{admin}=>ip rtlist
Label             Destination          Gateway  Interface     Mtc Admin  Oper
                 10.0.0.138/32       127.0.0.1  loop          0   UP     [UP]
                 10.0.0.255/32       127.0.0.1  loop          0   UP     [UP]
               10.23.29.254/32       127.0.0.1  loop          0   UP     [UP]
               10.23.29.255/32       127.0.0.1  loop          0   UP     [UP]
             87.115.131.206/32       127.0.0.1  loop          0   UP     [UP]
                  127.0.0.1/32       127.0.0.1  loop          0   UP     [UP]
            255.255.255.255/32       127.0.0.1  loop          0   UP     [UP]
            195.166.128.189/32  87.115.131.206  Internet      0   UP     UP
                212.159.6.9/32                  Internet      10  UP     UP
               212.159.6.10/32                  Internet      10  UP     UP
                   10.0.0.0/24      10.0.0.138  LocalNetwork  0   UP     [UP]
                 10.23.29.0/24    10.23.29.254  LocalNetwork  0   UP     [UP]
                 10.23.30.0/24     10.23.29.10  LocalNetwork  0   UP     [UP]
                    0.0.0.0/0                   Internet      10  UP     UP

mais quand j'ai fait un traceroute du 10.23.29.10 au 10.23.30.1 j'ai eu:

traceroute to 10.23.30.1 (10.23.30.1), 30 Hops max, 60 byte packets
 1  dsldevice.lan (10.23.29.254)  2073.983 ms  2073.481 ms  74.545 ms
 2  * * *

et toutes les étoiles jusqu'à ce qu'il abandonne. Cela me porte à penser que les paquets traceroute ne sont pas transférés vers 10.23.29.10 comme le dit la table de routage.

vpnroutingopenvpnsubnetnetmask
5
Grezzo

J'ai finalement découvert quel était le problème. J'utilise l'option "routage" d'OpenVPN, qui crée un nouveau sous-réseau pour toutes les connexions OpenVPN. Une adresse IP de ce sous-réseau a été attribuée à mon client, de même que mon serveur, afin qu'ils puissent communiquer entre eux via ce réseau. Avec le transfert IPv4 activé sur mon serveur, je pouvais également envoyer des paquets sur mon réseau local et j'étais évidemment capable de parler au serveur via son adresse IP de réseau local.

Lorsque le client a essayé de communiquer avec d'autres ordinateurs de mon réseau local, les paquets de ce dernier ont atteint mes hôtes du réseau local (je n'ai pas vérifié cela, mais je suis presque certain qu'ils l'étaient), mais l'adresse source de ces paquets était le adresse du réseau OpenVPN. Les hôtes du réseau local savaient que ce n'était pas sur leur réseau local et la seule chose qu'ils savaient faire dans ce cas était de les envoyer à la passerelle par défaut, qui était mon routeur. Je doute que cela leur ait fait quelque chose, car envoyer un paquet à une plage IP privée sur Internet est inutile.

La solution consiste à ajouter une route statique à tous les hôtes du réseau local ou à utiliser l'option "pontage" d'OpenVPN au lieu de "routage". Je ne l'ai pas encore fait, mais je suis sûr que c'est la voie à suivre.

6
Grezzo

Je ne pense pas que vous deviez ajouter une route statique à tous les hôtes LAN. Vous pouvez simplement ajouter une route statique dans votre passerelle sur ce réseau local, en pointant toutes les adresses réseau openvpn sur le serveur openvpn "adresse lan-ip".

2
anony

Même problème avec ma config, mais corrigé maintenant:

Comme vous utilisez les paramètres OpenVPN Road warrior, les paquets sont notés comme étant acheminés mais mis en NAT. Vous devez configurer vos options sortantes NAT afin de convertir tous les ports sources d'adresses IP virtuelles OpenVPN sur une interface de réseau local vers tous les ports de destination dotés de l'adresse WAN NAT.

Dans pfSense, vous devez désactiver la règle automatique sortante NAT dans la règle manuelle sortante NAT et simplement ajouter une nouvelle règle pour le réseau interne OpenVPN.

1
AsynKc

Avait le même problème ici (en utilisant ce guide pour configurer: https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-14- 04 )

La réponse d'Anony à propos de la route statique était la clé. Sur dd-wrt sous setup -> routage avancé:

configuration de route statique dd-wrt

Où

  • destination: openvpn tun0 interface
  • Gateway: serveur en cours d'exécution openvpn (lan ip)

Cela a fait le tour pour moi!

0
Tom Ratcliff