Modifications pour le document Mettre en place un sous-domaine

Résumé

• Propriétés de la Page (1 modifications, 0 ajouts, 0 suppressions)
• Pièces jointes (0 modifications, 1 ajouts, 0 suppressions)
  • reverse-proxy-arch.png

Détails

Propriétés de la Page

Contenu

...	...	@@ -1,6 +1,53 @@
1	1	Lorsqu'une VM est mise en place, et que le service qu'elle doit héberger est installé, il est grand temps de rendre ce service accessible à l'extérieur du réseau d'ATILLA.
2	2
	3	+{{toc/}}
3	3
4		-Dans l'infra d'ATILLA, les connexons à un service web (members.atilla.org, learn.atilla.org, …) passent en grande majorité par Bill, qui acte comme d'un frontal web : c’est lui qui réceptionne les connexions HTTP(s) et qui les renvoie aux bons services internes par la suite. On dit également que Bill joue le rôle de //reverse-proxy//.
	5	+=Idée générale=
5	5
6		-Cette machine dispose d'un serveur Nginx, qui va avoir comme boulot de réceptionner toute requête HTTP sur un des sites d'ATILLA et de transférer cette requête à la VM qui héberge le service correspondant.
	7	+Avant de suivre les étapes de mise en place, c’est intéressant de comprendre ce qu’on va faire ^^.
	8	+
	9	+Dans l'infra d'ATILLA, les connexions à un service web (members.atilla.org, learn.atilla.org, …) passent en grande majorité par Bill, qui acte comme d'un frontal web : c’est lui qui réceptionne les connexions HTTP(s) et qui les renvoie aux bons services internes par la suite. On dit également que Bill joue le rôle de //reverse-proxy//.
	10	+
	11	+En plus de cela, Bill gère la terminaison des connexions HTTPs : c’est à dire que lorsqu’une connexion HTTPs arrive sur Bill, elle est déchiffrée, puis renvoyée en HTTP à la machine virtuelle qui correspond. Cela permet de ne pas complexifier l’installation des services, et d’avoir un endroit central ou gérer les certificats SSL.
	12	+
	13	+[[image:reverse-proxy-arch.png]]
	14	+
	15	+En pratique, Bill dispose d'un serveur Nginx, qui va avoir réceptionner toute requête HTTP(s) sur un des sites d'ATILLA et qui transfère cette requête à la VM qui héberge le service correspondant.
	16	+
	17	+=Enregistrement du sous-domaine=
	18	+
	19	+La première chose à faire est de déclarer au monde que le domaine sur lequel vous souhaitez déployer votre service existe. Il n’y a pas de convention à proprement parler sur le choix du sous-domaine. Si vous déployez un service de gestion de tickets (par exemple, GLPI), le domaine auquel ce service pourra être accessible peut très bien être ##glpi.atilla.org## ou même ##tickets.atilla.org##.
	20	+
	21	+Pour déclarer ce domaine, rendez-vous sur la machine qui sert de DNS dans l’infra (aujourd’hui, il s’agit de Bill). Deux fichiers devront être édités :
	22	+* ##/etc/bind/internal/db.atilla.org## : les entrées DNS qui sont exposées à tous les utilisateurs au sein du réseau d’ATILLA et de l’EISTI
	23	+* ##/etc/bind/external/db.atilla.org## : les entrées DNS qui sont exposées à tous les utilisateurs venant de l’extérieur
	24	+
	25	+Dans ces deux fichiers, rajoutez une ligne comme celle-ci :
	26	+
	27	+{{code language="none"}}
	28	+monservice IN CNAME bill
	29	+{{/code}}
	30	+
	31	+… puis redémarrez le serveur DNS :
	32	+
	33	+{{code language="none"}}
	34	+systemctl restart bind9
	35	+{{/code}}
	36	+
	37	+Cela aura pour effet de déclarer le sous-domaine ##monservice.atilla.org##.
	38	+
	39	+Si vous devez déclarer un service sur ##*.eistiens.net##, il faudra éditer les fichiers ##db.eistiens.net## dans les dossiers ##internal## et ##external## de la configuration du DNS.
	40	+
	41	+{{warning}}
	42	+Lorsqu’on fait une modification dans une configuration DNS, il y a toujours un temps dit de "propagation", pendant lequel l’entrée qui a été déclarée n’est pas tout de suite accessible par tout le monde. Cela peut prendre jusqu’à 24h pour qu’une entrée soit réellement accessible par tous. Cela est également vrai lorsqu’on modifie ou supprime une entrée.
	43	+{{/warning}}
	44	+
	45	+=Mise en place des certificats SSL=
	46	+
	47	+Maintenant qu’on a notre domaine, on va pouvoir récupérer des certificats SSL nous permettant de mettre en place le HTTPs sur ce domaine.
	48	+
	49	+Très rapidement, l’idée c’est de récupérer des informations (en l’ocurrence, un certificat et sa clé) nous permettant d’attester que le frontal web est bien le "propriétaire" du domaine ##monservice.atilla.org##. Lorsqu’un utilisateur se connectera en HTTPs à ce domaine, la première action qui sera effectuée par le navigateur sera de vérifier que le serveur auquel il se connecte est bien le bon, et qu’il peut lui faire confiance.
	50	+
	51	+
	52	+
	53	+=Mise en place de la configuration Nginx=

reverse-proxy-arch.png

Auteur

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.aubincleme

Taille

...	...	@@ -1,0 +1,1 @@
	1	+17.5 KB

Contenu