Administrer un serveur dédié – part 4 : Premier container

Après déjà 3 articles, nous arrivons enfin à notre premier container qui va nous permettre enfin d’héberger nos sites et rendre service, car c’est bien là le but d’un serveur rendre services aux autres.

Créer le container

lxc-create -n CT101 -t debian
Créer un container

Et voilà c’est fait, vous avez une Debian 7.4 à jour 🙂 le mot de passe est root par défaut on le changera rapidement.

Le nom de votre container c’est CT101 qu’on devra utiliser dans presque toutes les commandes de LXC.

———————————————————————————

25/05/2014 : Modification du masque réseau (/24 au lieu de rien avant)

———————————————————————————

Après l’installation le container est à l’arrêt donc démarrons le :

ln -s /var/lib/lxc/CT101/config /etc/lxc/auto/CT101
lxc-start -n CT101 -d
Démarrer un container

La première permet de démarrer automatiquement le container à chaque fois que le host démarre. Et la seconde est pour le démarrer maintenant car on veut faire mumuse avec 🙂

Nous allons nous connecter dessus pour commencer à l’utiliser

lxc-console -n CT101
Se connecter à la console du container CT101

Quand on tape cette commande la phrase « Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself » s’affiche.

Donc avec notre clavier on fait Ctrl+a puis Entrée pour voir apparaître le prompt du login et pouvoir saisir root (le mot de passe est par défaut root).

A ce moment là vous êtes connecté à votre container, vous pouvez le voir car le prompt a changé « root@CT101:~# »

Pour quitter le container et revenir au prompt du host il suffit de faire exit. On revient à ce moment là au prompt du login et on a plus qu’à saisir Ctrl+a puis q.

Le prompt change de nouveau pour nous indiquer que nous sommes sur le host.

La suite est déjà expliqué dans mon article Administrer un serveur dédié – part 2 : Le socle (Section : Premières actions et Sécuriser le service SSH)

 

Configurer le réseau sur le host

On va commander un IP Failover sur la console Online, sur la page Failover, cliquer sur le bouton « Commander des adresses IP », sélectionner celle que vous voulez en fonction de la beauté des chiffres 🙂 et valider avec le bouton « Commander d’IP Failover »

Après la commande on retour sur la page Failover pour cette fois assigner l’IP à un serveur. Les IP disponibles sont en vert dans la liste des IP Failovers. Il suffit de glisser-déposer l’IP qu’on vient d’acheter sur le serveur que l’on souhaite. Et cliquer sur le bouton « Mise à jour ». Un récapitulatif des modifications s’affichent puis cliquer sur le bouton « Mise à jour ».

Ma nouvelle adresse IP Failover est : CT101_IP_PUBLIC

Dans la configuration réseau que nous allons faire nous n’avons pas besoin d’assigner une adresse mac à notre IP car l’IP bien que publique n’est pas connecté en direct mais passe par du NAT.

On va configurer le réseau à partir du host donc déconnectez vous du container pour suivre les actions ci-dessous.

On va commencer par déclarer notre IP en tant qu’interface réseau virtuelle sur notre host. Ces quelques lignes sont à rajouter à la fin du fichier après le bridge que nous avons créé dans l’article Administrer un serveur dédié – part 3 : Virtualisation

# Failover CT101 : CT101_IP_PUBLIC
auto eth0:x
iface eth0:x inet static
        address CT101_IP_PUBLIC
        netmask 255.255.255.255
vi /etc/network/interfaces

Il faut incrémenter le numéro x à chaque nouvelle IP. Donc eth0 est mon interface principale avec mon l’IP publique de mon serveur, eth0:0 sera l’interface virtuelle de ma première IP Failover CT101_IP_PUBLIC, eth0:1 sera l’interface virtuelle de ma seconde IP Failover CT102_IP_PUBLIC, eth0:2 sera l’interface virtuelle de ma troisième IP Failover CT103_IP_PUBLIC, … enfin on est limité à 5 par serveur chez Online.

Le netmask est à 255.255.255.255 comme l’indique Online dans sa documentation sur l’IP Failover.

Malheureusement cette configuration ne sera prise en compte qu’au prochain reboot, donc pour activer notre nouvelle interface maintenant tout de suite on exécute la commande suivante :

ifconfig eth0:x CT101_IP_PUBLIC netmask 255.255.255.255
Activer l'IP failover en live

 

Configurer le réseau sur le container

On reste sur le host pour configurer le réseau du container c’est plus simple car on est déjà dessus. Mais c’est possible de le faire aussi en étant connecté sur le container.

Il s’agit donc ici de définir un réseau local entre notre container et le bridge.

Le fichier existe déjà avec l’interface local et l’interface eth0 que l’on va remplacer.

Nos modifications sont les suivantes :

  • On ne touche pas à la boucle local
  • L’interface principale passe en mode manuel (dhcp vers static), c’est à dire qu’on va spécifier les informations au lieu de laisser les serveurs DHCP faire le boulot
    • address : IP privée de notre container (j’utilise toujours 192.168.0.xxx avec xxx le même numéro que le nom de mon container donc CT101 est sur l’IP privée 192.168.0.101 c’est plus facile à retenir). Il faut rajouter le masque réseau /24 indiquant que la boucle local est sur le dernier chiffre de l’IP (ou alors /16 pour indiquer que c’est les 2 derniers chiffres à prendre en compte)
    • broadcast : La même que ci-dessus avec un 255 à la fin
    • gateway : C’est l’IP privée de mon bridge que nous avons définit dans l’article précédent (address sur l’interface br0)
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.0.101
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
vi /var/lib/lxc/CT101/rootfs/etc/network/interfaces

Il y a aussi le fichier de configuration LXC pour le container en question à modifier. Le fichier permet de configurer des tas de choses mais nous allons nous concentrer uniquement sur le réseau. Normalement les directives ci-dessous n’existent pas donc ajouter les à la fin du fichier :

# Network
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.ipv4 = 192.168.0.101/24
lxc.network.veth.pair = vethCT101
vi /var/lib/lxc/CT101/config

On indique à LXC comment traiter le réseau de notre container :

  • lxc.network.type : lxc permet d’avoir différent types de réseaux (phys, vlan, …) nous on a choisir veth c’est à dire l’utilisation d’un bridge que nous lui indiquerons dans la directive lxc.network.link
  • lxc.network.flags : On le met à « up » pour activer le réseau
  • lxc.network.link : on vient de dire à LXC de traiter le réseau avec un bridge on lui indique ici le nom de l’interface que nous avons mis dans /etc/network/interface du host
  • lxc.network.name : on utilise l’interface eth0 de notre container, celle que nous venons de configurer ci-dessus avec l’IP 192.168.0.101
  • lxc.network.ipv4 : cette fois c’est notre IP privée
  • lxc.network.veth.pair : c’est le nom que nous donnons au lien, cf l’image de notre réseau dans l’article précédent

 

Configurer le firewall

Maintenant que notre réseau est configuré nous allons devoir faire quelques mises à jours sur notre firewall :

  • NAT : c’est à dire transformer tous les flux qui sortent de notre container avec l’IP 192.168.0.101 par CT101_IP_PUBLIC et inversement
  • Autoriser les flux en fonction des services que l’on proposera dans notre container

Modifier le firewall que nous avons mis en place dans Administrer un serveur dédié – part 2 : Le socle (Mise en place d’un firewall)

Pour rajouter les 2 lignes suivantes : déclaration de l’IP publique et privée de notre container CT101.

HN_IP="xx.xx.xx.xx"

CT101_IP_PRIVATE="192.168.0.101"
CT101_IP_PUBLIC="CT101_IP_PUBLIC"

##########################
# Start the Firewall rules
##########################
vi /etc/init.d/firewall.sh

Et et un peu plus loin entre le bloc « Autoriser HTTP et HTTPS » et la fin du bloc fw_start() :

# Autoriser HTTP et HTTPS
iptables -t filter -A OUTPUT -p tcp --dport $HTTP_PORT -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport $HTTP_PORT -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport $HTTPS_PORT -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport $HTTPS_PORT -j ACCEPT

# CT101 : Configuration NAT
iptables -A FORWARD -s $CT101_IP_PRIVATE -j ACCEPT
iptables -A FORWARD -d $CT101_IP_PRIVATE -j ACCEPT
iptables -t nat -A POSTROUTING -s $CT101_IP_PRIVATE -j SNAT --to $CT101_IP_PUBLIC
# CT101 : Autoriser HTTP
iptables -t nat -I PREROUTING -p tcp -d $CT101_IP_PUBLIC --dport $HTTP_PORT -j DNAT --to $CT101_IP_PRIVATE
iptables -I FORWARD -p tcp -d $CT101_IP_PRIVATE --dport $HTTP_PORT
# CT101 : Autoriser SSH
iptables -t nat -I PREROUTING -p tcp -d $CT101_IP_PUBLIC --dport $SSH_PORT -j DNAT --to $CT101_IP_PRIVATE
iptables -I FORWARD -p tcp -d $CT101_IP_PRIVATE --dport $SSH_PORT

}
fw_stop(){
vi /etc/init.d/firewall.sh

Il reste à relancer le firewall pour prise en compte des nouvelles règles :

firewall.sh restart
Relancer le firewall

Et relancer le container pour prendre en compte les changements réseaux et de configuration LXC :

lxc-stop -n CT101
lxc-list
lxc-start -n CT101 -d
Relancer le container

Et voilà, vous avez un container qui a accès à internet et qui peut héberger un serveur web par exemple 🙂

Ha on me dit que c’est dans le prochain article donc je vous laisse.

Vous pouvez répéter ce tuto autant de fois que vous voulez de container.

 

Un commentaire

  1. Bonsoir,
    Je suis entrain de suivre vos tutoriels pour mettre en place des containers LXC.

    J’ai crée le premier container et je voulais me connecter en SSH (pas besoin de HTTP) directement sur le container. J’ai donc mis dans firewall.sh :
    # CT101 : Configuration NAT
    iptables -A FORWARD -s $CT101_IP_PRIVATE -j ACCEPT
    iptables -A FORWARD -d $CT101_IP_PRIVATE -j ACCEPT
    iptables -t nat -A POSTROUTING -s $CT101_IP_PRIVATE -j SNAT –to $CT101_IP_PUBLIC
    # CT101 : Autoriser SSH
    iptables -t nat -I PREROUTING -p tcp -d $CT101_IP_PUBLIC –dport $SSH_PORT -j DNAT –to $CT101_IP_PRIVATE
    iptables -I FORWARD -p tcp -d $CT101_IP_PRIVATE –dport $SSH_PORT

    Et en haut :
    CT101_IP_PRIVATE= »192.168.0.101″
    CT101_IP_PUBLIC= »xxx.xxx.xxx.xxx »

    Mais lorsque j’essaie de me connecter en SSH sur xxx.xxx.xxx.xxx j’obtiens un timeout comme si le nat n’était pas réaliser. Ai-je oublié quelque chose (j’ai redémarré la machine etc mais rien n’y fait) ?

    Reply
    • Bonsoir,

      Et désolé pour la réponse tardive. J’espère que tu as trouvés la solution tout seul comme un grand 🙂

      Normalement il n’y a rien à faire sur le réseau ou le firewall puisque les routes sont déjà ouvertes. Il faut vérifier le port SSH est ce le même entre le firewall et la conf SS du container ?

      Après le problème que tu vois avoir c’est l’erreur suivante : This service allows sftp connections only.
      Car par défaut je ne laisse pas ni le compte root se connecter au ssh ni les comptes web. Il faudra changer la conf SSH de ton container comme pour le host qui lui l’autorise.

      Reply
      • Bonsoir,

        réponse un peu tardive pour ma part. Je n’ai toujours pas trouvé la solution. Sans prerouting, je tombe bien sur mon serveur dédié, cependant dès qu’il est activé, sous putty j’obtiens un timeout que ce soit en root (login avec root autorisé) ou avec l’utilisateur dédié (login avec root interdit) pour ssh.
        Avec un ping je tombe bien sur le bon serveur aussi ! La configuration de firewall est celle écrite au dessus !

        Bonne soirée !

        Reply
        • Bonsoir,

          Moi aussi une réponse tardive. Il faut vérifier le chemin complet jusqu’à ton container.
          * Ton IP public doit être correctement configuré pour arriver sur ton serveur déjà
          * Si ton IP arrive sur le serveur elle va être routé par le firewall qui doit avoir les bonnes lignes
          * Ensuite il faut vérifier la configuration de ton serveur SSH (le port doit etre le meme que celui configuré dans le firewall, IP qui est écoutée)

          Et surtout ne pas faire la configuration sftp que j’ai donné car elle est pour un autre usage. As tu configuré le sftp ?

          Bonne continuation

          Reply
  2. Bonjour ! J’ai réussi à manipuler LXC ainsi que les containers grâce à des vidéos sur ma pub et je dois dire que votre tutoriel est très complet. Merci pour votre partage.

    Reply

Leave a Comment.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.