Re: Réseau : accès VPN et LAN simultanés
- Original Message - > From: "Pascal Hambourg" > To: debian-user-french@lists.debian.org > Sent: Friday, January 11, 2019 9:16:14 PM > Subject: Re: Réseau : accès VPN et LAN simultanés > > Le 10/01/2019 à 15:28, roger.tar...@free.fr a écrit : > > > >> From: "Pascal Hambourg" > >> > >> 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) > > Il y a qund même un défaut gênant : cela retaille les lignes citées > avec > des retours à la ligne intempestifs. Les lignes de texte original > sont > coupées à 72 caractères pour permettre d'ajouter plusieurs niveaux de > citation sans dépasser 80 caractères. > Là je n'ai pas trouvé d'autres options de composition d'emailsTu utiles quoi comme client de messagerie ? > > 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. > > Certains commandes de /sbin ou /usr/sbin comme ip ou ifconfig peuvent > être exécutées par un utilisateur standard pour réaliser des > opérations > de consultation en lecture seule qui ne nécessitent pas de > privilèges. > Mais ce n'est pas d'iptables. > > Ok. > >>>> 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. > > Peux-tu expliquer ta réponse ? > > Le résultat de la commande 'ip route' est obtenu alors que la configuration réseau permet aux deux machines de communiquer ensemble via le LAN OU/ET le VPN. Peux-tu montrer un exemple de route qui est bonne ? > >>> 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 > > Rien à voir. C'est pour la configuration DNS. > > > C'est sans doute cette directive qui permet à la machine de trouver > > la gateway. > > Non, pas du tout. Les serveurs DNS servent à la résolution de noms et > n'ont aucun rôle dans le routage IP. > > Ok. > >>> 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 ? > > Normalement oui puisque machine 1 n'avait pas cette route erronée. > Tu pourrais montrer la configuration openvpn des deux machines ? > > Voici le fichier de configuration openvpn, identique pour MACHINE 1 et MACHINE 2 : client remote SERVER_VPN_IP 6504 proto udp nobind dev-type tun # rustine pour contourner un pb de mauvaise configuration réseau # et permettre une comm simultanée via LAN ET via VPN # auparavant, c'était LAN ou bien VPN route 192.168.0.0 255.255.255.0 net_gateway pull dev tun0 redirect-gateway # auth-user-pass # config initialement fournie par Serveur VPN Freebox auth-user-pass login.txt auth-retry interact fragment 1452 mssfix 1452 explicit-exit-notify 3 cipher AES-256-CBC remote-cert-tls server verify-x509-name "C=FR, O=Freebox SA, CN=Freebox OpenVPN server NOMBRE_HEXA_32_CARAC>" A l'original produit par leserveur openvpn Freebox, j'ai juste : - ajouté une directive pour lire un fichier login.txt - ajouté ta rustine Voilà.
Re: Réseau : accès VPN et LAN simultanés
Le 10/01/2019 à 15:28, roger.tar...@free.fr a écrit : From: "Pascal Hambourg" 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) Il y a qund même un défaut gênant : cela retaille les lignes citées avec des retours à la ligne intempestifs. Les lignes de texte original sont coupées à 72 caractères pour permettre d'ajouter plusieurs niveaux de citation sans dépasser 80 caractères. 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. Certains commandes de /sbin ou /usr/sbin comme ip ou ifconfig peuvent être exécutées par un utilisateur standard pour réaliser des opérations de consultation en lecture seule qui ne nécessitent pas de privilèges. Mais ce n'est pas d'iptables. 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. Peux-tu expliquer ta réponse ? 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 Rien à voir. C'est pour la configuration DNS. C'est sans doute cette directive qui permet à la machine de trouver la gateway. Non, pas du tout. Les serveurs DNS servent à la résolution de noms et n'ont aucun rôle dans le routage IP. 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 ? Normalement oui puisque machine 1 n'avait pas cette route erronée. Tu pourrais montrer la configuration openvpn des deux machines ?
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 exitedLSB: 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"
> 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"
>
> 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
Re: Réseau : accès VPN et LAN simultanés
- Original Message - > From: "Pascal Hambourg" > 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" > > 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 a
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" 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.
Re: Réseau : accès VPN et LAN simultanés
- Original Message - From: "Pascal Hambourg" To: debian-user-french@lists.debian.org 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.tar...@free.fr 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 (https://monbidule.freeboxos.fr:40870) . > 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 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. 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) > 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
Re: Réseau : accès VPN et LAN simultanés
Le 09/01/2019 à 18:10, Jérémy Prego a écrit : Le 09/01/2019 à 14:05, roger.tar...@free.fr 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.
Re: Réseau : accès VPN et LAN simultanés
Le 09/01/2019 à 08:35, roger.tar...@free.fr 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). 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
Re: Réseau : accès VPN et LAN simultanés
- Original Message -
From: "Jérémy Prego"
To: debian-user-french@lists.debian.org
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.tar...@free.fr 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
> http://www.whatsmyip.org/more-info-about-you/ 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, http://www.whatsmyip.org/more-info-about-you/ 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 (
https://www.debian.org/doc/manuals/securing-debian-howto/ ). 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
>
> - Original Message -
> From: "Eric Degenetais"
> To: "roger tarani"
> Cc: "ML 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, a écrit :
>> 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 pb
>> réseau est l'occasion de se mettre à jour.
>>
> pourquoi ne pas commencer par un simple traceroute tout con ?
>> Bonne journée
>>
>> - Original Message -
>> From: "Jérémy Prego"
>> To: debian-user-french@lists.debian.org
>> 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 :
>>>> Le 09/01/2019 à 02:23, roger.tar...@free.fr 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).
>>>
>> ça tombe bien, c'est le but de net_gateway par oposition a l'option
>> vpn_gateway.
>>
>> Jerem
>>
> Éic Dégenètais
>
Re: Réseau : accès VPN et LAN simultanés
Le 09/01/2019 à 14:05, roger.tar...@free.fr 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 > http://www.whatsmyip.org/more-info-about-you/ 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 > > - Original Message - > From: "Eric Degenetais" > To: "roger tarani" > Cc: "ML 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, a écrit : >> 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 pb >> réseau est l'occasion de se mettre à jour. >> > pourquoi ne pas commencer par un simple traceroute tout con ? >> Bonne journée >> >> - Original Message - >> From: "Jérémy Prego" >> To: debian-user-french@lists.debian.org >> 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 : >>>> Le 09/01/2019 à 02:23, roger.tar...@free.fr 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). >>> >> ça tombe bien, c'est le but de net_gateway par oposition a l'option >> vpn_gateway. >> >> Jerem >> > Éic Dégenètais >
Re: Réseau : accès VPN et LAN simultanés
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 http://www.whatsmyip.org/more-info-about-you/ 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" To: "roger tarani" Cc: "ML 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, a écrit : > > 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 pb > réseau est l'occasion de se mettre à jour. > pourquoi ne pas commencer par un simple traceroute tout con ? > Bonne journée > > - Original Message - > From: "Jérémy Prego" > To: debian-user-french@lists.debian.org > 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 : > >> Le 09/01/2019 à 02:23, roger.tar...@free.fr 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). > > > > ça tombe bien, c'est le but de net_gateway par oposition a l'option > vpn_gateway. > > Jerem > Éic Dégenètais
Re: Réseau : accès VPN et LAN simultanés
bonjour, Le mer. 9 janv. 2019 à 09:22, a écrit : > > 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 pb > réseau est l'occasion de se mettre à jour. > pourquoi ne pas commencer par un simple traceroute tout con ? > Bonne journée > > - Original Message - > From: "Jérémy Prego" > To: debian-user-french@lists.debian.org > 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 : > >> Le 09/01/2019 à 02:23, roger.tar...@free.fr 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). > > > > ça tombe bien, c'est le but de net_gateway par oposition a l'option > vpn_gateway. > > Jerem > Éic Dégenètais
Re: Réseau : accès VPN et LAN simultanés
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 pb réseau est l'occasion de se mettre à jour. Bonne journée - Original Message - From: "Jérémy Prego" To: debian-user-french@lists.debian.org 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 : >> Le 09/01/2019 à 02:23, roger.tar...@free.fr 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). > ça tombe bien, c'est le but de net_gateway par oposition a l'option vpn_gateway. Jerem
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 : >> Le 09/01/2019 à 02:23, roger.tar...@free.fr 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). > ça tombe bien, c'est le but de net_gateway par oposition a l'option vpn_gateway. Jerem
Re: Réseau : accès VPN et LAN simultanés
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" To: debian-user-french@lists.debian.org 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.tar...@free.fr 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).
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.tar...@free.fr 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).
Re: Réseau : accès VPN et LAN simultanés
Le 09/01/2019 à 02:23, roger.tar...@free.fr 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. :) > jerem
