----- Original Message -----
From: "Pascal Hambourg" <pas...@plouf.fr.eu.org>
To: debian-user-french@lists.debian.org
Sent: Wednesday, January 9, 2019 7:49:45 PM
Subject: Re: Réseau : accès VPN et LAN simultanés
Le 09/01/2019 à 08:35, roger.tar...@free.fr a écrit :
>
> MACHINE 1
>
> $ ip route
> default via FREEBOX_IP dev tun0 # correspond à freeplayer.freebox.fr
> default via FREEBOX_IP dev tun0 proto static metric 1024
Bizarre qu'il y ait deux routes par défaut pour le tunnel, mais passons.
Que représente FREEBOX_IP ?
Réponse :
correspond à freeplayer.freebox.fr (212.27.38.253)
De cette page web tu peux entrer l'adresse de ta box si tu l'as configurée pour
t'y connecter à distance (https://monbidule.freeboxos.fr:40870) .
> FREEBOX_IP_PUBLIQUE via LAN_GATEWAY_IP dev eth0
Que représente FREEBOX_IP_PUBLIQUE ? Normalement ça devrait être
l'adresse IP publique du serveur VPN.
Réponse :
C'est "l'IP publique de la box" utilisée par les clients VPN (visible dans le
fichier de conf client openvpn). Donc, oui c'est l'IP publique du serveur VPN.
> 192.168.0.0/24 dev eth0 proto kernel scope link src LAN_CLIENT_IP1 #
> IP_LAN est en 192.168.
> IP_VPN_CLIENT/27 via FREEBOX_IP dev tun0
> FREEBOX_IP dev tun0 proto kernel scope link src VPN_CLIENT_IP1
> $ iptables-save
> bash: iptables-save: command not found
Il faut l'exécuter en tant que root.
Réponse :
hum.. oui !
Sur cette machine, exécuter en root n'est pas exigé car l'utilisateur a /sbin
dans son PATH et accède donc directement à itables-save.
c'est un RPi3b en Raspbian8, et d'ailleurs c'est configuré d'office.
> MACHINE 2
>
> $ ip route
> default via FREEBOX_IP dev tun0
> FREEBOX_IP_PUBLIQUE via LAN_GATEWAY_IP dev eth0
> 192.168.0.0/24 via FREEBOX_IP dev tun0
Cette route est erronée. Elle ne devrait pas exister et est la cause
probable de la perte de connectivité entre les deux machines : celle-ci
croit que l'autre est joignable via le VPN, mais le serveur de VPN ne
route pas ce préfixe.
Si elle est mise en place par l'ouverture du VPN, il faut rechercher
quelle est l'option erronée qui la crée dans la configuration VPN du
client (route) ou du serveur (push).
Réponse :
ce résultat de ip route correspond à une situation avec connectivité via VPN ou
via LAN entre les 2 machines.
J'ai fait un test en modifiant /etc/network/interfaces
où j'ai commenté les directives (optionnelles) qui sont absentes de l'autre
machine qui
# gateway 192.168.0.1
# network 192.168.0.1
# broadcast 192.168.0.255
ça ne change rien
J'ai refait ip route avec/sans VPN :
MACHINE 2
avecVPN
$ ip route
default via FREEBOX_IP dev tun0
FREEBOX_IP_PUBLIQUE via 192.168.0.1 dev eth0
192.168.0.0/24 via 192.168.0.1 dev eth0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.101 metric
202
IP_VPN_CLIENT2/27 via FREEBOX_IP dev tun0
FREEBOX_IP dev tun0 proto kernel scope link src 192.168.27.70
sans VPN
$ ip route
default via 192.168.0.1 dev eth0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.101 metric
202
Je ne peux pas couper eth0 (sudo ifdown eth0) pour avoir juste le vpn,
puisqu'il passe par ce seul tuyau ethernet. Et donc ça va tout couper même le
lien vpn.
D'ailleurs, est-ce possible ?
Et est-ce pertinent ?
En même temps, le client vpn ne gère-il pas son affaire grâce à la directive
ajouté au fichier de conf ? (route 192.168.40.0 255.255.255.0 net_gateway)
> 192.168.0.0/24 dev eth0 proto kernel scope link src LAN_CLIENT_IP2 metric
> 202
> IP_VPN_CLIENT2/27 via FREEBOX_IP dev tun0
> FREEBOX_IP dev tun0 proto kernel scope link src VPN_CLIENT_IP2
>
> $ iptables-save
> # rien