J'ai plusieurs r=C3=A9seaux locaux distants dont le routeur est un serveur
Debian sur lequel un client OpenVPN est install=C3=A9.
Je souhaite pouvoir depuis mon propre PC sur lequel est aussi install=C3=A9=
un
client OpenVPN, atteindre les machines connect=C3=A9es des diff=C3=A9rents =
r=C3=A9seaux
locaux distants qui par ailleurs, sont =C3=A0 peu pr=C3=A8s tous configur=
=C3=A9s de la
m=C3=AAme fa=C3=A7on (tous en 192.168.1.0/24, par exemple).
Pour fixer les choses, j'envisage d'op=C3=A9rer de la fa=C3=A7on suivante:
+ sur mon PC:
A. je lance mon client OpenVPN
B. j'adapte ma configuration r=C3=A9seau en indiquant comment atteindre les
machines d'un r=C3=A9seau distant
+ sur mon serveur OpenVPN
C. j'adapte ma configuration r=C3=A9seau
+ sur un routeur Debian distant particulier:
D. j'adapte la configuration r=C3=A9seau afin que les machines du r=C3=A9se=
au local
puissent communiquer avec mon PC (par chance, le routeur Debian est d=C3=A9=
j=C3=A0 la
passerelle par d=C3=A9faut de ces machines).
Le serveur OpenVPN est une machine sur le cloud.
J'ai d=C3=A9couvert 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=C3=A9rait =C3=A0 "l'insu de la
configuration r=C3=A9seau du serveur OpenVPN" : les flux passaient directem=
ent
d'un client OpenVPN =C3=A0 un autre sans que je puisse, avec le firewall du
serveur OpenVPN d=C3=A9finir des r=C3=A9gles tr=C3=A8s pr=C3=A9cises 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'=C3=A9tape 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 =C3=A9tapes B et C ?
J'ai essay=C3=A9 sans trop de succ=C3=A8s diff=C3=A9rentes commande "ip rou=
te add" sans
succ=C3=A8s pour l'instant.
<div dir=3D"ltr"><div dir=3D"ltr"><div>Bonjour,</div><div><br></div><div>J&=
#39;ai plusieurs r=C3=A9seaux locaux distants dont le routeur est un serveu=
r Debian sur lequel un client OpenVPN=C2=A0 est install=C3=A9.</div><div><b=
r></div><div>Je souhaite pouvoir depuis mon propre PC sur lequel est aussi =
install=C3=A9 un client OpenVPN, atteindre les machines connect=C3=A9es des=
diff=C3=A9rents r=C3=A9seaux locaux distants qui par ailleurs, sont =C3=A0=
peu pr=C3=A8s tous configur=C3=A9s de la m=C3=AAme fa=C3=A7on (tous en <a =
href=3D"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'envisage d'op=C3=A9rer =
de la fa=C3=A7on suivante:</div><div>+=C2=A0 sur mon PC:</div><div>A. je la=
nce mon client OpenVPN <br></div><div>B. j'adapte ma configuration r=C3=
=A9seau en indiquant comment atteindre les machines d'un r=C3=A9seau di=
stant</div><div>+ sur mon serveur OpenVPN</div><div>C. j'adapte ma conf=
iguration r=C3=A9seau</div><div><a class=3D"gmail_plusreply" id=3D"gmail-pl=
usReplyChip-0">+</a>=C2=A0sur un routeur Debian distant particulier:</div><=
div>D. j'adapte la configuration r=C3=A9seau afin que les machines du r=
=C3=A9seau local puissent communiquer avec mon PC (par chance, le routeur D=
ebian est d=C3=A9j=C3=A0 la passerelle par d=C3=A9faut de ces machines).</d=
iv><div><br></div><div>Le serveur OpenVPN est une machine sur le cloud.</di=
v><div>J'ai d=C3=A9couvert que je pouvais utiliser l'option client-=
to-client d'OpenVPN pour permettre la communication directe entre deux =
clients OpenVPN.</div><div>J'ai lu en [1], que cette communication s=
9;op=C3=A9rait =C3=A0 "l'insu de la configuration r=C3=A9seau du s=
erveur OpenVPN" : les flux passaient directement d'un client OpenV=
PN =C3=A0 un autre sans que je puisse, avec le firewall du serveur OpenVPN =
d=C3=A9finir des r=C3=A9gles tr=C3=A8s pr=C3=A9cises comme celle de n'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'=
imaginais configurer l'=C3=A9tape D si dessus par un simple NAT avec ip=
tables du type (10.8.1.70 est l'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'en pensez-vous ?</div><div><br></div><div>3. Que faire pou=
r les =C3=A9tapes B et C ?</div><div>J'ai essay=C3=A9 sans trop de succ=
=C3=A8s diff=C3=A9rentes commande "ip route add" sans succ=C3=A8s=
pour l'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>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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 <http://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.
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
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
<http://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.
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)
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 <http://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.
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 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 <mailto: a écrit : 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
<http://192.168.1.0/24>
<http://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.
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
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.
Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux <no-spam@tootai.net
<mailto:no-spam@tootai.net>> a écrit :
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
<http://192.168.1.0/24>
> <http://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.
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)
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 <mailto: a écrit : 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
<http://192.168.1.0/24>
<http://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.
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 22/01/2019 à 19:18, Olivier a écrit :
Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux <mailto: a écrit : 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
Le 22/01/2019 à 19:18, Olivier a écrit :
Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux <no-spam@tootai.net
<mailto:no-spam@tootai.net>> a écrit :
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.
Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux <mailto: a écrit : 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 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] ?
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.
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
--000000000000e55aac0580217028 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg > a é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 <div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 23 janv. 2019 à 15 :46, Pascal Hambourg <<a href="mailto:"> louf.fr.eu.org</a>> a écrit :<br></div><blockquote class="gm ail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204, 204,204);padding-left:1ex"><br> Il y a une bidouille possible à base de double NAT source+destination. <br> Pour chaque réseau utilisant l'adressage <a href="http://192.168 .1.0/24" rel="noreferrer" target="_blank">192.168.1.0/24</a> en interne , on <br> 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'une adresse <br> externe, son adresse est mappée en l'adresse interne correspondant e.<br> <br> Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.<br> <br><div><br></div><div>Excellent !</div><div>Je ne connaissai t pas l'option -j NETMAP qui a l'air adaptée car si sur beauco up de sites distants, je retrouve les mêmes adresses IP, j'ai auss i une nomenclature avec un entier unique pour chaque site.</div><div>Il dev rait pas être difficile d'associer cet entier à une plage d&# 39;adresse propre à chaque site.<br></div><div><br></div><div>Merci in finiment pour l'avoir signalée<br></div></div></div> --000000000000e55aac0580217028--
Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg <pascal@plouf.fr.eu.org > a
é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.
<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 23 janv. 2019 à 15 :46, Pascal Hambourg <<a href="mailto:pascal@plouf.fr.eu.org">pascal@p louf.fr.eu.org</a>> a écrit :<br></div><blockquote class="gm ail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204, 204,204);padding-left:1ex"><br>
Il y a une bidouille possible à base de double NAT source+destination. <br>
Pour chaque réseau utilisant l'adressage <a href="http://192.168 .1.0/24" rel="noreferrer" target="_blank">192.168.1.0/24</a> en interne , on <br>
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'une adresse <br>
externe, son adresse est mappée en l'adresse interne correspondant e.<br>
<br>
Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.<br>
<br></blockquote><div><br></div><div>Excellent !</div><div>Je ne connaissai t pas l'option -j NETMAP qui a l'air adaptée car si sur beauco up de sites distants, je retrouve les mêmes adresses IP, j'ai auss i une nomenclature avec un entier unique pour chaque site.</div><div>Il dev rait pas être difficile d'associer cet entier à une plage d&# 39;adresse propre à chaque site.<br></div><div><br></div><div>Merci in finiment pour l'avoir signalée<br></div></div></div>
--000000000000e55aac0580217028 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg > a é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 <div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 23 janv. 2019 à 15 :46, Pascal Hambourg <<a href="mailto:"> louf.fr.eu.org</a>> a écrit :<br></div><blockquote class="gm ail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204, 204,204);padding-left:1ex"><br> Il y a une bidouille possible à base de double NAT source+destination. <br> Pour chaque réseau utilisant l'adressage <a href="http://192.168 .1.0/24" rel="noreferrer" target="_blank">192.168.1.0/24</a> en interne , on <br> 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'une adresse <br> externe, son adresse est mappée en l'adresse interne correspondant e.<br> <br> Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.<br> <br><div><br></div><div>Excellent !</div><div>Je ne connaissai t pas l'option -j NETMAP qui a l'air adaptée car si sur beauco up de sites distants, je retrouve les mêmes adresses IP, j'ai auss i une nomenclature avec un entier unique pour chaque site.</div><div>Il dev rait pas être difficile d'associer cet entier à une plage d&# 39;adresse propre à chaque site.<br></div><div><br></div><div>Merci in finiment pour l'avoir signalée<br></div></div></div> --000000000000e55aac0580217028--
Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg a é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.
Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg <pascal@plouf.fr.eu.org> a
é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.
Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg a é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 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 <mailto: a écrit : Le 23/01/2019 à 15:58, Olivier 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.
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 <pascal@plouf.fr.eu.org
<mailto:pascal@plouf.fr.eu.org>> 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
<pascal@plouf.fr.eu.org <mailto:pascal@plouf.fr.eu.org>> a
> é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.
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 <mailto: a écrit : Le 23/01/2019 à 15:58, Olivier 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 24/01/2019 à 11:32, Olivier a écrit :
Le jeu. 24 janv. 2019 à 11:18, Daniel Huhardeaux <mailto: a écrit : 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.
Ce lien confirme ce que j'écrivais ci-dessous : > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg <mailto:
<mailto: <mailto: a
> é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.
Le 24/01/2019 à 11:32, Olivier a écrit :
Le jeu. 24 janv. 2019 à 11:18, Daniel Huhardeaux <no-spam@tootai.net
<mailto:no-spam@tootai.net>> a écrit :
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
<pascal@plouf.fr.eu.org <mailto:pascal@plouf.fr.eu.org>
> <mailto:pascal@plouf.fr.eu.org <mailto:pascal@plouf.fr.eu.org>>>
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
> <pascal@plouf.fr.eu.org <mailto:pascal@plouf.fr.eu.org>
<mailto:pascal@plouf.fr.eu.org <mailto:pascal@plouf.fr.eu.org>>> a
> > é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.
>
Le jeu. 24 janv. 2019 à 11:18, Daniel Huhardeaux <mailto: a écrit : 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.
Ce lien confirme ce que j'écrivais ci-dessous : > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg <mailto:
<mailto: <mailto: a
> é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
