WIP interconnexion

2 files changed, 36 insertions, 1 deletions

diff --git a/src/Technique/Infra/Internet.md b/src/Technique/Infra/Internet.md
index b7ba6b4..df5a233 100644
--- a/src/Technique/Infra/Internet.md
+++ b/src/Technique/Infra/Internet.md
@@ -1,5 +1,7 @@
 ## Problèmes de connexion
 
-Actuellement les serveurs sont hébergés derrière une connexion Free qui a des problèmes en soirée.
+
+Entre janvier et mars, les serveurs hébergés derrière une connexion Free ont eu des problèmes en soirée.
+Le problème a été résolu depuis.
 
 Plus d'informations ici : https://www.aduf.org/viewtopic.php?t=286599&start=0
diff --git a/src/Technique/Jalon/Interconnexion.md b/src/Technique/Jalon/Interconnexion.md
new file mode 100644
index 0000000..578551b
--- /dev/null
+++ b/src/Technique/Jalon/Interconnexion.md
@@ -0,0 +1,33 @@
+*Ce document est une "demande de commentaire". Amendez-le, modifiez le, ajoutez vos réserves ou vos solutions alternatives librement.*
+
+Nous avons une architecture type micro-services.
+La plupart de ces services sont consommés en interne et ne sont donc pas exposés sur internet.
+Principe de minimisation de la surface d'attaque.
+Qui plus est, la communication entre ces services se fait souvent en clair.
+
+Le problème, c'est qu'en interconnectant nos infrastructures, ce qu'on veut c'est pouvoir consommer les services internes d'une infrastructure A depuis une infrastructure B. Par exemple, le serveur LDAP géré par Quentin doit être consommable par le serveur Git géré par Adrien.
+
+D'un point de vue topologie réseau, on a une première contrainte, le NAT en IPv4.
+En effet, si on a des serveurs derrière un même NAT ils auront envie de communiquer via l'IP interne.
+Mais les algos de gestion de membre (membership management) de Consul & co pourrait être empoisonné par ces IPs qui n'auraient que de valeur en interne.
+Après, on peut imaginer qu'on leur donne que l'IP externe pour communiquer, et se baser sur le NAT hairpinning de la box pour les communications intra cluster, mais ça rajoute une pression inutile sur la box : tout le traffic inter cluster sera rerouté et réécrit par la box, on se retrouve avec des traitements L3 inutiles.
+C'est particulièrement critique si on commence à faire du transfert de données (comme Garage par exemple).
+
+Cette complexité devrait évitée à mon avis. Pour cela je propose de baser nos communications de cluster via IPv6 seulement pour pouvoir adresser tout le mone directement. Je propose d'éditer un cahier des charges de la configuration minimale qu'une personne doit remplir pour s'interconnecter à l'infrastructure Deuxfleurs. Voilà une ébauche :
+
+  - Avoir une IPv6 routable sur Internet
+  - Ne pas avoir de filtrage de port (exception possible pour le port 25 en sortie...)
+  - Avoir au minimum 1Go de RAM
+  - Avoir un processeur x86
+
+Maintenant que toutes les machines de toutes les infrastructures peuvent toutes communiquer entre elles, il nous reste encore deux problèmes :
+  - Les services ne sont pas attachés à une machine, et donc pas attachés à une adresse réseau
+  - Le trafic passant en clair sur internet est supposé espionné
+
+Il nous faut donc deux propriétés qui découlent directement de ces deux besoins :
+  - Un moyen de permettre à un service C de communiquer avec un service D
+  - Chiffrer systématiquement le traffic qui part sur internet
+
+Voici quelques solutions à notre disposition :
+
+*À venir*