Re: Réseau : accès VPN et LAN simultanés
PS
J'ai fait plein d'essais de réglage réseau sur MACHINE 1.
J'arrive toujours à la faire communiquer avec MACHINE 2 via LAN ou via VPN et avec des machines de l'internet.
Mais il y a un truc qui m'échappe...
J'aiconservé le réglage du client openvpn ("route 192.168.40.0 255.255.255.0 net_gateway")
Je configure eth0 dans /etc/network/interfaces :
auto eth0
iface eth0 inet static
gateway 192.168.0.100 # IP gateway 7links
address 192.168.0.153
netmask 255.255.255.0
# dns-nameservers 192.168.0.100 80.10.246.2 80.10.246.129
Notez que la ligne dns-nameservers est commentée
Pour mettre en oeuvre la config réseau sans redémarrer la machine, je fais :
1/ pour mettre à jour resolv.conf après modif éventuelle de /etc/network/interfaces :
$ sudo systemctl restart resolvconf.service
ou bien
$ sudo resolvconf -u
J'obtiens 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
Si j'avais modifié exprès resolv.conf auparavant, je constate qu'il est mis à jour.
Par ailleurs, pour redémarrer les services réseau je fais :
2/ $ sudo systemctl restart networking.service
? la machine a un accès réseau opérationnel (LAN/VPN/internet), mais je ne comprends pas comment resolv.conf est mis à jour avec les infos de dns-namerservers qui sont commentées ?! (idem si la ligne est supprimée)
De la même façon, je ne comprends pas pourquoi la commande
$ sudo systemctl stop networking.service
ne coupe pas l'accès au LAN.
J'ai fait l'essai avec le client vpn connecté puis déconnecté (je me suis dit que la machine accèdait peut-être à internet via le lien de l abox qui sert de serveur vpn).
Par le passé, j'utilisais ifdown et ifup, mais là ça ne marche plus
$ sudo ifdown eth0
ifdown: interface eth0 not configured
C'est logique puisque /run/network/ifstate ne contient que
lo=lo
Il doit y avoir dans cette machine Debian un ordre des choses du réseau qui m'échappe !
Est-ce normal que networking.service soit 'active exited' ?
$ sudo systemctl list-units | grep networking
networking.service loaded active exited LSB: Raise network interfaces.
Là je sèche.
Voyez-vous la cause du problème ?
Merci
PS
Je viens de trouver cette page qui parle du même problème avec resolvconf :
https://serverfault.com/questions/912619/not-possible-to-update-resolv-conf
----- Original Message -----
> From: "Pascal Hambourg" <pascal@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.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: