Client à client OpenVPN


17

Lorsque j'utilise un serveur OpenVPN TUN (couche 3) avec client-to-clientdésactivé, mes clients peuvent toujours se parler.

La configuration client à client doit empêcher cela selon la documentation:

Décommentez la directive client à client si vous souhaitez que les clients se connectant puissent se joindre via le VPN. Par défaut, les clients ne pourront accéder qu'au serveur.

Pourquoi les clients peuvent-ils continuer à communiquer entre eux lorsque cette option est désactivée?

Voici ma conf de serveur:

port 443
proto tcp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh4096.pem
topology subnet
server 10.10.201.0 255.255.255.128
ifconfig-pool-persist ipp.txt
crl-verify /etc/openvpn/keys/crl.pem
push "route [omitted]"
push "dhcp-option DNS [omitted]"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so login
cipher AES-256-CBC
tls-auth /etc/openvpn/keys/pfs.key 0
verb 4

Réponses:


54

Si client-to-clientest activé , le serveur VPN transfère les paquets client à client en interne sans les envoyer à la couche IP de l'hôte (c'est-à-dire au noyau). La pile de mise en réseau hôte ne voit pas du tout ces paquets.

           .-------------------.
           | IP Layer          |
           '-------------------'


           .-------------------.
           | TUN device (tun0) |
           '-------------------'


           .-------------------.
           | OpenVPN server    |
           '-------------------'
             ^           |
          1  |           |  2   
             |           v
 .----------------.  .----------------.
 | Client a       |  | Client b       |
 '----------------'  '----------------'

Si client-to-clientest désactivé , les paquets d'un client vers un autre client passent par la couche IP hôte (iptables, table de routage, etc.) de la machine hébergeant le serveur VPN: si le transfert IP est activé , l'hôte peut transférer le paquet (en utilisant son table de routage) à nouveau à l'interface TUN et le démon VPN transmettra le paquet au client correct à l'intérieur du tunnel.

           .-------------------.
           | IP Layer          |  (4) routing, firewall, NAT, etc.
           '-------------------'      (iptables, nftables, conntrack, tc, etc.)
              ^          |
          3   |          |  5
              |          v
           .-------------------.
           | TUN device (tun0) |
           '-------------------'
             ^           |
          2  |           |  6  
             |           v
           .-------------------.
           | OpenVPN server    |
           '-------------------'
             ^           |
          1  |           |  7  
             |           v
 .----------------.  .----------------.
 | Client a       |  | Client b       |
 '----------------'  '----------------'

Dans ce cas ( client-to-clientdésactivé), vous pouvez bloquer les paquets client à client à l'aide d'iptables:

 iptables -A FORWARD -i tun0 -o tun0 -j DROP

tun0est votre interface VPN.


Marqué cela comme la réponse; concis mais très instructif et fournit en fait la règle de pare-feu iptables dans la réponse.
lobi

1
J'ai une question sur le diagramme, le dessinez-vous char par char et espace par espace? ou utilisez-vous une application pour vous aider à obtenir cela simplement et rapidement?
Mohammed Noureldin

3
@MohammedNoureldin, j'ai fait le diagramme original avec asciio ( search.cpan.org/dist/App-Asciio ) qui est un éditeur WYSWYG pointer-cliquer pour les diagrammes asciiart.
ysdx

Merci, avez-vous réussi à l'exécuter sur Windows? cela semble être une application du moyen-âge, et je ne pouvais pas l'exécuter sur Windows, j'ai essayé de l'installer avec le paquet camelbox, mais j'obtiens toujours une erreur 404.
Mohammed Noureldin

2
@MohammedNoureldin, je n'utilise pas Windows. J'utilise Debian et il est directement installable à partir des paquets.
ysdx

5

Le paragraphe suivant de la page de manuel pour openvpnrépondre à cette question, bien qu'il ne soit pas nécessairement clair en première lecture:

Étant donné que le mode serveur OpenVPN gère plusieurs clients via une seule interface tun ou tap, il s'agit en fait d'un routeur. L' --client-to-client indicateur indique à OpenVPN de router en interne le trafic client à client plutôt que de pousser tout le trafic provenant du client vers l'interface TUN / TAP.

Lorsque cette option est utilisée, chaque client "verra" les autres clients actuellement connectés. Sinon, chaque client ne verra que le serveur. N'utilisez pas cette option si vous souhaitez filtrer le trafic du tunnel à l'aide de règles personnalisées par client.

L' client-to-clientoption court-circuite les tables de routage normales sur le serveur. La suppression n'empêche pas les clients d'utiliser les tables de routage du serveur. Si ces tables de routage - et la configuration du pare-feu du serveur - permettent aux clients de se voir, ils pourront le faire.


5

Vous devez faire plus que simplement commenter la directive comme il est dit ici :

Décommentez cette directive pour permettre à différents clients de se "voir". Par défaut, les clients ne verront que le serveur. Pour forcer les clients à ne voir que le serveur, vous devrez également pare-feu de manière appropriée l'interface TUN / TAP du serveur.

Par conséquent, vous pouvez configurer une stratégie d'adresse IP distincte pour chaque client. Voir la section Configuration des règles spécifiques au client et des politiques d'accès ici: https://openvpn.net/index.php/open-source/documentation/howto.html . et ici: https://www.sbarjatiya.com/notes_wiki/index.php/Configuring_separate_IP_and_firewall_rule_for_each_openvpn_client .


Ensuite, cela signifie ce que je pensais: la seule façon d'y parvenir est de mettre chaque client sur des sous-réseaux différents. Cela répond principalement à la question, et vous avez également fourni de la documentation sur la façon de procéder. Je vais noter cela comme la réponse. Merci.
lobi
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.