Cryptage des communications client-Serveur

Bonjour,

Ca y est, j’ai fait le grand saut en V17.1 !

Mais quelques petites frayeurs quand même sur les premières minutes à cause du Cryptage des communications client-Serveur.

Pour info, je suis en client-serveur Mac OS non compilé avec 82 licences.

Au bout de quelques minutes, j’ai été obligé de désactiver le cryptage des communications car les utilisateurs avait le message suivant (soit au lancement de 4D, soit alors qu’ils étaient déjà connecté) :

Interruption de la connexion pour ce process ou bien la connexion n’a pu être établie - Erreur de connexion avec le serveur.

Et dans une 2ème fenêtre : Echec d’écriture SSL

Pour valider ce cryptage, j’ai acheté un certificat SSL, et j’ai mis dans le dossier Ressources de l’application client (et serveur aussi) les fichiers cert.pem et key.pem personnalisés à mon domaine.

Mais au final, cela ne fonctionne pas, les premiers utilisateurs arrivent se connecter mais rapidement les suivants sont refusés et certains des premiers sont même éjectés de façon à priori aléatoire.

Est-ce que quelqu’un a déjà rencontré ce genre de soucis ?
Est-ce que le fait d’être non compilé serait la raison ?
Est-ce mon certificat qui pose soucis et j’aurais du garder le cert.pem et key.pem livré en standard ?

J’avais déjà remarqué il y a quelques semaines que l’activation du cryptage me faisait des utilisateurs fantômes si jamais un utilisateur changeait d’adresse IP en cours de connexion, et là, je me retrouve avec un autre soucis lié au cryptage des communications …

Est-ce que c’est vraiment au point ce cryptage ?

Bref, je suis perplexe … J’espère que je n’aurais pas d’autres mauvaises surprises avec la V17 …

: David GOUYGOU

Bref, je suis perplexe … J’espère que je n’aurais pas d’autres
mauvaises surprises avec la V17 …
Je ne peux rien dire du cryptage C/S, par contre on a déployé récemment une v17 r2, ça baigne, un vrai bonheur. Un bravo ému à 4D, aussi bien pour la fiabilité de cette version que pour le pied que c’est de travailler avec !

Tu ne précises pas en quelle version 32 ou 64 bit ? ancienne ou nouvelle couche réseau ?

Ah oui 64 bits, nouvelle couche réseau.

Il n’y a pas besoin d’activer le cryptage pour avoir des utilisateurs fantômes.
Étant donné que l’IP du client est un identifiant de connexion, il ne sera plus reconnu s’il en change.

Tu as un moyen de traiter ça, coté serveur ?

: Stanislas CARON

Il n’y a pas besoin d’activer le cryptage pour avoir des utilisateurs
fantômes.
Étant donné que l’IP du client est un identifiant de connexion, il ne
sera plus reconnu s’il en change.
Justement c’était un des changements prévus avec la nouvelle couche réseau de gérer un identifiant unique (fichier 4Dpeer.txt) de l’utilisateur pour gérer cela y compris le basculement d’IP.

Donc normalement, il ne devrait PAS(plus) y avoir de connexion fantôme pour un client se connectant d’une même machine (même session).

Reste le soucis du timeout de la mise en veille d’une connexion (on ne peut pas laisser le time out par défaut de 48h ce n’est pas raisonnable pour tous les cas de figure). Les licences sont mangées trop vite.

Bonjour,

: David GOUYGOU

J’espère que je n’aurais pas d’autres mauvaises surprises avec la V17

La v17 n’y est pour rien.
Le soucis est (comme précisé avant) :

: David GOUYGOU

Bonjour,
un utilisateur changeait d’adresse IP en cours de connexion
L’IP d’un client doit être fixe durant sa session.
Si l’IP du client change n’est-ce pas le signe que ce client à perdu sa connexion au réseau ?

Cordialement,

: Arnaud DE MONTARD

Tu as un moyen de traiter ça, coté serveur ?
Bah à part déconnecter les utilisateurs en question à la main, je ne vois pas. Et encore, des fois on ne peut pas.

C’est un vrai problème ce bridage d’une IP fixe durant la session. Je n’en comprend pas la raison.
Dans certains cas, l’IP change, par exemple un portable qui change de zone.

Dans la session de Sergyi sur la nouvelle couche réseau que j’avais suivi au summit, il avait pourtant bien annoncé qu’on pourrait envisager d’entamer un traitement au bureau, de fermer son portable, de le rouvrir à la maison et que le traitement continuerait comme si de rien n’était.
L’IP ne devait donc pas être fixe et le serveur devait se baser sur un id session. C’était un mode déconnecté comme sur le web.
Cela n’a pas été le cas au final et ça pose principalement le problème des licences mangées et irrécupérables sans intervention manuelle. Quand cela se produit plusieurs fois dans la journée, ça peut devenir un calvaire.

: Stanislas CARON
: Arnaud DE MONTARD

Tu as un moyen de traiter ça, coté serveur ?
Bah à part déconnecter les utilisateurs en question à la main, je ne
vois pas. Et encore, des fois on ne peut pas.
Mmmm, je vois ; chance, je ne suis pas confronté à ce problème, nos utilisateurs sont ficelés à des postes fixes.
En fait je cherche à savoir si quelqu’un a expérimenté une des commandes dont Intissar parlait https://forums.4d.com/Post/FR/28121532/1/28121533#28121533ici>, DROP REMOTE USER. Mais je ne vois pas trop sur quel critère le serveur pourrait décider qu’il est temps de droper le remote usé.

Attention, de mon côté, je parle de deux problèmes différents.

  • Le changement d’adresse IP en cours de session qui fait des fantômes est un problème n°1.

  • Mais le problème que j’ai eu ce matin après avoir tout basculé en V17 hier soir est qu’en laissant activé le cryptage des communications, au bout de quelques minutes, les utilisateurs avait le message suivant (soit au lancement de 4D, soit alors qu’ils étaient déjà connecté) :

Interruption de la connexion pour ce process ou bien la connexion n’a pu être établie - Erreur de connexion avec le serveur. Et dans une 2ème fenêtre : Echec d’écriture SSL.

Et ceci pour des utilisateurs qui n’ont aucun soucis ou de changement d’adresses IP.

Il s’agit donc bien de 2 problèmes différents.

Autant le changement d’IP en cours de session n’est pas forcément le plus grave dans mon cas, autant le fait de ne pas pouvoir crypter les communications est un souci.

Mais je m’y prends peut-être mal. Pour valider ce cryptage, j’ai acheté un certificat SSL, et j’ai mis dans le dossier Ressources de l’application client (et serveur aussi) les fichiers cert.pem et key.pem personnalisés à mon domaine; et j’ai coché la case côté serveur.

D’où peut donc venir ce refus de connexion ?

: Olivier DESCHANELS

Le soucis est (comme précisé avant) :

: David GOUYGOU

Bonjour,
un utilisateur changeait d’adresse IP en cours de connexion
L’IP d’un client doit être fixe durant sa session.
Si l’IP du client change n’est-ce pas le signe que ce client à perdu
sa connexion au réseau ?

C’est oublier un peu rapidement le deuxième GROS changement de la nouvelle couche réseau qui est la gestion des mises en veille des postes.

Que se passe t’il si un poste client se connecte, puis le poste est mise en veille, puis déplacé dans une autre salle, l’utilisateur réouvre son poste tente une reconnexion au serveur (qui a conservé la session en veille) et là il y a changement d’IP (car connexion en WIFI sur une autre borne réseau et le poste en DHCP) entre temps mais NORMALEMENT la session de travail doit reprendre sur le serveur comme si de rien n’était !!!

D’où l’utilisation du 4Dpeer.TXT (qui contient une clé unique de session qui n’a rien a voir avec l’IP du poste !)

Merci de vous renseignez (auprès de qui connait) et de nous dire clairement si cela est toujours d’actualité ( :?:slight_smile: ou si changement dans le comportement annoncé. :-?

: Stanislas CARON

L’IP ne devait donc pas être fixe et le serveur devait se baser sur
un id session. C’était un mode déconnecté comme sur le web.
Cela n’a pas été le cas au final et ça pose principalement le
problème des licences mangées et irrécupérables sans intervention
manuelle. Quand cela se produit plusieurs fois dans la journée, ça
peut devenir un calvaire.
Où as-tu obtenu ces infos ? qui a dit que ce n’était plus le comportement souhaité ?
Et je confirme que l’implémentation actuellement de la gestion du time out des mises en veille n’est pas tenable pour des gestions de licence restreintes !

  • client fantôme
  • licence mangée
  • non reconnexion après un changement d’IP
  • Problème de cryptage ?
  • gestion des mises en veille

Tous ces problèmes étaient censés être réglés avec cette nouvelle couche réseau…

: Manuel PIQUET

Où as-tu obtenu ces infos ?
Je le dis dans le même message, dans une session du summit par le créateur de cette nouvelle couche réseau.

Je te parle de la phrase suivante qui dit que ce n’est plus
d’actualité (ou pas fait).

: Stanislas CARON

Cela n’a pas été le cas au final…

: Stanislas CARON

dans une session du summit par le créateur de cette nouvelle couche
réseau.
J’y étais aussi… :wink:

Plusieurs sources :wink:
Déjà, c’est un constat.
Ça a été dit par quelqu’un de chez 4D (je ne sais plus qui) à un responsable de chez nous.
Olivier vient de dire sur ce fil que l’IP devait être fixe toute la session.

Je ne sais pas qui a décidé de ça. Je n’en comprend pas la raison. Pour moi, rien ne l’obligeait.
Avoir une session (et donc une licence) bloquée, ne serait-ce qu’à cause d’un plantage, est une régression.

Un constat que j’ai fait lors de mes premiers tests, il y a 6 mois… :evil:

Si c’est OFFICIEL c’est TRES grave !!! :-o

C’est une regression complète par rapport à l’ancienne couche réseau qui avait(puisque plus utilisable en 64 bit ?!) alors au moins le mérite de libérer correctement les licences dans le cas d’une déconnexion !

Là avec la gestion des postes qui se mettent en veille et la non reprise correcte du travail ensuite, les licences sont bouffées ( :!:slight_smile: immédiatement.

Il est INCONCEVABLE de devoir resté devant le serveur pour gérer les licences à la main…

client fantôme
j’en ai vu quand on venait de mettre la v17 en prod, mais ce jour là le serveur devait être un peu énervé par les pétouilles qu’on avait laissé trainé, deux ou trois ajustements environnementaux à faire, etc. Plus rien depuis.
gestion des mises en veille
Ce point là marche bien, pour moi ; je fais la sieste avec mon poste, on se réveille de concert, tout est comme avant, c’est beau l’amour.

Pour avoir fait toute une série de tests pour planter volontairement 4D, j’ai surtout constaté pour les fantômes que le souci est présent avec le cryptage des communications clients/serveur.

Et quand j’ai un fantôme sur le serveur, impossible de le déconnecter manuellement. Et si je tentes de fermer l’appli serveur pour la relancer, celle-ci ne répond plus et je suis obligé à forcer à quitter pour reprendre la main tant que j’ai un fantôme.

Pour la gestion de la mise en veille (ordi portable fermé par exemple), j’ai jamais réussi à dépasser les 50 secondes de mise en veille côté client …
Ou alors, cela n’est correctement géré que les applis compilées et pas en client/serveur ?

Quels sont les bons paramètres et comment gérer correctement la mise en veille car impossible de trouver des infos sur le doc center ?