Conseils sur le routage de client à client avec OpenVPN

Le
Olivier
--0000000000002782ed05800de855
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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ése=
au 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'Ope=
nVPN
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 directem=
ent
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 rou=
te add" sans
succès pour l'instant.

Slts

--0000000000002782ed05800de855
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div dir="ltr"><div>Bonjour,</div><div><br></div><div>J&=
#39;ai plusieurs réseaux locaux distants dont le routeur est un serveu=
r Debian sur lequel un client OpenVPN  est installé.</div><div><b=
r></div><div>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 <a =
href="http://192.168.1.0/24">192.168.1.0/24</a>, par exemple).<br></div><=
div><br></div><div>Pour fixer les choses, j&#39;envisage d&#39;opérer =
de la façon suivante:</div><div>+  sur mon PC:</div><div>A. je la=
nce mon client OpenVPN <br></div><div>B. j&#39;adapte ma configuration r=
seau en indiquant comment atteindre les machines d&#39;un réseau di=
stant</div><div>+ sur mon serveur OpenVPN</div><div>C. j&#39;adapte ma conf=
iguration réseau</div><div><a class="gmail_plusreply" id="gmail-pl=
usReplyChip-0">+</a> sur un routeur Debian distant particulier:</div><=
div>D. j&#39;adapte la configuration réseau afin que les machines du r=
éseau local puissent communiquer avec mon PC (par chance, le routeur D=
ebian est déjà la passerelle par défaut de ces machines).</d=
iv><div><br></div><div>Le serveur OpenVPN est une machine sur le cloud.</di=
v><div>J&#39;ai découvert que je pouvais utiliser l&#39;option client-=
to-client d&#39;OpenVPN pour permettre la communication directe entre deux =
clients OpenVPN.</div><div>J&#39;ai lu en [1], que cette communication s&#3=
9;opérait à &quot;l&#39;insu de la configuration réseau du s=
erveur OpenVPN&quot; : les flux passaient directement d&#39;un client OpenV=
PN à 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&#39;a=
utoriser que la communication depuis ou vers un ou deux clients OpenVPN.<br=
></div><div><br></div><div>Mes questions:</div><div>1. Ai-je bien compris [=
1] et [1] est-il bien toujours valable ?</div><div><br></div><div>2. J&#39;=
imaginais configurer l&#39;étape D si dessus par un simple NAT avec ip=
tables du type (10.8.1.70 est l&#39;IP dans le VPN du routeur Debian):</div=
><div>iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70<=
/div><div>Qu&#39;en pensez-vous ?</div><div><br></div><div>3. Que faire pou=
r les étapes B et C ?</div><div>J&#39;ai essayé sans trop de succ=
ès différentes commande &quot;ip route add&quot; sans succès=
pour l&#39;instant.</div><div><br></div><div>Slts<br></div><div><br></div>=
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>=
</div></div>

--0000000000002782ed05800de855--
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Daniel Huhardeaux
Le #26506511
Le 22/01/2019 à 16:48, Olivier a écrit :
Bonjour,

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

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)
--
Daniel
Daniel Huhardeaux
Le #26506536
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
-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.
Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux
Le 22/01/2019 à 16:48, Olivier a écrit :
Bonjour,

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

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.

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)
--
Daniel
Daniel Huhardeaux
Le #26506539
Le 22/01/2019 à 19:18, Olivier a écrit :
Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux
Le 22/01/2019 à 16:48, Olivier a écrit :
Bonjour,

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.
--
Daniel
Pascal Hambourg
Le #26506690
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
Le #26506693
--000000000000e55aac0580217028
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg écrit :
Il y a une bidouille possible à base de double NAT source+destinatio n.
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 ma ppée
en son adresse externe correspondant au réseau ;
- quant un paquet est reçu par le tunnel à destination d'une ad resse
externe, son adresse est mappée en l'adresse interne correspondante.
Evidemment, ça ne marche qu'avec les protocoles supportés par l e NAT.


Excellent !
Je ne connaissait pas l'option -j NETMAP qui a l'air adaptée car si su r
beaucoup de sites distants, je retrouve les mêmes adresses IP, j'ai au ssi
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
--000000000000e55aac0580217028
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il y a une bidouille possible à base de double NAT source+destination. <br>
Pour chaque réseau utilisant l&#39;adressage définit un réseau externe unique, on configure le routage des r éseaux <br>
externes sur le serveur openvpn et on met en place des règles NETMAP s ur <br>
la passerelle de chaque réseau pour faire en sorte que :<br>
- quand un paquet est émis vers le tunnel, son adresse source est mapp ée <br>
en son adresse externe correspondant au réseau ;<br>
- quant un paquet est reçu par le tunnel à destination d&#39;une adresse <br>
externe, son adresse est mappée en l&#39;adresse interne correspondant e.<br>
<br>
Evidemment, ça ne marche qu&#39;avec les protocoles supportés par le NAT.<br>
--000000000000e55aac0580217028--
Pascal Hambourg
Le #26506697
Le 23/01/2019 à 15:58, Olivier a écrit :
[1] https://serverfault.com/questions/736274/openvpn-client-to-client

Ce lien confirme ce que j'écrivais ci-dessous :
Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg écrit :
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.
Daniel Huhardeaux
Le #26506829
Le 24/01/2019 à 10:54, Olivier a écrit :
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 !

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.

Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg
Le 23/01/2019 à 15:58, Olivier a écrit :
[1] https://serverfault.com/questions/736274/openvpn-client-to-client

Ce lien confirme ce que j'écrivais ci-dessous :
Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg

écrit :
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.



Daniel Huhardeaux
Le #26506863
Le 24/01/2019 à 11:32, Olivier a écrit :
Le jeu. 24 janv. 2019 à 11:18, Daniel Huhardeaux

Rien ne t'empêche de mettre une seconde configuration VPN en parallèle
chez tes clients (et chez toi) sur un autre port !
Je suis d'accord.
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)
Je suis d'accord sauf peut-être sur la persistance des liens car ne
l'oublions pas, j'ai des plages d'adresses identiques sur des sites
différents et ça va rester.
Quelle techno de VPN te sembles la plus adaptée pour ça ?

tun
On garde OpenVPN (pas de logiciels supplémentaire à installer): juste
une re-configuration au cas par cas pour la deuxième instance d'OpenVPN ?
Ça me semble une très bonne idée mais je préfère demander.

Oui
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.

Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg


a écrit :
     Le 23/01/2019 à 15:58, Olivier a écrit :
      >
      > [1]

https://serverfault.com/questions/736274/openvpn-client-to-client
     Ce lien confirme ce que j'écrivais ci-dessous :
      > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg
     

      > écrit :
      >
      >> 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.

Publicité
Poster une réponse
Anonyme