Analyse du prototype
Pour mettre en place les différents services, nous avons décidé de tout mettre sur un seul vps, celui de Cyril Grandjean.
D'une part cela permet d'avoir une meilleure sécurité car nous n’avons pas besoin de firewall entre les différent vps.
D'autres part tout est regroupé en un seul point donc il est plus facile de faire le maintien du serveur.
Cela permet aussi de faire des économies car nous n'avons besoin que d'un seul vps.
Finalement cela permet de pouvoir lancer et paramétrer les différents services en une seule fois.
Les inconvénients de cette architecture sont que si le serveur contenant le dns interne et externe venait à tomber à cause d'une panne, d'une attaque. Les deux services seraient alors indisponibles. De plus, avec cette configuration le DNS interne est plus exposé.
Chaque service que nous utiliserons auront leurs propres container docker dédié excepté pour le DNS externe et le DNS externe qui seront rassembler dans le même conteneur.
192.168.10.0/24
- BDD: 192.168.10.2
192.168.30.0/24
- DNS: 192.168.30.2
- WEB: 192.168.30.3
- VOIP: 192.168.30.4
- Mail: 192.168.30.5
192.168.0.0/24
- Directeur: 192.168.0.2
- Commerciaux 1: 192.168.0.34
- Commerciaux 2: 192.168.0.35
- Secrétaire: 192.168.0.66
- Hangar: 192.168.0.99
- Atelier: 192.168.0.98
- Comptable 1: 192.168.0.130
- Comptable 2: 192.168.0.131
Le problème de notre prototype est qu'il est simulé, donc si nous voulons le configurer pour une entreprise réelle, nous devons faire en sorte qu'il soit le plus semblable possible à ce que nous aurions dû faire dans le monde réel ce qui permettrait de pouvoir L’implémenter sans avoir à modifier trop de choses. Même si il est pratiquement sûr que nous allons devoir appliquer des modifications.
En simulation, nous ne sommes pas autant confronté à des incompatibilités matérielles, des produits ne fonctionnant pas comme prévu,...
En d’autres mots, nous allons devoir faire en sorte que les services soient le plus indépendant possible pour qu'on puisse les implémenter facilement dans le réseau réel. De plus, tout ce que nous simulons comme par exemple les postes de travail, vont devoir être enlevé et remplacé par des postes réels.
Bien évidemment, quand nous passerons du projet simulé au projet réel nous risquons bien évidemment d'avoir des modifications à faire comme des incompatibilités matérielles ou des modifications demandées par le client car quand nous simulons notre réseau nous ne pouvons pas penser à tout et certains besoins pourraient être oubliés pour les personnes allant utiliser le réseau donc nous allons devoir ajouter, modifier ou même retirer certaines fonctionnalités.
Certaines ips dans les configurations pourraient aussi devoir être modifiées car tous les réseaux n'ont pas les mêmes besoins en terme de réseau.
Concrètement, comme l'entreprise n'utilise pas docker, nous allons devoir
- pour les employés, implémenter les commandes utiles directement pour les postes utilisateurs et plus dans un container docker, il y aura aussi plus d'ip pour les différents postes car un poste utilisateur comme par exemple commerciaux contiendra plusieurs employés
- pour les serveurs, nous allons devoir remplacer les containers docker en serveur réel
Pour notre architecture du VPS, nous avons décidé d'avoir une partie où les services seront exposés donc susceptibles d'être accédés par internet reprenant le DNS , le voip, le mail et les différent web à côté de cela nous avons une zone non exposée donc qui n'est pas accessible à internet comprenant notre base de données. Pour séparer les zones nous utilisons un firewall et c'est lui qui indique si oui ou non on peut accéder au serveur, et finalement nous avons une partie reprenant les différents employés que nous simulons.