Différences

Ci-dessous, les différences entre deux révisions de la page.

--- guide:installation_serveur_agregation_connexion_2014 [2014/06/09 21:58] – vivi
+++ guide:installation_serveur_agregation_connexion_2014 [2021/04/18 22:24] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
+====== Installation serveurs agrégation connexion 2014 ======
+Mis en place en 2014.
-**Installation serveurs agrégation connexion 2014**
 ===== Introduction =====
-L'objectif de ce guide est la mise en place de serveurs permettant l'agrégation de connexions. Dans mon cas ce sera une connexion ADSL avec une connexion 4G. Elle suppose l'installation de **deux serveurs un chez moi et un sur le net**. Entre ces deux serveurs nous construirons deux liens (avec tunnel VPN) un via la 4G et un via l'ADSL.
+L'objectif de ce guide est la mise en place de serveurs permettant l'agrégation de connexions. Dans mon cas ce sera une connexion ADSL avec une connexion 4G. Elle suppose l'installation de **un serveur un chez moi et un sur le net**. Entre ces deux serveurs nous construirons deux liens (avec tunnel VPN) un via la 4G et un via l'ADSL.
 Tout sera connecté au serveur chez moi qui fournira une connexion internet unifiée. Même combat côté internet, mon serveur installé servira de point de sortie unifié vers le net.
-Concernant la connexion ADSL, j'utilise la box normale de mon FAI. Concernant la connexion 4G, je prends un forfait internet qui va bien avec la carte SIM only. J'utilise ensuite [[http://www.ldlc.com/fiche/PB00134946.html|ce modem 4G]]. Ca n'est pas obligatoire, c'est un choix perso. Je suppose que le modem 4G fourni avec le forfait par certains opérateurs de mobile.
+Concernant la connexion ADSL, j'utilise la box normale de mon FAI. Concernant la connexion 4G, je prends un forfait internet qui va bien avec la carte SIM only. J'utilise ensuite [[http://www.ldlc.com/fiche/PB00134946.html|ce modem 4G]]. Ca n'est pas obligatoire, c'est un choix perso. Je suppose que le modem 4G fourni avec le forfait par certains opérateurs de mobile peut aller également.
 **Vocabulaire :**
-    * Je parlerai de __**serveur maison**__//(ou maison en abrégé)//      pour celui chez moi qui fera offcie de routeur / gateway pour mon bonding
+    * Je parlerai de __**serveur maison**__//(ou maison en abrégé)//    pour celui chez moi qui fera offcie de routeur / gateway pour mon bonding
-    * Je parlerai de __**serveur dédié**__// (ou dédié en abrégé) //     pour le serveur chez online.net qui me sert de sortie sur le réseau public internet (via le réseau online.net)
+    * Je parlerai de __**serveur dédié**__// (ou dédié en abrégé) //      pour le serveur chez online.net qui me sert de sortie sur le réseau public internet (via le réseau online.net)
 ====== 1. Installation du serveur dédié ======
 ===== 1.1. Installation initiale du serveur =====
@@ Ligne 28: / Ligne 35: @@
 **TODO SCREENS**
 ===== 1.2. Préparation de la configuration =====
-Pour cette recette, il vous faudra utiliser les **3 ingrédients**      suivants :
+Pour cette recette, il vous faudra utiliser les **3 ingrédients**    suivants :
     * OpenVPN //(voir // //[[https://help.ubuntu.com/community/OpenVPN|ce lien]]//// et la // //[[http://openvpn.net/index.php/open-source/documentation/manuals/65-openvpn-20x-manpage.html|manpage]]//// contient pas mal d'infos également)//
     * Le système de bridging //(voir // //[[https://help.ubuntu.com/community/NetworkConnectionBridge|ce lien]]////)//
     * Le module de bonding //(voir // //[[https://help.ubuntu.com/community/UbuntuBonding|ce lien]]//// et la // //[[https://www.kernel.org/doc/Documentation/networking/bonding.txt|doc officielle]]////)//
 ==== 1.2.1. Installation d'OpenVPN ====
@@ Ligne 43: / Ligne 54: @@
 </code>
-Nous utiliserons OpenVPN pour monter **2 tunnels VPN**     l'un avec notre première connexion internet (la 4G) pour moi et l'autre avec notre seconde connexion internet (l'ADSL pour moi).
+Nous utiliserons OpenVPN pour monter **2 tunnels VPN**      l'un avec notre première connexion internet (la 4G) pour moi et l'autre avec notre seconde connexion internet (l'ADSL pour moi).
 ==== 1.2.2. Installation du système de bridging ====
@@ Ligne 50: / Ligne 63: @@
 sudo apt-get install bridge-utils
 </code>
 ==== 1.2.3. Activation du module de bonding ====
@@ Ligne 71: / Ligne 86: @@
 rtc
 bonding
+dummy
 </code>
@@ Ligne 78: / Ligne 94: @@
 sudo modprobe bonding
 </code>
 ==== 1.2.4. Activation de l'ip forwarding ====
@@ Ligne 92: / Ligne 110: @@
 net.ipv4.ip_forward=1
 </code>
+==== 1.2.6. Activation du NAT ====
+C'est le nat qui va permettre le routage final.
+Une bonne idée est de s'appuyer sur cette méthode : https://help.ubuntu.com/community/Router
+Ce qui va donner chez moi ce genre de chose:
+<code bash>
+nano nat.sh
+</code>
+<code bash>
+#
+# Configure here your interfaces
+#
+EXTIF="bond0"
+INTIF="br0"
+#
+# Commands path
+#
+DEPMOD=/sbin/depmod
+MODPROBE=/sbin/modprobe
+#
+# General information
+#
+echo "[INFO][NAT] Loading NAT configuration..."
+echo "[INFO][NAT] External Interface:  $EXTIF"
+echo "[INFO][NAT] Internal Interface:  $INTIF"
+#
+# Checking requested linux kernel modules
+#
+echo "[INFO][NAT] Verifying that all kernel modules are ok"
+$DEPMOD -a
+echo "[INFO][NAT] Loading module ip_tables..."
+$MODPROBE ip_tables
+echo "[INFO][NAT] Loading module nf_conntrack..."
+$MODPROBE nf_conntrack
+echo "[INFO][NAT] Loading module nf_conntrack_ftp..."
+$MODPROBE nf_conntrack_ftp
+echo "[INFO][NAT] Loading module nf_conntrack_irc..."
+$MODPROBE nf_conntrack_irc
+echo "[INFO][NAT] Loading module iptable_nat..."
+$MODPROBE iptable_nat
+echo "[INFO][NAT] Loading module nf_nat_ftp..."
+$MODPROBE nf_nat_ftp
+#
+# Enabling ip forwarding
+#
+echo "[INFO][NAT] Enabling forwarding..."
+echo "1" > /proc/sys/net/ipv4/ip_forward
+echo "[INFO][NAT] Enabling DynamicAddr..."
+echo "1" > /proc/sys/net/ipv4/ip_dynaddr
+#
+# Setting iptables rules
+#
+echo "[INFO][NAT] Clearing any existing rules and setting default policy..."
+iptables-restore <<-EOF
+*nat
+-A POSTROUTING -o "$EXTIF" -j MASQUERADE
+COMMIT
+*filter
+:INPUT ACCEPT [0:0]
+:FORWARD DROP [0:0]
+:OUTPUT ACCEPT [0:0]
+-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
+-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
+-A FORWARD -j LOG
+COMMIT
+EOF
+echo "[INFO][NAT] NAT configuration loaded !"
+</code>
+After configuring the 2 variables, save the script below as nat.sh and make it executable by doing
+<code bash>
+chmod a+x nat.sh
+</code>
+Now, test the script by running as root
+<code bash>
+sudo sh nat.sh
+</code>
+Investigate the messages from the console output to see if any error happened. If everything looks fine, use another host in the internal network to test if it can access the external network (presumably the Internet). A quick way to test is pinging Google public DNS from the console.
+<code bash>
+ping -c 3 -W 10 8.8.8.8
+</code>
+If ping responds, make our new script bootable so we don't have to run the script every time we restart.
+<code bash>
+sudo mv nat.sh /etc/init.d/
+</code>
+See : https://askubuntu.com/questions/765120/after-upgrade-to-16-04-lts-rc-local-not-executing-command
+<code bash>
+sudo systemctl enable rc-local.service
+</code>
+<code bash>
+sudo nano /etc/rc.local
+</code>
+<code>
+# Executing nat script
+/etc/init.d/nat.sh
+</code>
+As a final test, restart your computer and test to see if you still have the same functionality. If so then congratulations! If not then make sure you followed the above correctly so the script is bootable.
+Mais pour mémoire le point important est celui-ci:
+<code bash>
+iptables -A POSTROUTING -t nat -j MASQUERADE
+</code>
+Pour ne pas perdre le NAT, lancer cette commande à chaque boot par exemple en l'incluant dans les fichiers de démarrage (déjà pris en compte dans le lien de référence ci dessus).
 ==== 1.2.5. Récupérer des ip / mac online.net ====
@@ Ligne 97: / Ligne 244: @@
 Dans le montage choisi, j'utiliserai un montage vpn en mode [[http://openvpn.net/index.php/open-source/documentation/miscellaneous/ethernet-bridging.html|bridge]]. Résumé très vulgairement, l'idée est de monter mon serveur online, mon serveur à la maison sur le réseau online avec des ip publiques. Le montage sous forme de bridge permet cela en reliant ces serveurs avec une sorte de switch virtuel tant avec le mode bridge d'OpenVPN que le système de bridge linux.
-Evidemment, on ne peut pas aller sur le réseau d'un hébergeur avec l'ip de son choix, il faut donc passer par l'étape d'obtention d'[[http://documentation.online.net/fr/serveur-dedie/reseau/ip-failover|ip]][[http://documentation.online.net/fr/serveur-dedie/reseau/ip-failover| failover]].
+Evidemment, on ne peut pas aller sur le réseau d'un hébergeur avec l'ip de son choix, il faut donc passer par l'étape d'obtention d'[[http://documentation.online.net/fr/serveur-dedie/reseau/ip-failover|ip]] failover.
 **Au final pour ma configuration il faut 3 ipfailover :**
@@ Ligne 110: / Ligne 257: @@
 Dernier détail important, comme online.net (et probablement n'importe quel hébergeur de dédié d'ailleurs) surveille son réseau pour éviter que n'importe quel équipement cause dessus, **//il faut également prendre une mac online.net (j'ai choisi la mac pour KVM bien que je pense que cela ne fasse pas de différence) avec l'ip failover associé au serveur maison//**. Autrement, vous vous ferez couper le réseau puis que vous aurez votre serveur maison avec une adresse mac maison (non connue de online.net) qui va trainer sur leur réseau…
 ===== 1.3. Configurer OpenVPN =====
 ==== 1.3.1. Introduction ====
@@ Ligne 118: / Ligne 269: @@
 __**Note importante :**__ il est essentiel de comprendre que l'ordre de certaines opération, notamment au démarrage de la machine pourra changer la façon de préparer la configuration. Par exemple si OpenVPN démarre avant ou après le réseau ou inversement, on ne passera pas les commandes de la même manière car il y a un ordre logique. Par exemple, on utilise pas une interface VPN si elle n'est pas un minimum montée… Bref, j'indique ici **une technique qui peut ne fonctionner que dans le contexte ubuntu 14.04**. Il y a une manière de faire qui n'est pas due au hasard bien qu'il existe sans doute d'autres (meilleures peut-être) manières. J'ai juste choisi en fonction de ce que j'ai trouvé sur le net et ce que je trouvais le plus simple / pratique à gérer.
 ==== 1.3.2. Préparation de la configuration ====
@@ Ligne 173: / Ligne 326: @@
 </code>
-Le fichier de configuration du premier serveur ressemble à cela chez moi //(les parties à adapter à votre configuration commencent par TO_CHANGE)//    :
+Le fichier de configuration du premier serveur ressemble à cela chez moi //(les parties à adapter à votre configuration commencent par TO_CHANGE)//     :
 <code>
@@ Ligne 227: / Ligne 380: @@
 Eléments importants :
-    * **keepalive 1 5**     permet de régler le maintient d'activité sur le VPN. S'il n'y a pas de traffic, un ping sera émis toutes les 1 sec et s'il n'y a pas du tout de traffic au bout de 5 sec, le tunnel est considéré comme perdu et cherchera à redémarrer.
+    * **keepalive 1 5**      permet de régler le maintient d'activité sur le VPN. S'il n'y a pas de traffic, un ping sera émis toutes les 1 sec et s'il n'y a pas du tout de traffic au bout de 5 sec, le tunnel est considéré comme perdu et cherchera à redémarrer.
-    * **up-restart**     permet de faire en sorte que les "hooks" comme down (et les scripts associés down-link.sh) soient appelés en cas de restart de tunnel (c'est à dire en cas de défaillance) et non pas juste une fois à l'arrêt d'OpenVPN.
+    * **up-restart**      permet de faire en sorte que les "hooks" comme down (et les scripts associés down-link.sh) soient appelés en cas de restart de tunnel (c'est à dire en cas de défaillance) et non pas juste une fois à l'arrêt d'OpenVPN.
-    * **down **    (combiné a up-restart) permet d'appeler un script quand le tunnel tombe
+    * **down **     (combiné a up-restart) permet d'appeler un script quand le tunnel tombe
-    * **ipchange **    permet d'appeler un script quand le tunnel est remonté
+    * **ipchange **     permet d'appeler un script quand le tunnel est remonté
 **Pour le deuxième serveur on part du premier :**
@@ Ligne 242: / Ligne 395: @@
     * TO_CHANGE_PORT_1 => TO_CHANGE_PORT_2
     * tap1 => tap2
 ==== 1.3.4. up-restart down et ipchange sont dans un bateau ====
@@ Ligne 247: / Ligne 402: @@
 Un petit aparté sur ces éléments et les scripts qui vont avec. C'est un truc très très con que j'ai du fouiller et bricoler au fur et a mesure.
-En fait, les interfaces montées avec OpenVPN (ici tap1 et tap2) ne sont pas mises à jour correctement du point de vue link. C'est à dire que **quand le tunnel VPN tombe, l'interface associée (mettons tap1 pour le tunnel 1) reste toujours up !!!**  Ce qui est une connerie fondamentale puisque les outils tels que le bonding se servent de cet état pour déterminer si le traffic peut être envoyé sur l'interface...
+En fait, les interfaces montées avec OpenVPN (ici tap1 et tap2) ne sont pas mises à jour correctement du point de vue link. C'est à dire que **quand le tunnel VPN tombe, l'interface associée (mettons tap1 pour le tunnel 1) reste toujours up !!!**   Ce qui est une connerie fondamentale puisque les outils tels que le bonding se servent de cet état pour déterminer si le traffic peut être envoyé sur l'interface…
-Bref, par défaut vous allez monter votre bonding avec 2 liens en répartition de charge et si un tunnel tombe, votre bonding continuera à envoyer du traffic sur le lien mort ce qui vous fera une perte de 50% des paquets. Bref, l'intérêt du bonding devient vraiment minable...
+Bref, par défaut vous allez monter votre bonding avec 2 liens en répartition de charge et si un tunnel tombe, votre bonding continuera à envoyer du traffic sur le lien mort ce qui vous fera une perte de 50% des paquets. Bref, l'intérêt du bonding devient vraiment minable…
 Donc voilà, avec les petites ruses précédentes, je m'arrange pour détecter quand le tunnel tombe / remonte et mettre a jour manuellement l'état du lien afin qu'il puisse être correctement mis à jour up ou down.