----- Original Message -----
> From: "Pascal Hambourg" <pas...@plouf.fr.eu.org>
> To: debian-user-french@lists.debian.org
> 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.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.
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).
>
> > 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.
>
Oui, c'est vrai. J'aurais pu être plus explicite.
> >> 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.
>
Dans le doute et vu mon niveau modeste, j'ai préféré analyser, anonymiser et
simplifier ces infos.
> >> $ 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.
>
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.
> >> 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.
>
ç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 la gateway.
> > # 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.
>
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
> > 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.
>
>
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
