Re: Aide offline libreoffice 6
Le 07/01/2019 à 18:00, ajh-valmer a écrit : On Friday 04 January 2019 15:02:12 Nicolas FRANCOIS wrote: quand elle encadre deux caractères dans la même police, elle obtient 2 caractères encadrés, et pas un cadre pour les deux caractères...). Il y en a un autre : OpenOffice et maintenant LibreOffice ont toujours eu ce défaut récurrent, le Copier/Coller à l'intérieur d'un document LO ne fonctionne pas avec la roulette de la souris. Il faut mettre le texte en surbrillance, clic droit, "Copier", puis encore clic droit et "Coller". (alors qu'avec la roulette, texte en surbrillance puis clic roulette, quel gain de temps !) Si ça peut rassurer, sur ma Kubuntu 18.10 avec LibreOffice 6.1.3.2, ça fonctionne désormais ! Par contre le copier-coller avec le clic droit fonctionne une fois sur 2 dans calc. Bogue saisi. -- Migrec
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: Formattage EXT4 d'une clé de 2To
Le 07/01/2019 à 19:59, Pascal Hambourg a écrit : Le 07/01/2019 à 14:48, Patrick Menier a écrit : Le 07/01/2019 à 10:30, C. Mourad Jaber a écrit : sudo mount /dev/sdb1 /media/usbkey/ mount: /media/usbkey : mauvais type de système de fichiers, option erronée, superbloc erroné sur /dev/sdb1, page de code ou programme auxiliaire manquant, ou autre erreur. Fdisk me donne les informations suivantes : Commande (m pour l'aide) : p Disque /dev/sdb : 1,9 TiB, 209715200 octets, 409600 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : gpt Identifiant de disque : 896CE1F7-6EC3-2A4D-BC2B-809402441080 Périphérique Début Fin Secteurs Taille Type /dev/sdb1 2048 409566 4095997919 1,9T Racine Linux (x86-64) (...) Ca ne serait pas le type de partition gpt? Tu as essayé de le modifier ? Qu'est-ce qui te fait suggérer cela ? Linux gère très bien le format GPT, et mount et le pilote ext4 s'en fichent complètement. A noter que le format GPT n'est pas indispensable pour une taille de 2 To puisque la limite du format DOS/MBR est de 2 Tio (avec des secteurs logiques de 512 octets), légèrement supérieure. Oui je sais. Mais c'est pour l'avoir vécu... c'est tout. Patrick
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
