Je rencontre un problème d’accès à Tomcat avec SSL sous MS ISA 2006.
Lorsque j'accède en utilisant l'adresse IP interne (par exemple, https://10.0.42.136/.. ), Tout fonctionne correctement et localhost_access_log. montrez-moi que la requête renvoie 200.
Cependant, si vous accédez au même serveur à l'aide du nom de domaine complet (par exemple, https : //mydomain.com/... ) Lance un message 403 - Forbidden dans le navigateur. Sur le serveur Tomcat, je trouve une erreur 401 dans la liste, pas 403. En d’autres termes, ISA jette 403 tandis que Tomcat jette 401.
Le serveur hébergeant le Tomcat ainsi que le serveur interrogeant l'application Tomcat ont un accès complet à Internet.
Je pense qu’il pourrait y avoir un problème avec le serveur ISA, car je suppose que le trafic des adresses IP passe directement, tandis que le trafic des noms de domaine complets s’éteint avant de revenir. Mais je ne suis pas sûr de cela.
Tomcat a-t-il besoin d'une configuration supplémentaire pour desservir le trafic https de l'extérieur, par exemple, ajouter l'adresse IP du serveur ISA, puisqu'il fonctionne parfaitement avec l'adresse IP?
Devons-nous faire quelque chose en ce qui concerne les certificats, comme indiqué ici: http://webcache.googleusercontent.com/search?q=cache:Y0BozNSUpN4J:forums.isaserver.org/fb.aspx%3Fm%3D2002034493+tomcat+behind + isa + serveur + certificats & cd = 1 & hl = no & ct = clnk & gl = no ?
Pourquoi le trafic de mon ordinateur client à l'extérieur va-t-il très bien, alors que le trafic du réseau interne échoue?
la source
mydomain.comdonne la bonne adresse IP du serveur? Sinon, vous pourriez être dirigé vers un autre serveur!Réponses:
Une hypothèse qui
nslookup mycompany.comimprime l'adresse IP du serveur ISA et10.0.42.136correspond à l'adresse IP du Tomcat (pas de l'ISA).Ainsi, lorsque vous vous connectez,
https://10.0.42.136/vous vous connectez directement à Tomcat (sans ISA). Vous pouvez simplement vérifier si la connexion à Tomcat avec FDQN fonctionne si vous écrivez ce qui suit dans votre fichier hosts :(Le chemin du fichier est généralement
c:\windows\system32\drivers\etc\hostsou/etc/hosts.)Après cela, vérifiez
pingque votrehostsentrée de fichier est exacte. La commande et les résultats devraient ressembler à ceci:Si ce sont des pings,
10.0.42.136vérifiezhttps://mycompany.com/dans un navigateur. Peut-être devez-vous redémarrer le navigateur avant de l'utiliser et n'oubliez pas de supprimer la ligne duhostsfichier ultérieurement.Si le site Web fonctionne bien avec l'
hostsentrée de fichier, il s'agit certainement d'un problème de serveur ISA. Sinon, le problème est lié à Tomcat.la source
Vous n'avez rien dit à propos du client, et c'est important. Le client doit-il sortir pour accéder au nom de domaine complet? Avez-vous dit qu'il est local, ou qu'il devrait éviter le proxy, pour cette URL? (quel est le client?)
Quoi qu'il en soit, à part cela, je pense que vous pourriez bénéficier d'une protection contre les attaques par réflexion.
Plus classique: si votre jeu de règles n'indique pas que les hôtes internes peuvent parler à d'autres hôtes internes, ils ne le peuvent pas.
Si le nom de domaine complet est conçu pour sortir de votre réseau et y revenir via ISA, un ensemble de règles permettant cette combinaison est nécessaire.
Par conséquent, si vous souhaitez autoriser les clients du réseau interne à se connecter à votre site Web externe HTTPS, essayez une règle du type: Autoriser / HTTP et HTTPS / De: Réseau interne / Vers: IP interne de l'hôte utilisé (vous pouvez également essayer un ensemble d'URL. y compris, mais ce n'est peut-être pas nécessaire.
la source