Re: Conseils sur le routage de client à client avec OpenVPN

Hello,

Première intervention sur la ML :)

Je remote avec un VPS OVH 600 sites distants via du OpenVPN et du Mikrotik sur site. Des sites en chine (pas HK) via des protocoles exotiques pour ne pas être filtrer (voir stunnel).

Les réseaux clients ne doivent pas avoir de même subnet.

C'est un peu compliqué au départ mais en étant rigoureux, je fais du 1 touch provisionning sur mes clients OpenVPN

Un exemple de configuration de ma "tete" vpn vers un client Mikro en Europe.

port 443

proto tcp

dev tun

ca /etc/openvpn/CL001-XXX/ca.crt

cert /etc/openvpn/CL001-XXX/server.crt

key /etc/openvpn/CL001-XXX/server.key

dh /etc/openvpn/CL001-XXX/dh2048.pem

# IP DU SERVEUR

server 172.30.1.0 255.255.255.0

client-config-dir /etc/openvpn/CL001-XXX/CSO

ccd-exclusive

# LE SERVEUR APPRENDS LES ROUTES - TAPER ROUTE

route 192.168.1.0 255.255.255.0

route 192.168.68.0 255.255.255.0

route 192.168.5.0 255.255.255.0

keepalive 10 120

cipher aes256

auth sha1

log-append /var/log/openvpn.log

status /var/log/openvpn-status.log

verb 4

mute 20

Un exemple de configuration de ma "tete" vpn vers un client Mikro

### CSO ##

#ifconfig-push 172.30.1.2 172.30.1.1

push "route 172.30.2.0 255.255.255.0"

push "route 172.30.99.0 255.255.255.0"

#push "route 192.168.5.0 255.255.255.0"

iroute 192.168.1.0 255.255.255.0

Une trace depuis un autre VPS

root@ > traceroute 192.168.1.251

traceroute to 192.168.1.251 (192.168.1.251), 30 hops max, 60 byte packets

1 VPN-OVH-MONITORING (172.30.2.1) 11.316 ms 22.360 ms 22.343 ms

2 MF-MONITORING (192.168.1.251) 33.140 ms 44.087 ms 44.108 ms

root@ ~ >

Bon courage,

Baptiste Chappe

Le mer. 23 janv. 2019 à 14:39, Olivier Bitsch <olivier.bitsch@gmail.com> a écrit :

Bonjour Olivier,

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.

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.

3. Pour les étapes B et C, et sous réserve que chaque réseau aient leur propre adressage, il faut utiliser la topologie subnet avec OpenVPN. Je peux te donner des exemples si tu en as besoin.

obitwo

Le mar. 22 janv. 2019 à 16:48, Olivier <oza.4h07@gmail.com> a écrit :
Bonjour,

J'ai plusieurs réseaux locaux distants dont le routeur est un serveur Debian sur lequel un client OpenVPN est installé.

Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un client OpenVPN, atteindre les machines connectées des différents réseaux locaux distants qui par ailleurs, sont à peu près tous configurés de la même façon (tous en 192.168.1.0/24, par exemple).

Pour fixer les choses, j'envisage d'opérer de la façon suivante:
+ sur mon PC:
A. je lance mon client OpenVPN
B. j'adapte ma configuration réseau en indiquant comment atteindre les machines d'un réseau distant
+ sur mon serveur OpenVPN
C. j'adapte ma configuration réseau
+ sur un routeur Debian distant particulier:
D. j'adapte la configuration réseau afin que les machines du réseau local puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la passerelle par défaut de ces machines).

Le serveur OpenVPN est une machine sur le cloud.
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.

Mes questions:
1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?

2. J'imaginais configurer l'étape D si dessus par un simple NAT avec iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
Qu'en pensez-vous ?

3. Que faire pour les étapes B et C ?
J'ai essayé sans trop de succès différentes commande "ip route add" sans succès pour l'instant.

Slts