Zentyal Forum, Linux Small Business Server
International => French => Topic started by: ypatrick on January 30, 2014, 03:48:44 pm
-
Bonjour à tous,
Je suis désolé si un post similaire existe déjà sur le forum, ce n'est pas par faute d'avoir cherché depuis hier.
En fait, ma société est répartie sur plusieurs sites distants, chaque site devra être géré par un serveur Zentyal.
Pour des besoins de la société, je dois fusionner le réseau de deux sites, pour le faire, je veux configurer un VPN Zentyal<------>Zentyal, chaque site disposant d'une adresse publique.
J'ai bien créé le serveur VPN sur le premier site tel que décrit sur le site de zentyal
- Créer un CA pour le serveur
- Créer un certificat pour le client distant
- Créer un serveur VPN:
- port UDP
- VPN address: 192.168.160.0/24
- Server certificate: le-certificat-serveur
- allow zentyal to zentyal tunel
- password
Sur le serveur client
J'ai uploadé le fichier de configuration que j'ai téléchargé du serveur VPN
J'ai activé le client
Sur le tableau de bord du serveur VPN je vois bien qu'un tunel est créé, ainsi que sur le client VPN sauf que sur ce dernier l'adresse d'interface VPN n'est pas active.
Mon problème c'est comment faire pour activer cette interface.
Vu que chaque site dispose d'une IP publique, il y a t-il n moyen de réaliser efficacement ce VPN.
J'ai vraiment besoin de votre aide pour finaliser cette architecture
Je vous remercie
-
Sur le serveur client
J'ai uploadé le fichier de configuration que j'ai téléchargé du serveur VPN
J'ai activé le client ...
As-tu bien suivi la documentation (http://doc.zentyal.org/en/vpn.html#configuration-of-a-vpn-server-for-interconnecting-networks) ?
Le mode server-to-server fonctionne normalement assez bien.
J'ai vraiment besoin de votre aide pour finaliser cette architecture
Dans les cas complexes ou les situations de production critiques, je pense qu'il ne faut pas hésiter à faire appel à un partenaire Zentyal
-
Oui en effet, j'envisage passer par un partenaire, il faut dire que j'ai découvert Zentyal chez un collègue il y a seulement quelque mois, la solution me plaît bien, je serai en effet intéressé sur tu pouvais m'orienter vers quelques partenaires.
Pour en revenir à mon problème, si je comprends bien je créé un serveur VPN sur chaque Zentyal, et le client de l'un se connecte au serveur de l'autre
-
Je ne peux pas t'orienter vers un partenaire, n'étant pas moi-même lié à Zentyal mais je pense qu'il y a sur le site de Zentyal une liste de partenaires par pays.
Pour ce qui est du VPN, c'est effectivement l'idée: il y a un serveur Zentyal de chaque coté. Le serveur "central" est configuré comme serveur VPN sur lequel tu as pris soin d'activer la fonction qui autorise les tunnels "de Zentyal à Zentyal".
Les autres serveurs Zentyal vont se comporter comme des clients.
-
Ok, j'essaie de mettre ca en place et je reviens
-
J'ai bien créé un serveur de chaque côté, chacun ayant un réseau local du style:
192.168.160.0/24
Je créé un client VPN de chaque côté et je charge les configurations du serveur VPN distant en ayant pris soin de fixer son adresse publique, mais malgré ça, sur le tableau au niveau du client VPN, j'ai ceci:
Service Activé
Status du service En cours d'execution
Cible de connection 172.xx.xx.xx 7766/UDP
adresse de l'interface RPV (VPN) Non actif
et ceci sur chaque zentyal
-
En sur le tableau de bord de chaque zentyal j'ai ceci:
ZENTYAL 1
Serveur interco-coo-plant
Service Activé
Status du service En cours d'execution
Adresse locale 172.xx.xx.aa
Port 1194/UDP
Sous-réseau RPV (VPN) 192.168.161.0/255.255.255.0
Interface réseau RPV (VPN) tap1
adresse de l'interface RPV (VPN) 192.168.161.1/24
Client openvp-eth1-192.168.0.0
Service Activé
Status du service En cours d'execution
Cible de connection 172.xx.xx.bb 7766/UDP
adresse de l'interface RPV (VPN) Non actif
ZENTYAL 2
Serveur interco-masse-coo
Service Activé
Status du service En cours d'execution
Adresse locale 172.xx.xx.bb
Port 7766/UDP
Sous-réseau RPV (VPN) 192.168.161.0/255.255.255.0
Interface réseau RPV (VPN) tap1
adresse de l'interface RPV (VPN) 192.168.161.1/24
Client openvp-eth1-192.168.0.0
Service Activé
Status du service En cours d'execution
Cible de connection 172.xx.xx.aa 1194/UDP
adresse de l'interface RPV (VPN) Non actif
-
IL y a une petite erreur de compréhension: ce n'est pas un client + un serveur de chaque coté (et donc 2 tunnels) mais un seul serveur, en central (si tu as plusieurs clients qui se connectent dessus) et des clients tout autour qui sont eux aussi des serveurs Zentyal
-
C'est ce que j'avais fait la première fois et j'avais ceci au tableau de bord
Client openvp-eth1-192.168.0.0
Service Activé
Status du service En cours d'execution
Cible de connection 172.xx.xx.xx 7766/UDP
adresse de l'interface RPV (VPN) Non actif
Au niveau de chaque serveur ZENTYAL client, j'utilise VPN----->Clients pour accéder au serveur VPN central, je crois bien que c'est la procédure
Je ne sais vraiment plus par où chercher
-
J'ai tout ce que je pouvais pour réussir mon VPN en vain.
Sur le client j'ai ce log qui revient tout le temps
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Jan 31 15:11:20 2014 TLS Error: TLS handshake failed
Fri Jan 31 15:11:20 2014 TCP/UDP: Closing socket
Fri Jan 31 15:11:20 2014 SIGUSR1[soft,tls-error] received, process restarting
Fri Jan 31 15:11:20 2014 Restart pause, 2 second(s)
Fri Jan 31 15:11:22 2014 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Fri Jan 31 15:11:22 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Jan 31 15:11:22 2014 Re-using SSL/TLS context
Fri Jan 31 15:11:22 2014 LZO compression initialized
Fri Jan 31 15:11:22 2014 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Jan 31 15:11:22 2014 Socket Buffers: R=[212992->131072] S=[212992->131072]
Fri Jan 31 15:11:22 2014 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Jan 31 15:11:22 2014 Local Options hash (VER=V4): 'd79ca330'
Fri Jan 31 15:11:22 2014 Expected Remote Options hash (VER=V4): 'f7df56b8'
Fri Jan 31 15:11:22 2014 UDPv4 link local: [undef]
Fri Jan 31 15:11:22 2014 UDPv4 link remote: [AF_INET].31.252.42:1194
Fri Jan 31 15:11:22 2014 TLS: Initial packet from [AF_INET].31.252.42:1194, sid=b992477e 92cca2f8
Et sur le serveur j'ai ça:
TLS: Initial packet from [AF_INET].31.233.6:43542 (via [AF_INET].31.252.42%eth2), sid=765d1cb9 96ba321f
Fri Jan 31 14:10:46 2014 .6:43542 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Jan 31 14:10:46 2014 .31.233.6:43542 TLS Error: TLS handshake failed
Fri Jan 31 14:10:46 2014 31.233.6:43542 SIGUSR1[soft,tls-error] received, client-instance restarting
Fri Jan 31 14:10:48 2014 MULTI: multi_create_instance called
Fri Jan 31 14:10:48 2014 .31.233.6:45463 Re-using SSL/TLS context
Fri Jan 31 14:10:48 2014 .31.233.6:45463 LZO compression initialized
Fri Jan 31 14:10:48 2014 .31.233.6:45463 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Jan 31 14:10:48 2014 .31.233.6:45463 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Jan 31 14:10:48 2014 .31.233.6:45463 Local Options hash (VER=V4): 'f7df56b8'
Fri Jan 31 14:10:48 2014 .31.233.6:45463 Expected Remote Options hash (VER=V4): 'd79ca330'
J'ai vraiment besoin de votre aide.
-
Pour donner suite à notre échange et parce que ça peut également servir à d'autres:
j'avais écrit il y a quelques mois un petit bout de documentation pour expliquer (en anglais) quelques trucs autour du VPN de serveur à serveur.
Ce n'est pas basé sur la version 3.2 ou 3.3 mais le principe reste le même.
C'est ici (http://trac.zentyal.org/wiki/Documentation/Community/HowTo/Zentyal-to-Zentyal-VPN-study).
-
Après investigation (nous avons passé pas mal de temps ensemble sur les machines en remote sans succès), j'ai fini par émuler en local cette configuration.
J'ai pu reproduire cette situation en insérant un FW entre le client et le serveur et en n'autorisant pas UDP.
Une fois UDP autorisé, le tunnel s’établit correctement.
Avant établissement du tunnel sur les machines citées, nous nous sommes assurés que celles-ci se "voyaient" via des ping mais j'ai omis de test la couche UDP qui semble être une des causes possible du problème.