Nous avons un produit que nous déployons dans certaines petites entreprises. Il s'agit essentiellement d'une API reposante sur SSL en utilisant Tomcat. Ceci est installé sur le serveur dans la petite entreprise et est accessible via un appareil iPhone ou un autre appareil portable de périphérique. Ainsi, les périphériques qui se connectent au serveur peuvent provenir de n'importe quel nombre d'adresses IP.
Le problème vient avec l'installation. Lorsque nous installons ce service, il semble toujours devenir un problème lors du transfert de ports afin que le monde extérieur puisse avoir accès à Tomcat. Il semble le plus de temps que le propriétaire ne connaisse pas le mot de passe de routeur, etc., etc.
J'essaie de rechercher d'autres moyens que nous pouvons y accomplir. J'ai proposé ce qui suit et aimerais entendre d'autres pensées sur le sujet.
Configurez un tunnel SSH de chaque bureau client sur un serveur central. Fondamentalement, les périphériques distants se connecteraient à ce serveur central sur un port et que le trafic serait tunnel à Tomcat au bureau. Semble un peu redondant d'avoir SSH, puis SSL, mais vraiment pas d'autre moyen de l'accomplir depuis la fin de la fin, j'ai besoin de SSL (de l'appareil au bureau). Pas sûr des implications de performance ici, mais je sais que cela fonctionnerait. Aurait besoin de surveiller le tunnel et de le ramener si cela se passe, il faudrait gérer les échanges clés de SSH, etc.
SETUP UPNP Pour essayer de configurer le trou pour moi. Travaillera probablement la plupart du temps, mais UPnP n'est pas garanti d'être allumé. Peut être une bonne étape suivante.
propose un type de schéma transversal NAT. Je ne suis tout simplement pas familier avec ceux-ci et incertain de la façon dont ils fonctionnent exactement. Nous avons accès à un serveur centralisé qui est requis pour l'authentification si cela facilite la tâche.
Que devrais-je regarder d'autre pour obtenir cela accompli?
8 Réponses :
Configurez un Apache devant votre Tomcat. Cet apache doit être visible d'Internet, où le Tomcat ne devrait pas.
Configurez Apache pour transmettre tout le trafic vers Tomcat. Ceci peut facilement être accompli avec mod_proxy (Découvrez la proxypasse et le proxyptassiffus directives).
Avez-vous votre certificat SSL situé dans l'Apache, de sorte que tous les clients puissent parler HTTPS avec le serveur Apache, qui parle à tour de rôle HTTP avec Tomcat.
Pas de tunneling ou autre méchanceté + Vous serez surpris de voir à quel point il est facile de configurer Apache pour le faire.
Je ne pense pas que vous compris la question. Tomcat est sur une adresse IP privée derrière la NAT. Mettre Apache devant elle ne résoudra rien. Les personnes à l'extérieur du NAT ont encore besoin d'accéder au service, que ce soit Tomcat ou Apache. J'ai déjà Tomcat exécutant SSL répondant à un port. C'est juste que j'ai besoin de frapper le trou dans le pare-feu et j'essaie d'éviter cela.
Oui, la solution ci-dessus suppose que Apache est en dehors de votre réseau privé et que Apache et Tomcat vous parlent d'un trou dans le pare-feu. Désolé de ne pas être plus explicite à ce sujet. Avec cette configuration, les clients n'ont pas besoin d'un accès direct à votre réseau privé, car toutes les demandes entrent via le serveur Apache. Dans mes yeux, cela crée une configuration sûre et maintenable. Surtout que le trou du pare-feu n'est ouvert que pour l'adresse IP du serveur Apache et vous pouvez sécuriser l'Apache tout ce que vous aimez.
J'aurais toujours besoin de frapper le trou dans le pare-feu, ce que j'essaie d'éviter.
Oui, je me rends compte que (BWT: il n'est pas clair de votre question initiale que vous essayez d'éviter cela). Je suppose que mon point de frapper un trou dans le pare-feu pourrait valoir la peine, si le résultat est une configuration propre, sécurisée et conviviale.
N'y a-t-il aucune façon que ce service puisse organiser publiquement par vous ou un fournisseur d'hébergement plutôt qu'avec le client?
J'ai eu une situation similaire lorsque je développais des kiosques. Je n'ai jamais su quel type d'environnement réseau que je devrais faire face à la prochaine installation.
J'ai fini par créer un VPN PPTP pour permettre à tous les kiosques de se connecter à un serveur que j'ai hébergé publiquement. Nous avons ensuite créé un service Web contrôleur pour exposer l'accès aux kiosques qui étaient tous connectés via le VPN. Je ne sais pas à quel point vous êtes familier avec VPN, mais avec la connexion VPN, j'ai pu contourner complètement le pare-feu devant chaque kiosque en accédant au kiosque via l'IP attribuée VPN.
Chaque nœud kiosque a été incroyablement facile à configurer une fois que j'avais une configuration de serveur VPN. Il a également apporté des avantages de la gestion et des revenus de licences que j'ai envisagés à l'origine. Avec cette infrastructure, je pouvais facilement déployer des services accessibles via des téléphones mobiles.
Bonne chance!
Solutions existent à "dynamiquement" accéder à un logiciel sur un ordinateur derrière un NAT, mais généralement principalement pour la communication UDP.
Le Poinçonnage de trou UDP La technique est l'une d'elles. Cependant, ce n'est pas Guranteed de travailler dans toutes les situations possibles de . Si les deux côtés de la communication sont derrière un "cône symétrique", il ne le fera pas.
Vous pouvez certainement réduire la probabilité qu'un client ne puisse pas communiquer à l'aide de UPNP comme alternative de sauvegarde (ou même primaire).
Je ne connais pas suffisamment de services Web et je ne sais même pas si vous utilisez UDP pour votre service WebService est une option (ou si elle est même possible).
Utiliser la même technique pour directement TCP est susceptible d'échouer (les connexions TCP ne sont pas apatrides - qui provoque beaucoup de problèmes ici).
Une alternative utilisant la même technique, serait de configurer du VPN basé sur UDP (juste comme OpenVPN ) , mais comme vous l'avez dit, vous devrez gérer les clés, les certificats, etc. Cela peut être automatisé (je l'ai fait) mais toujours, ce n'est pas vraiment trivial.
Si vous souhaitez vraiment utiliser TCP, vous pouvez créer un logiciel "proxy" simple sur les boîtes client qui serviraient de relais.
Vous auriez le schéma suivant:
Une alternative: vous pouvez demander au logiciel proxy de se connecter directement au demandeur d'améliorer les performances, mais vous pourriez alors rencontrer les mêmes problèmes de NAT que vous essayez d'éviter.
Merci. J'aimerais garder les choses basées sur http, alors besoin de rester avec TCP. J'ai vraiment besoin d'une solution dans laquelle le serveur de la NAT initie une connexion TCP sortante et le maintient, permettant à TCP entrant de se connecter à son contourner et d'être destiné à un certain port.
@Jr vous êtes la bienvenu. Je souhaite qu'il y ait une solution similaire à UDP pour TCP. Malheureusement, les routeurs et les pare-feu sont généralement suffisamment intelligents pour comprendre lorsqu'une connexion TCP est entrante ou ouverte. Ainsi, la technique décrite ne peut pas fonctionner. J'ai toutefois mis à jour ma réponse pour suggérer une nouvelle solution possible .
+1 Voici comment Hamachi et Skype (et, un jour dans l'avenir lointain, Cryptolink).
@Blueraja: Qu'est-ce que CryptoLink?
Logiciel VPN censé travailler 100X mieux (et plus facile) que tout ce que nous avons maintenant. Steve Gibson n'arrive à en parler sur son magnifique podcast, Security maintenant! - Il l'écrit ( Single, en langage de montage) pendant des années ...
Je devais faire quelque chose de similaire dans le passé et je crois La meilleure option est la première que vous avez proposée.
Vous pouvez faire de manière simple, en utilisant SSH avec son option -R, en utilisant Publick Key Auth et quelques scripts pour vérifier Connectivité. N'OUBLIEZ PAS LES DIVERS GARDER GARDER VIVANT ET TEMPSOUT Caractéristiques de SSH.
Ne vous inquiétez pas des performances. Utilisez des utilisateurs et des ports non privilégiés si tu peux. Ne vous inquiétez pas de configurer une ca, la clé publique de chaque télécommande serveur est plus facile à maintenir sauf si vous êtes dans les milliers.
La surveillance est assez simple. Chaque serveur doit tester le service sur le serveur central. S'il échoue, le tunnel est en panne ou qu'il n'y a pas de connectivité. Le redémarrage du tunnel ne nuira dans aucun cas.
ou vous pouvez le faire au niveau du réseau, à l'aide d'IPsec (STARTSWAN). Cela peut être plus difficile à configurer et c'est l'option que j'ai utilisée mais je vais Utilisez SSH la prochaine fois, cela m'aurait sauvé beaucoup de temps.
Le programme "Atossh" résout les problèmes de connectivité. C'est-à-dire que cela maintient toujours le tunnel ouvert et reconnecte si quelque chose échoue (comme le réseau descendant puis revenant). C'est comme ça que je résolvez le problème ci-dessus et cela fonctionne comme un charme. De toute évidence, les touches RSA nécessaires doivent être configurées d'une part.
Si vous souhaitez avoir une intégration reposante au serveur , un tunnel sur le serveur central qui fonctionne comme un proxy, semble la meilleure approche.
mais si ce n'est pas une exigence difficile, vous pouvez laisser le le serveur central manipuler les éléments resultl et intégrer le serveur Central Server et serveur client avec d'autres middleware. Les bons candidats seraient RMI ou JMS. Par exemple, une connexion RMI initiée par le client permet au serveur de faire des appels RMI au client.
RMI fonctionne-t-il sur http droit lorsque la demande est initiée sur le serveur? Je n'ai pas regardé RMI depuis des années, à cette époque, RMI ne pouvait pas faire pousser du serveur sur http.
Je ne pense pas que le tunnel HTTP RMI résoudra quoi que ce soit. Le problème est que le "serveur de clients" est derrière un pare-feu NAT et doit donc toujours initier la connexion au "serveur central" (si vous ne faites pas de transfert de port). Avec RMI, vous initiez cette connexion au «serveur central» de sorte que le «serveur central» puisse utiliser des rappels pour se connecter au «serveur des clients» (BTW RMI sur HTTP ne prend pas en charge les rappels).
+1 pour aller avec un tunnel SSH. C'est bien connu, largement disponible et pas trop difficile à configurer.
Cependant, comme vous le signiez, vous exécutez déjà SSL, le cryptage SSH est donc redondant. Au lieu de SSH, vous pouvez simplement utiliser un proxy de tunneling régulier, qui fournit le tunnel sans le cryptage. J'ai utilisé Celui-ci dans le passé et il a bien fonctionné, bien que je N'a pas chargé le test - il a été utilisé avec une poignée d'utilisateurs.
Voici un blog de quelqu'un qui a utilisé le proxy tunneling pour accéder à sa webcam de l'extérieur de son pare-feu .
C'est des choses comme ceci, c'est la raison pour laquelle les gens ont tout ceinture sur http maintenant et pourquoi certains vendeurs de matériel facturent une petite fortune pour le filtrage de la paquette de couche 7.
Il s'agit d'une quantité énorme de travail pour résoudre un problème lorsque le client a au moins trois problèmes. Outre celui que vous avez identifié, s'ils ne connaissent pas leur propre mot de passe, alors qui fait? Un administrateur qui ne fonctionne plus là-bas? C'est un problème.
Deuxièmement, s'ils ne connaissent pas le mot de passe, cela signifie qu'ils sont presque certainement loin derrière sur des mises à jour du microprogramme avec leur pare-feu.
Je pense qu'ils devraient envisager sérieusement de faire une réinitialisation de bal de bal sur leur pare-feu et de reconfigurer à partir de zéro (et à la mise à niveau du micrologiciel pendant qu'elles sont comprises).
3 oiseaux, une pierre.
+1 - Bien que j'ai fréquemment utilisé des techniques de poinçonnage des trous pour des tests ou des démos uniques rapides, pour une solution à long terme, c'est la vraie réponse ...
Dans un monde parfait oui ... mais dans un monde réel, le client n'écoute jamais et vous demande de résoudre son problème , pas le réel un. : /
Vous pouvez essayer de vous connecter à un PC / serveur et à Tunnel toutes les données via Hamachi (logiciel VPN gratuit) car cet outil vous pouvez installer et créera une connexion inverse (à l'intérieur de votre NAT à l'extérieur) afin que vous puissiez vous connecter. à celui-ci
Site: http://hamachi.cc/