Le 09/01/2019 à 21:21, roger.tar...@free.fr a écrit :
----- Original Message -----
From: "Pascal Hambourg" <pas...@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.tar...@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.