J'ai donc testé la solution 1 qui me parait être la plus simple.
Pour les tests j'ai remplacé l'IPBX par un Debian et j'ai donc ces adresses :
- Server {tun0=10.64.0.1}
- CLIENT-1 {tun0=10.64.0.100; eth0=192.168.138.16}
- IPBX {eth0=192.168.138.12}
L'IP 192.168.138.12 (IPBX) est translatée en 10.64.0.200.
J'ai utilisé l'option client-nat d'OpenVPN pour pousser sur CLIENT-X la conf de NAT ci-dessous:
j'imagine que les machines CLIENT-X sont des machines à toi, que tu met chez le client pour permettre la telemaintenance des equipements.
Exactement.
donc sur l'equipement CLIENT-1, tu met un NAT qui convertit
10.1.0.y en 192.168.0.y (en entrée des flux qui arrivent sur le VPN : DNAT)
et 192.168.0.y en 10.1.0.y (en sortie des flux qui sortent sur le VPN : SNAT)
J'avais réussi avec quelques lignes d'iptables sur CLIENT-X à convertir 10.1.0.y en 192.168.0.y, les paquets allaient jusqu'à l'IPBX mais ne revenaient pas.
Je ne sais pas s'il est possible de faire une translation sans toucher à la configuration de l'IPBX ?
Donc le but est de se connecter à Server pour avoir accès à tous nos équipements chez le client grâce à l'équipement Linux qui sert de point d'entrée.
On peut imaginer Server dans un VPS chez un hébergeur type DigitalOcean.
Ici je n'ai représenté qu'un seul client pour ne pas compliquer le schéma mais c'est grossièrement la même chose chez les autres clients.
Je veux avoir une connexion sur les équipements de nos clients. Donc il y a du SSH, du telnet, des protocoles proprios Avaya pour les configurations et du debug, du tftp, du SNMP etc.. Donc c'est pour ça que la redirection par port est trop complexe dans ce cas.
Effectivement ce serrait une idée si il n'y avait qu'un seul équipement. Parfois il peut y avoir plusieurs équipement de nature différente derrière un équipement CLIENTX. Ou peut-etre n'ais-je pas tout compris de ce que tu voulais dire par pont réseau..
Pour la partie VPN effectivement les clients ne sont pas isolés! Par contre j'ai pu lire qu'il était possible de translater une plage d'adresse entière. Par exemple 192.168.100.0/24 -> 10.64.100.0/24. J'avais réussi à faire un bout de configuration iptables qui fonctionnait. Les paquets étaient bien envoyés à l'IPBX mais ils n'étaient pas retournées vers l'équipement CLIENTX. Peut etre qu'il manquait un bout de conf sur CLIENTX..
Car je ne pas utiliser la NAT avec des ports due au fait que les équipements IPBXX ne sont pas simple à configurer et des outils spécifiques sont utilisés. Autant dire que l'on ne peut presque pas toucher la configuration des IPBX.
Intéressant, je ne connaissais pas, par contre je ne pense pas que ce soit très adapté à mon cas. De ce que j'ai lu c'est plus pour les clients qui se connectent et déconnectent régulièrement comme des clients wifi ou des téléphones mobiles.
En fait non car on a pas besoin d’être sur que les paquets arrivent cela fait perdre du temps pour pas grand choses. Quelques pertes ne sont pas très grave. Il faut privilégier la vitesse donc UDP est souvent choisit.
Oui je devrais avoir un peu de latence, j'avais environ 150ms avec OpenVPN avec SOCKS je pense que je peux baisser pas mal du fait que seulement le jeu passera par le proxy (et il n'y a peut être pas autant de cryptage ? à vérifier).
# Confusion
Posté par tofu . En réponse à la dépêche Sortie de Bokeh 7.10. Évalué à 3.
A ne pas confondre avec la librairie Python !
[^] # Re: regles de NAT sur les machines CLIENT-X
Posté par tofu . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.
J'ai donc testé la solution 1 qui me parait être la plus simple.
Pour les tests j'ai remplacé l'IPBX par un Debian et j'ai donc ces adresses :
- Server {tun0=10.64.0.1}
- CLIENT-1 {tun0=10.64.0.100; eth0=192.168.138.16}
- IPBX {eth0=192.168.138.12}
L'IP 192.168.138.12 (IPBX) est translatée en 10.64.0.200.
J'ai utilisé l'option client-nat d'OpenVPN pour pousser sur CLIENT-X la conf de NAT ci-dessous:
Avec cette configuration quand je lance un ping 10.64.0.200 depuis 10.64.0.1 (Server) :
Server
CLIENT-1 (tcpdump)
IPBX (tcpdump)
Donc en résumé on dirait qu'il manque quelque chose sur CLIENT-1 au niveau de la NAT pour translater 192.168.138.16 en 10.64.0.1 ?
J'ai un peu du mal avec la NAT ^
[^] # Re: regles de NAT sur les machines CLIENT-X
Posté par tofu . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.
Exactement.
J'avais réussi avec quelques lignes d'iptables sur CLIENT-X à convertir 10.1.0.y en 192.168.0.y, les paquets allaient jusqu'à l'IPBX mais ne revenaient pas.
Je ne sais pas s'il est possible de faire une translation sans toucher à la configuration de l'IPBX ?
[^] # Re: NAT
Posté par tofu . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.
Donc le but est de se connecter à Server pour avoir accès à tous nos équipements chez le client grâce à l'équipement Linux qui sert de point d'entrée.
On peut imaginer Server dans un VPS chez un hébergeur type DigitalOcean.
Ici je n'ai représenté qu'un seul client pour ne pas compliquer le schéma mais c'est grossièrement la même chose chez les autres clients.
Donc on peut avoir différent type d'équipements.
[^] # Re: NAT
Posté par tofu . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.
Je veux avoir une connexion sur les équipements de nos clients. Donc il y a du SSH, du telnet, des protocoles proprios Avaya pour les configurations et du debug, du tftp, du SNMP etc.. Donc c'est pour ça que la redirection par port est trop complexe dans ce cas.
[^] # Re: SSH ?
Posté par tofu . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1. Dernière modification le 21 juillet 2016 à 15:11.
Non plus ! Ou peut etre pour les versions serveur mais ce n'est pas le cas ici.
[^] # Re: NAT
Posté par tofu . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.
Je venais de lire ce lien mais effectivement on peut faire mieux :P J'ai fini par comprendre que c'était tout simplement un bridge..
Le schéma plus complet est le suivant:
PS: FW est le firewall du client.
L'équipement CLIENTX n'est donc pas directement connecté à l'IPBX. Ce qui, sauf si je dis une bétise, ne fonctionne pas.
[^] # Re: NAT
Posté par tofu . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1. Dernière modification le 21 juillet 2016 à 14:05.
Effectivement ce serrait une idée si il n'y avait qu'un seul équipement. Parfois il peut y avoir plusieurs équipement de nature différente derrière un équipement CLIENTX. Ou peut-etre n'ais-je pas tout compris de ce que tu voulais dire par pont réseau..
[^] # Re: Réseau mesh
Posté par tofu . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.
Ok je vais essayer de creuser un peu plus. Si j'ai bien compris il n'y a rien à installer coté IPBX dans mon cas ?
[^] # Re: NAT
Posté par tofu . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.
Hélas non je ne peux pas c'est du Avaya donc du proprio..
[^] # Re: NAT
Posté par tofu . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.
Pour la partie VPN effectivement les clients ne sont pas isolés! Par contre j'ai pu lire qu'il était possible de translater une plage d'adresse entière. Par exemple 192.168.100.0/24 -> 10.64.100.0/24. J'avais réussi à faire un bout de configuration iptables qui fonctionnait. Les paquets étaient bien envoyés à l'IPBX mais ils n'étaient pas retournées vers l'équipement CLIENTX. Peut etre qu'il manquait un bout de conf sur CLIENTX..
Car je ne pas utiliser la NAT avec des ports due au fait que les équipements IPBXX ne sont pas simple à configurer et des outils spécifiques sont utilisés. Autant dire que l'on ne peut presque pas toucher la configuration des IPBX.
[^] # Re: Réseau mesh
Posté par tofu . En réponse au message Entrelacement de réseaux et VPN. Évalué à 1.
Intéressant, je ne connaissais pas, par contre je ne pense pas que ce soit très adapté à mon cas. De ce que j'ai lu c'est plus pour les clients qui se connectent et déconnectent régulièrement comme des clients wifi ou des téléphones mobiles.
[^] # Re: avec ssh
Posté par tofu . En réponse au message Proxy SOCKS5: connexion impossible. Évalué à 1.
En fait non car on a pas besoin d’être sur que les paquets arrivent cela fait perdre du temps pour pas grand choses. Quelques pertes ne sont pas très grave. Il faut privilégier la vitesse donc UDP est souvent choisit.
Oui je devrais avoir un peu de latence, j'avais environ 150ms avec OpenVPN avec SOCKS je pense que je peux baisser pas mal du fait que seulement le jeu passera par le proxy (et il n'y a peut être pas autant de cryptage ? à vérifier).
[^] # Re: avec ssh
Posté par tofu . En réponse au message Proxy SOCKS5: connexion impossible. Évalué à 1.
Les jeux en réseaux. Pourquoi ?
[^] # Re: avec ssh
Posté par tofu . En réponse au message Proxy SOCKS5: connexion impossible. Évalué à 1.
Donc l'UDP devrait passer ?
[^] # Re: diff entre ta conf et le tuto
Posté par tofu . En réponse au message Proxy SOCKS5: connexion impossible. Évalué à 1. Dernière modification le 05 janvier 2014 à 20:05.
Oui et du coup j'écoute sur 127.0.0.1 et mon adr local: (netstat -natp)
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp 0 0 0.0.0.0:51413 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:1080 0.0.0.0:* LISTEN -
tcp 0 0 192.168.0.26:1080 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN -
tcp 0 0 192.168.0.26:22 **:41424 ESTABLISHED -
tcp 0 572 192.168.0.26:22 **:37848 ESTABLISHED -