ConnectException: timed out - appli client serveur
Bonjour,
dans le cadre du déploiement d'une appli java de gestion de projet dans l'entreprise où je travaille, j'ai été amené à effectuer des tests d'accès au serveur (Apache / Tomcat) depuis un poste client extérieur (plateau sous-traitant). Cela fonctionne très bien en interne, ou avec une connexion VPN, mais je rencontre un problème de connexion (timeout) lors de la connexion au serveur.
Je reprends le contexte pour situer :
- appli java client-serveur (tourne avec un JRE 1.4.2 ou >)
- serveur apache / tomcat 5.0.28
- réseau : réseau d'entreprise, avec un accès sécurisé par jeton pour les sites externes
=> schéma réseau : Appli => IPinterne (en 152....) <= routeur NAT // firewall => IPexterne (en 195....) <= poste Client
- les IP concernées ne sont pas 'pingables' depuis le net.
- l'appli est accessible en HTTP par le port 8080 (routage ok...); les transactions sont toutes en TCP
- le plateau externe n'utilise ni proxy, ni firewall
Fonctionnement normal (en interne ou avec connexion VPN) :
- 1) connexion à l'adresse du serveur d'appli avec un navigateur web (IE6)
- 1bis) (1er accès seulement) vérification présence et version JVM (s'installe au besoin)
- 2) sélection du mode de lancement (même fenêtre, nouvelle, avec Java Web Start)
- 3) chargement des .jar
- 4) fenêtre d'authentification (tomcat)
- 5) initialisation de l'appli et chargement des ressources
- 6) ouverture fenêtre de l'appli => OK pour utilisation
Fonctionnement depuis le plateau :
- étapes 1 à 4 OK
- authentification :
# login/mdp fictifs => signale un couple login/mdp inexistant
# login/mdp corrects => "freeze" du splash screen de lancement pendant 10 à 20 secondes, puis message d'erreur, et l'appli se ferme.
le rapport d'erreur généré contient les lignes suivantes :
"java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
[...]
at org.apache.catalina.core.[...]
[...]
at com.sciforma.psnext.client.ClientApplet.init(DashoA10*..:102)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)"
après quelques jours passés à rechercher les causes possibles, je commence à manquer un peu d'idées: je me demandais cependant si la translation d'adresse ne pouvait pas poser un problème d'adressage des paquets (je ne sais pas encore s'ils sont cryptés lors des échanges, ou pas...) ?
Si vous rencontrez le même type de difficultés, que vous avez des suggestions ou des pistes à proposer, je serais heureux de pouvoir en tenir compte dans mes prochains tests.
Merci d'avance pour votre aide
NB: je ne sais pas si l'explication du contexte est assez claire, n'hésitez pas à demander plus d'infos au besoin !
Résolu... mais pas compris pourquoi !!!
chouchou93: merci pour ton aide; le délai était d'environ 15 secondes, mais les connections entre la base de données et la servlet se font de manière transparente pour le client (aucun accès direct). A l'exception de l'erreur citée plus tôt, les autres connections étaient 'rapides' (pas de différence notable entre les tests en interne et depuis l'extérieur), sauf à partir de l'initialisation de l'applet.
Il y a effectivement la possibilité de régler le timeout de connection dans les fichiers de configuration de tomcat -je ne suis pas spécialiste du sujet donc pas beaucoup plus d'infos- je crois que c'est 120s par défaut...
Bon, j'ai finalement trouvé comment accéder à l'application, mais sans avoir totalement compris pourquoi...
Il suffit en fait d'utiliser l'adresse translatée comme serveur proxy dans les paramètres d'internet explorer (pas testé sur firefox...), et de saisir l'adresse du réseau interne comme URL.
Les paramètres proxy de la JVM doivent utiliser la config du navigateur (pas de paramétrage supplémentaire).
Ceci dit, si quelqu'un a un peu plus d'informations sur la manière dont java gère les translations d'adresse en TCP, je suis toujours intéressé. D'autant que dans le cas -certes un peu complexe- de plusieurs réseaux interconnectés, avec donc plusieurs routeurs NAT, cette solution ne doit plus fonctionner.
Il est possible de paramétrer des proxys dans le code de l'appli Java, mais j'ai l'impression que cela se complique sérieusement dès qu'il faut en passer plusieurs...
@+, je reste à l'écoute sur ce sujet.