Re: Réseau : accès VPN et LAN simultanés

[roger.tarani@free.fr]

----- Original Message -----
> From: "Pascal Hambourg" <pascal@plouf.fr.eu.org>
> 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.tarani@free.fr a écrit :
> > 
> >> 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.
> > 
> > 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à.