Bonjour,
Si je m'en tiens à la solution A1 évoquée ici :http://www.campuswiki.fr/index.php [...] Z_publique
Le serveur Internotes (web + base de données) est accessible depuis le réseau Internet via un reverse proxy situé en DMZ publique. Jusque là, c'est normal.
L'utilisateur saisit l'URL (nom de domaine) dans son navigateur pour accéder au serveur Internotes. Après résolution du nom de domaine, les paquets sont envoyés sur l'adresse IP publique de l'établissement et sur un port externe prédifini (dans notre exemple 80). Le parefeu autorise le flux entrant sur ce port et redirige les paquets vers le reverse proxy (DMZ publique vers DMZ privée). Le reverse proxy écoute sur le port 80 et établit une connexion avec le serveur Internotes. Le dialogue s'instaure et les échanges de données peuvent se poursuivre.
Maintenant, l'utilisateur est situé sur le LAN pédagogique. Il accède au serveur Internotes situé sur la DMZ privée (puisqu'une règle de pare-feu l'y autorise) en saisissant l'adresse IP privée du serveur. Tout ceci reste logique.
Dans le premier cas, l'utilisateur saisit un nom de domaine dans son navigateur et dans le deuxième cas, il est obligé de saisir une adresse IP.
Pour que cette opération reste transparente pour l'utilisateur, il devrait saisir également le nom de domaine dans son navigateur depuis un poste situé sur le LAN pédagogique.
Dans ce cas de figure, il doit sortir par le pare-feu pour re-rentrer. Si le pare-feu offre également un serveur de noms, on peut imaginer placer une correspondance IP/nom de domaine dans les entrées DNS.
Or, toute connexion initiée depuis la zone DMZ publique, la zone DMZ privée, la zone pédagogique et la zone administrative vers la zone DMZ publique est rejetée. S'agissant d'une zone d'accès publique, c'est normal que depuis le réseau interne on ne puisse pas y accéder.
On pourrait imaginer passer par un proxy externe mais ce n'est certainement pas la solution. Alors comment faire ?
Merci pour vos contributions.
