Re: Réseau : accès VPN et LAN simultanés

[roger.tarani@free.fr]

----- Original Message -----
From: "Pascal Hambourg" <pascal@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.tarani@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