[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Le 09/01/2019 à 21:21, roger.tarani@free.fr a écrit :

----- Original Message -----
From: "Pascal Hambourg" <pascal@plouf.fr.eu.org>

Serait-il possible de configurer ton logiciel de messagerie pour citer correctement (avec des marques de citation ">") le message auquel tu réponds, parce que là c'est difficile à lire.

Le 09/01/2019 à 08:35, roger.tarani@free.fr a écrit :

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.

Tu aurais pu préciser que le serveur VPN était une freebox. Je pensais, parce que c'est la situation la plus courante, que la freebox était la box internet des deux clients, et du coup je ne comprenais pas.

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

Et franchement, pas besoin de caviarder toutes ces adresses IP. L'adresse du freeplayer est la même pour toutes les box. Quant aux adresses privées des clients, elles ne sont pas uniques et injoignables depuis l'extérieur.

$ 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.

Il ne suffit pas que l'exécutable soit dans le $PATH (ce qui n'est manifestement pas le cas d'après la réponse de bash), il faut aussi l'exécuter avec les privilèges root.

c'est un RPi3b en Raspbian8, et d'ailleurs c'est configuré d'office.

Peu importe.

MACHINE 2
(...)
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.

Je ne comprends pas ce que tu veux dire.

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

Si l'interface est configurée avec la méthode "static", l'absence de l'option gateway l'empêchera d'atteindre l'extérieur du réseau.

# network 192.168.0.1

Cette valeur est invalide. L'adresse de réseau est par convention la première adresse du préfixe, 192.168.0.0, et traitée comme une adresse de broadcast quand elle est définie.

ça ne change rien

Normal. J'ai dit que cette route venait de la configuration du VPN, pas du fichier interfaces.

J'ai refait ip route avec/sans VPN :

Résultat qui confirme que la route est ajoutée par le VPN.

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.

Je n'ai jamais dit de couper eth0. Pourquoi vouloir faire une chose pareille ? Non seulement cela couperait le VPN, mais cela couperait aussi la communication directe sur le LAN avec l'autre machine.

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)

Cette directive est juste une rustine qui sert à masquer une erreur de configuration.


Reply to: