cerhu > linux.debian.user.french

Olivier (22/01/2019, 17h50)
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
Daniel Huhardeaux (22/01/2019, 18h40)
Le 22/01/2019 à 16:48, Olivier a écrit :
> Bonjour,


Bonjour

[..]
> 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.


Perso j'utilise 2 types d'organisations:

1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
tun, tous les serveurs des sites clients s'y connectent, je peux joindre
n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
d'adresses IP.

L'inconvénient pour toi est que justement tous les réseaux auxquels tu
veux te joindre ont le même plan d'adressage IP

2. les réseaux des clients: j'utilise un serveur OpenVPN mode tun en DC
auquel les serveurs clients se connectent soit via OpenVPN soit en ssh
avec autossh (reverse ssh).

Dans les 2 cas, à partir de mon portable je peux joindre n'importe quel
machine derrière les réseaux clients en utilisant les commandes ssh
(pour le cas 2 essentiellement ProxyCommand pour tous les clients,
Hostname en plus pour ceux en VPN)
Olivier (22/01/2019, 20h20)
Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux <no-spam> a
écrit :
[..]
Olivier (22/01/2019, 20h20)
Merci Daniel pour ta réponse.

J'aurai pu le préciser mais j'arrive à me connecter ponctuellement aux
équipements distants via des commandes SSH du type ssh -f -N foo@remote
-L1234:192.168.151:80 mais c'est assez fastidieux car je dois désignerles
ports distants, choisir des ports disponibles sur ma machine, ajouter un
éventuel rebond.

Je recherche maintenant à re-configurer le réseau afin d'avoir une
re-configuration ponctuelle plus générique

Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux <no-spam> a
écrit :
[..]
Daniel Huhardeaux (22/01/2019, 20h30)
Le 22/01/2019 à 19:16, Olivier a écrit :
> Merci Daniel pour ta réponse.
> J'aurai pu le préciser mais j'arrive à me connecter ponctuellement aux
> équipements distants via des commandes SSH du type ssh -f -N foo@remote
> -L1234:192.168.151:80 mais c'est assez fastidieux car je dois désigner
> les ports distants, choisir des ports disponibles sur ma machine,
> ajouter un éventuel rebond.
> Je recherche maintenant à re-configurer le réseau afin d'avoir une
> re-configuration ponctuelle plus générique


Justement, en centralisant les connexions sur un serveur, VPN et/ou ssh,
tu ne reconfigures plus le réseau: le fichier ~/.ssh/config contiendra
les commandes nécessaires afin de ne faire qu'un simple "ssh <host>"

Je trouve d'ailleurs dommage que mosh ne gère pas le fichier config de ssh.
[..]
Daniel Huhardeaux (22/01/2019, 20h40)
Le 22/01/2019 à 19:18, Olivier a écrit :
> <mailto:no-spam>> a écrit :
> Le 22/01/2019 à 16:48, Olivier a écrit :
> Bonjour
> 1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
> tun, tous les serveurs des sites clients s'y connectent, je peux
> joindre
> n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
> d'adresses IP.
> Comment le "routage" entre le réseau distant et les clients du VPN ?


Le serveur OpenVPN sait comment joindre chaque IP puisque chaque client
pousse sa route. Pour que cela fonctionne aussi avec les machines
Windows un masquerade fait son job. J'ai créé un script (cde up de la
config openvpn) qui fait le travail lorsque le VPN est monté, script
installé sur chaque client OpenVPN d'un site.
Olivier Bitsch (23/01/2019, 15h40)
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éseauaient 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> a écrit :
[..]
Olivier (23/01/2019, 16h10)
Le mer. 23 janv. 2019 à 14:39, Olivier Bitsch <olivier.bitsch> 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.


Je viens d'y passer la matinée mais sans succès malheureusement.

En mode client-to-client, les clients peuvent facilement se parler mais
c'est tout:
une commande "ip route add 192.168.1.0/24 via 10.8.1.40" est refusée même
si je peux atteindre (via openvpn) l'adresse 10.8.1.40.

J'ai l'impression qu'il faut jouer avec des paramètres OpenVPN comme route
(côte client OpenVPN) et/ou iroute (côte serveur OpenVPN) mais jen'ai pas
encore essayé.
[..]
Baptiste Chappe (23/01/2019, 16h30)
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, jefais 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> a
écrit :
[..]
Pascal Hambourg (23/01/2019, 16h50)
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] ?
Olivier (23/01/2019, 17h00)
Mea culpa: voici le lien manquant !

[1] [..]

Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg <pascal> a
écrit :
[..]
Olivier (23/01/2019, 17h10)
Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg <pascal> a
écrit :

> 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 NETMAPsur
> 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.
>Excellent !

Je ne connaissait pas l'option -j NETMAP qui a l'air adaptée car si sur
beaucoup de sites distants, je retrouve les mêmes adresses IP, j'ai aussi
une nomenclature avec un entier unique pour chaque site.
Il devrait pas être difficile d'associer cet entier à une plage d'adresse
propre à chaque site.

Merci infiniment pour l'avoir signalée
Pascal Hambourg (23/01/2019, 17h20)
Le 23/01/2019 à 15:58, Olivier a écrit :
> [1] [..]


Ce lien confirme ce que j'écrivais ci-dessous :
[..]
Olivier (24/01/2019, 12h00)
Bonjour,

La nuit porte conseil et en repensant à ce qui précède, je pense que mon
besoin premier est d'utiliser mon VPN comme un tunnel laissant passer des
flux entre deux clients du VPN
sans les interpréter lui-même.

Le VPN est le seul lien que j'ai avec des sites distants et je ne peux pas
risquer de perdre un lien en reconfigurant OpenVPN.
Or il me semble que les paramètres de routage d'OpenVPN ont une portée
générale avec des précautions que j'ai du mal à respecter (adresses
uniques, ...).

En conclusion:
1- je ne change pas ma configuration d'OpenVPN
2- s'il existe une technique pour utiliser ma configuration OpenVPN comme
un "tunnel entre mon PC et un LAN distant" et sans le re-configurer, ça
m'intéresse
3- s'il existe une autre technologie de VPN (IPSEC ? Wireguard ? ...) pour
faire ce que je recherche et utilisable en parallèle à OpenVPN, ça
m'intéresse aussi.

Pour le point 3, je n'ai pas besoin d'avoir un tunnel permanent entre mon
PC et le LAN distant: j'ai juste besoin de pouvoir établir ce tunnel le
temps d'une session de déboguage.
Je peux pouvoir initier ce tunnel quand je suis en déplacement et connecté
à réseau local dont je ne pourrai pas modifier la configuration du routeur:
je devrai donc passer par une machine tierce sur Internet qui aura les
ports ouverts nécessaires.

Pour compléter mon cahier des charges:
- toutes les machines concernées (mon PC, machine tierce, routeur sur le
LAN distant) sont sous Debian avec toutefois des versions variées (jessie,
stretch, ...).

Conseils, remarques et suggestions bienvenues !

Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg <pascal> a
écrit :
[..]
Daniel Huhardeaux (24/01/2019, 12h20)
Le 24/01/2019 à 10:54, Olivier a écrit :
[..]
> connecté à réseau local dont je ne pourrai pas modifier la configuration
> du routeur: je devrai donc passer par une machine tierce sur Internet
> qui aura les ports ouverts nécessaires.
> Pour compléter mon cahier des charges:
> - toutes les machines concernées (mon PC, machine tierce, routeur sur le
> LAN distant) sont sous Debian avec toutefois des versions variées
> (jessie, stretch, ...).
> Conseils, remarques et suggestions bienvenues !


Rien ne t'empêche de mettre une seconde configuration VPN en parallèle
chez tes clients (et chez toi) sur un autre port !

Pour ma part, je réitère: un serveur VPN central sur lequel vont se
connecter les clients et toi, du réseau bureau ou déplacement.

serveur VPN
/ | ...\
clt1 clt2 Cltx

Le lien est permanent pour les clients sauf pour toi (si tu le désire)

Pas de port ouvert sauf celui pour le VPN et ssh en secours. Cela veut
dire que tu pourras te connecter (ssh avec mot de passe) chez tes
clients à partir de n'importe quel matériel, pas seulement de ceux qui
te sont connus.
[..]

Discussions similaires
HS - Client openvpn sur iOS/android

OpenVPN côté client

openvpn client sur bewan 6104

[etch] client Openvpn-gui pour windows


Fuseau horaire GMT +2. Il est actuellement 20h24. | Privacy Policy