cerhu > linux.debian.user.french

roger.tarani (09/01/2019, 03h30)
Bonjour
J'ai un petit blocage sur un sujet de réseau :
Openvpn client est installé sur 2 machiness Jessie qui sont sur le même LAN.
Le serveur est dans un lieu différent.
Dès que la connexion vpn est demarrée, impossible de communiquer via le LAN entre les deux machines. Seule l'adresse IP du VPN est accessible.
C'est surtout gênant pour les gros transferts de fichiers.

Mon intuition me dit que c'est une plutôt bonne chose pour la sécurité. Mais si le LAN est protégé, ça me va qu'une machine soit accessible simultanément via VPN et via LAN.

Si par ailleurs j'arrive à faire tourner ce réseau correctement, là je ne sais pas trop comment faire.
La seule chose que je n'ai pas abordée c'est du côté du FW où mes connaissances sont basiques. Je n'ai pas vu de FW installé ou pas su en voir.

J'ai cherché sur le net sans trouver de solution.
Comment faudrait-il procéder ?
Merci
Jérémy Prego (09/01/2019, 03h40)
Le 09/01/2019 à 02:23, roger.tarani a écrit :
> Bonjour


bonjour,

> J'ai un petit blocage sur un sujet de réseau :
> Openvpn client est installé sur 2 machiness Jessie qui sont sur le même LAN.
> Le serveur est dans un lieu différent.
> Dès que la connexion vpn est demarrée, impossible de communiquer via le LAN entre les deux machines. Seule l'adresse IP du VPN est accessible.
> C'est surtout gênant pour les gros transferts de fichiers.
> Mon intuition me dit que c'est une plutôt bonne chose pour la sécurité. Mais si le LAN est protégé, ça me va qu'une machine soit accessible simultanément via VPN et via LAN.
> Si par ailleurs j'arrive à faire tourner ce réseau correctement, là je ne sais pas trop comment faire.
> La seule chose que je n'ai pas abordée c'est du côté du FW où mes connaissances sont basiques. Je n'ai pas vu de FW installé ou pas su en voir.
> J'ai cherché sur le net sans trouver de solution.
> Comment faudrait-il procéder ?


dans le fichier openvpn sur les clients ou sur le serveur

client:
route 192.168.40.0 255.255.255.0 net_gateway

ou serveur:

push "route 192.168.40.0 255.255.255.0 net_gateway"

192.168.40 est à changer selon l'IP de ton réseau local par exemple, si
l'ip est 192.168.1.37 mettre 192.168.1.0.
par ailleurs, vérifier que l'ip du vpn est bien dans un sous réseau
différent, par défaut 10.8.0.x
> Merci

avec plaisir. :)
Pascal Hambourg (09/01/2019, 08h30)
Le 09/01/2019 à 02:35, Jérémy Prego a écrit :
> Le 09/01/2019 à 02:23, roger.tarani a écrit :
>> J'ai un petit blocage sur un sujet de réseau :
>> Openvpn client est installé sur 2 machiness Jessie qui sont sur le même LAN.
>> Le serveur est dans un lieu différent.
>> Dès que la connexion vpn est demarrée, impossible de communiquer via le LAN entre les deux machines. Seule l'adresse IP du VPN est accessible.
>> C'est surtout gênant pour les gros transferts de fichiers.


Peux-tu poster la table de routage et le jeu de règles iptables des deux
machines lorsqu'elles sont connectées au VPN ?

ip route
iptables-save

> dans le fichier openvpn sur les clients ou sur le serveur
> client:
> route 192.168.40.0 255.255.255.0 net_gateway


En quoi est-ce censé répondre au besoin ?
Je ne pense pas que Roger souhaite que les communications entre les deux
machines passent par le VPN (cf. phrase sur le transfert de gros fichiers).
roger.tarani (09/01/2019, 09h40)
Oui, les communications entre les deux machines sur le même LAN doivent se faire hors VPN car le serveur VPN est distant et accessible par un petit tuyau.

MACHINE 1

$ ip route
default via FREEBOX_IP dev tun0 # correspond à freeplayer.freebox.fr
default via FREEBOX_IP dev tun0 proto static metric 1024
FREEBOX_IP_PUBLIQUE via LAN_GATEWAY_IP dev eth0
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

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

Merci

----- Original Message -----
From: "Pascal Hambourg" <pascal>
To: debian-user-french
Sent: Wednesday, January 9, 2019 7:25:55 AM
Subject: Re: Réseau : accès VPN et LAN simultanés

Le 09/01/2019 à 02:35, Jérémy Prego a écrit :
> Le 09/01/2019 à 02:23, roger.tarani a écrit :
>> J'ai un petit blocage sur un sujet de réseau :
>> Openvpn client est installé sur 2 machiness Jessie qui sont sur le même LAN.
>> Le serveur est dans un lieu différent.
>> Dès que la connexion vpn est demarrée, impossible de communiquer via le LAN entre les deux machines. Seule l'adresse IP du VPN est accessible.
>> C'est surtout gênant pour les gros transferts de fichiers.


Peux-tu poster la table de routage et le jeu de règles iptables des deux
machines lorsqu'elles sont connectées au VPN ?

ip route
iptables-save

> dans le fichier openvpn sur les clients ou sur le serveur
> client:
> route 192.168.40.0 255.255.255.0 net_gateway


En quoi est-ce censé répondre au besoin ?
Je ne pense pas que Roger souhaite que les communications entre les deux
machines passent par le VPN (cf. phrase sur le transfert de gros fichiers).
Jérémy Prego (09/01/2019, 09h50)
Le 09/01/2019 à 07:25, Pascal Hambourg a écrit :
> Le 09/01/2019 à 02:35, Jérémy Prego a écrit :
> Peux-tu poster la table de routage et le jeu de règles iptables des
> deux machines lorsqu'elles sont connectées au VPN ?
> ip route
> iptables-save
> Je ne pense pas que Roger souhaite que les communications entre les
> deux machines passent par le VPN (cf. phrase sur le transfert de gros
> fichiers).


ça tombe bien, c'est le but de net_gateway par oposition a l'option
vpn_gateway.

Jerem
roger.tarani (09/01/2019, 10h30)
Je vais essayer. C'est simple, une ligne.

A part constater que la communication fonctionne entre elles via le LAN lorsque les machines sont aussi reliées au VPN, quel outil SIMPLE utiliser pour vérifier les liens et les flux ?
Je connais un peu nmap mais c'est de la grosse artillerie (pour moi). Ce pbréseau est l'occasion de se mettre à jour.

Bonne journée

----- Original Message -----
From: "Jérémy Prego" <jeremy>
To: debian-user-french
Sent: Wednesday, January 9, 2019 8:47:07 AM
Subject: Re: Réseau : accès VPN et LAN simultanés

Le 09/01/2019 à 07:25, Pascal Hambourg a écrit :
> Le 09/01/2019 à 02:35, Jérémy Prego a écrit :
> Peux-tu poster la table de routage et le jeu de règles iptables des
> deux machines lorsqu'elles sont connectées au VPN ?
> ip route
> iptables-save
> Je ne pense pas que Roger souhaite que les communications entre les
> deux machines passent par le VPN (cf. phrase sur le transfert de gros
> fichiers).


ça tombe bien, c'est le but de net_gateway par oposition a l'option
vpn_gateway.

Jerem
Eric Degenetais (09/01/2019, 11h20)
bonjour,
Le mer. 9 janv. 2019 à 09:22, <roger.tarani> a écrit :
[..]
> ça tombe bien, c'est le but de net_gateway par oposition a l'option
> vpn_gateway.
> Jerem


Éic Dégenètais
roger.tarani (09/01/2019, 15h10)
La modification du fichier de configuration du client vpn a régléinstantanément le problème.
En l'occurence :
route 192.168.0.0 255.255.255.0 net_gateway # permettre intercom via LAN

Avec traceroute :
on lit la route immédiate pour accéder via VPN, et on visualise le cas où il y a blocage entre les 2 machines via le LAN. Ça confirme en termes de réseau le blocage observé.

MACHINE 1
1 * * *
2 * * *
3 * * *
4 * * *
MACHINE 2
1 freeplayer.freebox.fr (FREEPLAYER) 39.753 ms 39.531 ms 39.427 ms
2 freeplayer.freebox.fr (FREEPLAYER) 3139.230 ms !H 3139.549 ms !H 3139.457 ms !H

Problème résolu.
Merci.

PS : une question de sécurité qui devrait intéresser les gens, je crois :
Est-il normal que l'adresse IP d'une machine du LAN soit visible depuis un site internet auquel elle se connecte par un navigateur ??
On la lit en clair, par exemple avec [..] qui fournit d'abord (et c'est normal) l'adresse IP publique du réseau (de la Box).

D'accord, c'est la machine qui se connecte via un navigateur à ce site.. Mais ça me gêne dans le principe. Quand on veut pouvoir accéder à une machine du LAN via l'IP publique, on fait du NAT ou du PAT puisqu'elle n'est pas accessible directement.

Est-ce un danger ?
Si oui, y a-t-il une solution ? (tiens, là je sens que l'on va me parler de FW que je devrais configurer...)

----- Original Message -----
From: "Eric Degenetais" <edegenetais>
To: "roger tarani" <roger.tarani>
Cc: "ML Debian User French" <debian-user-french>
Sent: Wednesday, January 9, 2019 10:10:47 AM
Subject: Re: Réseau : accès VPN et LAN simultanés

bonjour,
Le mer. 9 janv. 2019 à 09:22, <roger.tarani> a écrit :
[..]
> ça tombe bien, c'est le but de net_gateway par oposition a l'option
> vpn_gateway.
> Jerem


Éic Dégenètais
Jérémy Prego (09/01/2019, 19h20)
Le 09/01/2019 à 14:05, roger.tarani a écrit :
> Avec traceroute :
> MACHINE 2
> 1 freeplayer.freebox.fr (FREEPLAYER) 39.753 ms 39.531 ms 39.427 ms
> 2 freeplayer.freebox.fr (FREEPLAYER) 3139.230 ms !H 3139.549 ms !H 3139.457 ms !H ce traceroute n'est pas bon.
> Problème résolu.


tant mieux si c'est résolu, mais le traceroute n'est pas convainquant
> PS : une question de sécurité qui devrait intéresser les gens, je crois :
> Est-il normal que l'adresse IP d'une machine du LAN soit visible depuis un site internet auquel elle se connecte par un navigateur ??
> On la lit en clair, par exemple avec [..] qui fournit d'abord (et c'est normal) l'adresse IP publique du réseau (de la Box).


> l'adresse privé de la machine est visible parce que ton navigateur utilise la technologie webRTC.


> Est-ce un danger ?


Je ne sais pas vraiment.

> Si oui, y a-t-il une solution ? (tiens, là je sens que l'on va me parler de FW que je devrais configurer...)


désactivvé WebRTC ? mais c'est pas forcément une bonne idée si des
services l'utilisent

Jerem
[..]
roger.tarani (09/01/2019, 20h50)
----- Original Message -----
From: "Jérémy Prego" <jeremy>
To: debian-user-french
Sent: Wednesday, January 9, 2019 6:10:02 PM
Subject: Re: Réseau : accès VPN et LAN simultanés

Le 09/01/2019 à 14:05, roger.tarani a écrit :
> Avec traceroute :
> MACHINE 2
> 1 freeplayer.freebox.fr (FREEPLAYER) 39.753 ms 39.531 ms 39.427 ms
> 2 freeplayer.freebox.fr (FREEPLAYER) 3139.230 ms !H 3139.549 ms !H 3139.457 ms !H ce traceroute n'est pas bon.
> Problème résolu.


tant mieux si c'est résolu, mais le traceroute n'est pas convainquant

Réponse :
Le traceroute communiqué pour les deux machines est celui indiquéSANS la configuration salvatrice côté client openvpn ("on visualise le cas où il y a blocage entre les 2 machines via le LAN").

AVEC la bonne config, le traceroute montre juste un saut :
$ traceroute IP_machine2
traceroute to IP_machine2 (IP_machine2), 30 hops max, 60 byte packets
1 IP_machine2 (IP_machine2) 5.358 ms 5.654 ms 5.677 ms

Idem depuis l'autre machine.

> PS : une question de sécurité qui devrait intéresser les gens, je crois :
> Est-il normal que l'adresse IP d'une machine du LAN soit visible depuis un site internet auquel elle se connecte par un navigateur ??
> On la lit en clair, par exemple avec [..] qui fournit d'abord (et c'est normal) l'adresse IP publique du réseau (de la Box).


> l'adresse privé de la machine est visible parce que ton navigateur utilise la technologie webRTC.


> Est-ce un danger ?


Je ne sais pas vraiment.

Réponse :
Test : sans VPN, [..] voit l'adresse IP de la machine sur le LAN.
Cette situation me choque. Peux-tu/pouvez-vous essayer avec votre machine pour voir si votre IP LAN "fuit" ?

> Si oui, y a-t-il une solution ? (tiens, là je sens que l'on va me parler de FW que je devrais configurer...)


désactivvé WebRTC ? mais c'est pas forcément une bonne idée si des services l'utilisent

Réponse :
Je n'utilise pas webRTC, mais il est utilisé à mon insu.
Je viens d'installer l'extension FF Disable WebRTC et, ô joie, whatsmyip ne voit plus l'IP LAN :
Internal LAN IP: Local IP address is not supported in this browser

Notez que noscript n'empêchait pas l'IP LAN d'être lue.

Je suis en train de plancher sur Securing Debian Manual ( [..] ). Je veux tout passer au crible. Et je sens que je vais découvrir un tas de fissures de ce genre dans mon système.

Avant que j'ai fait le tour de la sécurité d'une machine Debian,
y a-t-il d'autres choses évidentes (comme WebRTC) à vérifier?
Déjà au niveau du navigateur qui expose beaucoup la machine au monde extérieur

Merci

Jerem
[..]
Pascal Hambourg (09/01/2019, 20h50)
Le 09/01/2019 à 08:35, roger.tarani 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 ?

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

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

> 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).
[..]
Pascal Hambourg (09/01/2019, 21h00)
Le 09/01/2019 à 18:10, Jérémy Prego a écrit :
> Le 09/01/2019 à 14:05, roger.tarani a écrit :
>> Avec traceroute :
>> MACHINE 2
>> 1 freeplayer.freebox.fr (FREEPLAYER) 39.753 ms 39.531 ms 39.427 ms
>> 2 freeplayer.freebox.fr (FREEPLAYER) 3139.230 ms !H 3139.549 ms !H 3139.457 ms !H

> ce traceroute n'est pas bon.


Normal et prévisible. Cette "solution" est sous-optimale. La route
normale devrait être directe, sans next hop, mais l'option que tu as
suggérée impose le routeur du réseau comme next hop, ce qu'on voit dans
le traceroute.
roger.tarani (09/01/2019, 22h30)
----- Original Message -----
From: "Pascal Hambourg" <pascal>
To: debian-user-french
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 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 ([..]) .

> 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 VPNdu
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)
[..]
Pascal Hambourg (10/01/2019, 00h50)
Le 09/01/2019 à 21:21, roger.tarani a écrit :
> ----- Original Message -----
> From: "Pascal Hambourg" <pascal>


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

> 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.
roger.tarani (10/01/2019, 16h30)
----- Original Message -----
> From: "Pascal Hambourg" <pascal>
> To: debian-user-french
> Sent: Wednesday, January 9, 2019 11:48:51 PM
> Subject: Re: Réseau : accès VPN et LAN simultanés
> Le 09/01/2019 à 21:21, roger.tarani a écrit :
> 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.


Voilà c'est fait !
C'est possible avec Zimbra : (Préférences/Composition d'emails/Utiliser un préfixe des emails inclus ou retransmis)
Et à ça répond à un des points de mon récent mon message sur le bon usage et notamment les règles de formattage pour rendre les échanges plus lisibles via cette liste (sujet : Fonctionnement de la liste Debian).

> 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. Oui, c'est vrai. J'aurais pu être plus explicite.


> 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. Dans le doute et vu mon niveau modeste, j'ai préféré analyser, anonymiser et simplifier ces infos.


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

Je me demande bien pourquoi raspbian donne la possibilité à l'utilisateur pi (qui n'est pas root) d'exécuter du code dans sbin normalement réservé à root. Même sudo ne demande pas le mot de passe de l'utilisateur pi. C'est sans doute pour faciliter la vie de l'utilisateur qui débute en Linux avec un pi.
Ça n'est pas le cas avec Debian et c'est mieux ainsi.

> (...)
> Je ne comprends pas ce que tu veux dire.
> 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.

ça doit fonctionner car il y a aussi cette ligne :
dns-nameservers 192.168.0.1 8.8.8.8
Excuse-moi de ne l'avoir pas précisé.
C'est sans doute cette directive qui permet à la machine de trouver lagateway.

> > # 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 commeune
> adresse
> de broadcast quand elle est définie.

Tu as raison. J'avais trouvé cette config sur le net à un moment où cette machine était coupée du monde extérieur. ça a marché et j'ai laissé comme ça.
Je viens de relire des bases en réseau. Si 192.168.0.x est l'adresse de la machine sur un réseau, la machine a juste besoin de connaître l'IP de la gateway. Les IP de network et de broadcast peuvent être calculés :

netwkork : 192.168.0.x AND 255.555.255.0 = 192.168.0.0

broadcast : 192.168.0.x OR (NOT 255.555.255.0) = 192.168.0.x OR 0.0.0.255= 192.168.0.255

Merci pour cette révision.

> > ça ne change rien

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


> Résultat qui confirme que la route est ajoutée par le 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.
> Cette directive est juste une rustine qui sert à masquer une erreur
> de
> configuration.


Peut-on se passer de cette rustine ?

Finalement, j'ai simplifié la config des deux machines ainsi :

MACHINE 1
/etc/network/interfaces :
auto eth0
iface eth0 inet static
gateway 192.168.0.100
address 192.168.0.101
netmask 255.255.255.0

resolv.conf :
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.100

MACHINE 2 (pi)
/etc/network/interfaces :
auto eth0
iface eth0 inet static
gateway 192.168.0.100
address 192.168.0.102
netmask 255.255.255.0

resolv.conf :
# Generated by resolvconf
domain home
nameserver 192.168.0.100
nameserver 192.168.0.1

Et le fichier de conf openvpn client a le même ajout, qui permet désormais d'accéder via LAN ou via VPN :
route 192.168.0.0 255.255.255.0 net_gateway

Merci

Discussions similaires
Gérer les accès simultanés à un fichier

WD75 Accès simultanés à un fichier du réseau local

Acces simultanés à une base MDB par ADO

Accès simultanés à plusieurs bases


Fuseau horaire GMT +2. Il est actuellement 09h36. | Privacy Policy