OpenVPN - Raspbian - problème local

Wazis · Mars 21, 2017, 9:54am

Bonjour,

J’ai bien évidemment regardé chez notre pote google mais rare sont les sujets résolue pour mon problème.
Je vais essayer de faire simple et précis.

Mon OpenVPN fonctionne, mon client peut s’y connecter. Mais tout ne fonctionne pas.

L’accès à mon partage de fichier samba n’est pas accessible depuis l’intérieur de mon VPN.
L’accès à mon Raspberry en ssh depuis mon réseau local, donc chez moi sur mon routeur en 192.168/24 ne fonctionne pas.
Je peux pas contre accéder à mon SSH depuis mon adresse IP public, en parallèle du VPN.
Je peux aussi pinger mon raspberry avec l’adresse local à l’intérieur du VPN, et accéder à internet en modifiant une règle d’“iptables”.

Je ne sais pas si c’est normal, ça l’est peut-être, je pense sois à une règle de routage interne à mon raspberry, ou bien au firewall mais normalement aucune règle n’est modifié. Suivant ce dont vous avez besoin dites-moi et je vous mettrai le résultat des commandes.

Mon adresse pour le VPN est de la forme 10.8/24 et ma configuration est fortement inspiré du lien suivant :
http://www.bexen.fr/2016/03/15/raspberry-pi-installation-et-configuration-dopenvpn/

Merci à ceux qui prendront le temps !

ostyll971 · Mars 17, 2017, 8:48pm

Bonsoir,
Tout d’abord il nous faudrait un peu plus info sur ta configuration, le fichier conf ssh et openvpn serait la bien venu pour commencer.

Wazis · Mars 18, 2017, 2:09pm

Très bien !

Alors le fichier ssh_config, que je n’ai jamais modifié :

> Host *
> #   ForwardAgent no
> #   ForwardX11 no
> #   ForwardX11Trusted yes
> #   RhostsRSAAuthentication no
> #   RSAAuthentication yes
> #   PasswordAuthentication yes
> #   HostbasedAuthentication no
> #   GSSAPIAuthentication no
> #   GSSAPIDelegateCredentials no
> #   GSSAPIKeyExchange no
> #   GSSAPITrustDNS no
> #   BatchMode no
> #   CheckHostIP yes
> #   AddressFamily any
> #   ConnectTimeout 0
> #   StrictHostKeyChecking ask
> #   IdentityFile ~/.ssh/identity
> #   IdentityFile ~/.ssh/id_rsa
> #   IdentityFile ~/.ssh/id_dsa
> #   Port 22
> #   Protocol 2,1
> #   Cipher 3des
> #   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
> #   MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
> #   EscapeChar ~
> #   Tunnel no
> #   TunnelDevice any:any
> #   PermitLocalCommand no
> #   VisualHostKey no
> #   ProxyCommand ssh -q -W %h:%p gateway.example.com
> #   RekeyLimit 1G 1h
>     SendEnv LANG LC_*
>     HashKnownHosts yes
>     GSSAPIAuthentication yes
>     GSSAPIDelegateCredentials no

et le server.conf de openvpn :

local 192.168.0.45 # ADRESSE IP INTERNE DU SERVEUR
dev tun
proto tcp #PROTOCOLE
port 1194 #PORT
ca /etc/openvpn/easy-rsa/keys/ca.crt #CHEMIN ca.crt
cert /etc/openvpn/easy-rsa/keys/RPi.crt #CHEMIN "serveur".crt
key /etc/openvpn/easy-rsa/keys/RPi.key #CHEMIN "serveur".key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem # VERIFIER CETTE VALEUR

server 10.8.0.0 255.255.255.0
# server and remote endpoints
ifconfig 10.8.0.1 10.8.0.2

# Add route to Client routing table for the OpenVPN Server
push "route 10.8.0.0 255.255.255.255"

# Add route to Client routing table for the OpenVPN Subnet
push "route 10.8.0.1 255.255.255.0"

# your local subnet
push "route 192.168.0.0 255.255.255.0" # VOTRE RESEAU

# Set primary domain name server address to the SOHO Router
# If your router does not do DNS, you can use Google DNS 8.8.8.8
push "dhcp-option DNS 192.168.0.254" # VOTRE ROUTEUR
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
client-to-client
duplicate-cn
keepalive 10 120
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
verb 1

Et un petit iptables :

sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-ssh tcp – anywhere anywhere multiport dports ssh

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all – anywhere anywhere

Merci merci !

Almtesh · Mars 18, 2017, 5:09pm

Bonjour,

Oulà, commence par le plus bas niveau, essaie de faire un ping avant de tester samba.
Essaie déjà de communiquer (avec ping, au début) entre le client et le serveur OpenVPN. Ça permet déjà de savoir si ton VPN est connecté.
Après, tu fais un ping vers un hôte un peu plus loin, pour voir.

Autre chose, pour nous donner tes règles iptables, utilises plutôt iptables-save, ça fait comme la banane (ça a le même goût à l’aller et au retour).

Wazis · Mars 19, 2017, 8:59am

Hey !

(c’est marrant on habite juste à côté, je suis à Artigues… )

C’est partis on reprend du début :

iptables-save -c de mon raspberry :

# Generated by iptables-save v1.4.21 on Sun Mar 19 09:15:17 2017
*filter
:INPUT ACCEPT [514464:486200892]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [421383:213269723]
:fail2ban-ssh - [0:0]
[2864:222326] -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
[2829:219230] -A fail2ban-ssh -j RETURN
COMMIT
# Completed on Sun Mar 19 09:15:17 2017

Ensuite, je lance mon openvpn-server sur mon raspberry puis effectue un ifconfig :

ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:60:c6:59  
          inet addr:192.168.0.45  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: 2a01:e34:ec6f:2090:259d:7087:1453:d024/64 Scope:Global
          inet6 addr: fe80::2a15:87a4:3407:7ef4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5508264 errors:0 dropped:44 overruns:0 frame:0
          TX packets:4647397 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1249140288 (1.1 GiB)  TX bytes:1958921971 (1.8 GiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:11102 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11102 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:1245404 (1.1 MiB)  TX bytes:1245404 (1.1 MiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

J’active ma configuration VPN depuis mon poste client, mon système m’indique que la connexion a bien été établie. Je lance un terminal puis lance un ifconfig :

ifconfig
enp4s0f2  Link encap:Ethernet  HWaddr 74:d0:2b:d8:78:91  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)

lo        Link encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          Packets reçus:2394 erreurs:0 :0 overruns:0 frame:0
          TX packets:2394 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1 
          Octets reçus:270429 (270.4 KB) Octets transmis:270429 (270.4 KB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet adr:10.8.0.6  P-t-P:10.8.0.5  Masque:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
          TX packets:148 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:100 
          Octets reçus:0 (0.0 B) Octets transmis:15946 (15.9 KB)

wlp3s0    Link encap:Ethernet  HWaddr 24:0a:64:2f:d5:3b  
          inet adr:192.168.43.104  Bcast:192.168.43.255  Masque:255.255.255.0
          adr inet6: fe80::6cd1:2de9:731:5476/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:52539 erreurs:0 :0 overruns:0 frame:0
          TX packets:34158 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          Octets reçus:64896803 (64.8 MB) Octets transmis:4710851 (4.7 MB)

Je lance plusieurs test de ping depuis mon poste client qui à lancé le VPN:

-CientVPN -> Serveur VPN(raspberry) : ping 192.168.0.45 = OK
-CientVPN -> 192.168.0.254 (passerelle) = WRONG
-CientVPN -> 10.8.0.1 = OK
-CientVPN -> 192.168.43.1 = OK

Si je suis un peu la chose, mon serveur et mon client sont bien sur le même réseau 10.8.0.0/32 (normal?). En tous cas, ils arrivent à communiquer.

Par contre sur le “wlp3s0” du client l’adresse est de type 192.168.43/24 au lieu d’être en 192.168.0/24. Ce qui expliquerait qu’aucune connexion ne soit possible. Si je ne me trompe pas.

Par contre à quel moment ce networkID de .43 est donné ? aucune idée.

En tous cas, merci !

AnonymousCoward · Mars 19, 2017, 1:30pm

Hello,

Tout d’abord le radotage habituel : Les vieilles commandes ifconfig, route et arp sont obsolètes depuis 2002 !
Il FAUT désomais utiliser les commandes ip link ls , ip -4 addr ls, ip -4 route ls ETC à la place.

Voir http://baturin.org/docs/iproute2/ .

Outre que pas mal de fonctionnalités ne marchent pas avec ifconfig, celle-ci utilise la notation classful avec les masques de sous-réseau du genre 255.255.255.0 au lieu de /24 , ce qui rend les choses moins faciles à comprendre.

Concernant ton problème avec OpenVPN… Ton client prend l’adresse IP 10.8.0.6 et obtient des routes qui ont l’air correctes et peut envoyer des paquets aux machines telles que 192.168.0.254 (une freebox ?).
Le problème est que les machines telles que 192.168.0.254 n’ont aucune idée de la route / des routes spécifique(s) pour envoyer des paquets à 10.8.0.6 en retour.

Pour résoudre le problème il faudrait ajouter aux systèmes concernés une route pour le sous-réseau 10.8.0.0/24 via 192.168.0.45 .
(Si 192.168.0.254 est une freebox, c’est un soucis car les freeboxs sont artificiellement bridées et on ne peut pas leur ajouter de route)

Si tu fais cela, que ça fonctionne et que tu veux le péréniser, il faudra ajouter la route de manière persistante (CAD qu’elle revient après un redémarrage).
C’est plus facile à faire sur un Windows que sur un Linux et c’est dommage. Mais c’est possible.

–
AnonymousCoward

Almtesh · Mars 19, 2017, 9:10pm

Salut,

Oui, c’est la première chose que je me suis dite en lisant ta réponse. Ensuite.

Oui, donc, le client a la route vers 192.168.0.0/24.

Évidemment, eux aussi.C’est un bon début, mais

« WRONG » n’est pas une erreur connue de la commande ping, mais je vois ce que tu veux dire.
En fait, 192.168.0.254 ne connait pas la route vers 10.8.0.6. Tu as donc deux solutions : soit tu fais du NAT sur ton serveur OVPN, soit tu configures la route sur 192.168.0.254.

Wazis · Mars 21, 2017, 9:55am

Merci pour vos réponses.

Déjà, incroyable que je n’ai jamais entendu parlé de iproute2. Je me remet tout juste au réseau ainsi qu’à linux mais partout où je lis et me forme on ne m’en avais encore jamais parlé … donc merci.

Ensuite, effectivement c’est bien une freebox. Du coup je pars sur la recherche de configuration du NAT.

Est-ce qu’en me basant sur quelque chose de la sorte cela pourrait fonctionner ?

https://memo-linux.com/configurer-un-simple-petit-routeur-nat-sous-debian-jessie/

edit :

En suivant le tuto juste au dessus j’ai appliqué la commande suivante :

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Peut-être mieux en faisant :

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

A présent, le ping entre mon client VPN vers ma passerelle .254 ainsi que les autres hôtes de mon réseau local est OK.

La découverte de mon réseau samba n’est pas fonctionnel, mais en entrant l’adresse de mon réseau samba dans mon explorateur j’accède aux dossiers. J’ai tout de même une erreur pour accéder aux dossiers : “impossible de monter le partage windows, argument invalide.”.

Mais ce problème ce situe sûrement plus au niveau de la configuration samba, il à l’air assez “chatouilleux” pour le partage de fichiers hors de sa localisation.

Ma problématique première est donc résolue, je n’ai pas exactement compris le pourquoi du comment de la commande que j’ai entré, il faut encore que j’étudie tout ce qui touche au routage, NAT, bridge, et puis l’iproute2 en passant

Encore merci à vous 2 !

Almtesh · Mars 21, 2017, 8:35am

Bonjour,

Pour marquer un sujet comme résolu, merci de ne pas modifier son titre pour ajouter « [Résolue] », mais cliquer sur la coche dans le message qui t’a permis de résoudre ton problème.

Merci.