Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
>
> 1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
> le serveur. Du coup pas de filtrage possible si c'est option est activée.
Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur
du tunnel entre deux clients ne transitent pas par l'interface tun/tap
ni la pile réseau de la machine qui fait tourner le serveur openvpn,
mais les paquets transportant le tunnel passent quand même par le
serveur openvpn.
> 2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
> je ne vois pas comment il sera possible de router les paquets d'un réseau
> comme il faut. Donc je ne vois pas comment ça peut marcher.
Il y a une bidouille possible à base de double NAT source+destination.
Pour chaque réseau utilisant l'adressage 192.168.1.0/24 en interne, on
définit un réseau externe unique, on configure le routage des réseaux
externes sur le serveur openvpn et on met en place des règles NETMAP sur
la passerelle de chaque réseau pour faire en sorte que :
- quand un paquet est émis vers le tunnel, son adresse source est mappée
en son adresse externe correspondant au réseau ;
- quant un paquet est reçu par le tunnel à destination d'une adresse
externe, son adresse est mappée en l'adresse interne correspondante.
Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.
>> J'ai découvert que je pouvais utiliser l'option client-to-client d'OpenVPN
>> pour permettre la communication directe entre deux clients OpenVPN.
>> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
>> configuration réseau du serveur OpenVPN" : les flux passaient directement
>> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
>> serveur OpenVPN définir des régles très précises comme celle de n'autoriser
>> que la communication depuis ou vers un ou deux clients OpenVPN.
Qu'est-ce que [1] ?