Mon petit setup à moi – 2/?

La suite

Suite au premier article, j’ai passé pas mal de temps à faire autre chose que ce que je voulais faire initialement, mais je n’ai pas oublié mon objectif premier. Voilà donc un petit retour sur expérience de ce que j’ai mis en place, et comment ça a été mis en place :

HAProxy et NGINX

Initialement, je voulais mettre en oeuvre ce truc :

article5-ha

Le but initial du setup de HAProxy

Finalement, en bossant un peu dessus, je me suis rendu compte de plusieurs choses. La première, c’est que CozyCloud c’est bien, mais un programme en full-js c’est lourdingue. Le choix, presque justifié, de ce langage est expliqué sur leur mailing-list, mais comme j’ai essayé de leur dire : c’est pas parce que c’est facile à développer que le résultat est bon ! On se retrouve avec un programme qui tombe un serveur, parce que le node.js qui fait tourner le site, derrière un reverse proxy NGINX, s’emballe et on ne sait pas quoi faire pour l’arrêter, en dehors de tuer les processus et les relancer … On a aussi l’aspect administration, qui implique de devoir utiliser node.js, les commandes liées à cet environnement, NGINX, et toute éventuelle couche amont … Ça finit par devenir lourdingue. J’ai aussi testé Nunux-reader, mais je n’ai pas été conquis. Je reste, pour le moment, sur feedly, en espérant trouver chaussure à mon pied côté agrégateur de liens. Bref, tout ne s’est pas passé comme prévu. Au final, j’ai mis en place ça :

Ce que j'ai mis en place, finalement

La configuration d’OwnCloud

Côté owncloud, ça se traine un peu quand on laisse la configuration standard, j’ai rajouté un peu de caching APC pour limiter le ramage :

Plus, sur les conseils de la documentation owncloud :

Pour ce qui est de la configuration de NGINX et PHP-FPM en eux même, la documentation faite par ownCloud est très bien.

La configuration du reverse proxy SSL

J’ai été agréablement surpris par NGINX concernant ses fonctionnalités de reverse proxy, il est capable de gérer une connexion SSL, sans disposer du certificat, chose très chi^W compliquée à mettre en place avec Apache.  Le vhost est très simple à réaliser en plus :

 PHPMyAdmin

C’est pas le plus intéressant, mais puisque j’en parle dans le schéma :

Côté HAProxy

Ca vaut le coup, avec HAProxy, de se pencher sur la documentation, vu les possibilités de ce programme particulièrement bon.  Je vous conseille plutôt la lecture de cette version de la doc mise en forme : http://cbonte.github.io/haproxy-dconv/configuration-1.4.html plutôt que la documentation initiale http://haproxy.1wt.eu/download/1.4/doc/configuration.txt : vous comprendrez bien pourquoi. Du coup, ça donne ça :

En gros, la conf se décompose en « global », « defaults » , « frontend », « backend », ce sont des blocks de configuration, à la manière de NGINX, la rigueur syntaxique en moins.

  • Global permet de définir les réglages système, le niveau de log, la restriction de droits, le chroot du programme, etc.
  • Defaults donne les valeurs appliquées à tous les frontends et backends
  • Frontend définie où l’on place nos oreilles
  • Backend permet de désigner les serveurs sur lesquels on va rebalancer le trafic

Après, on a tout un tas de directives contextuelles intéressante, je vous laisserai lire la doc pour ça.

Voilà en gros une décomposition de ce que j’ai fait :

Ces deux directives rebalancent tout le trafic http sur owncloud et phpmyadmin en https

idem sur la directive ci-dessus.

Du reste, on a pas grand chose de trascendant sur les ACL de frontends, en gros, quand je détecte un trafic sur le port 80, je le balance au backend qui lui correspond, comme dans cet exemple :

Après, on peut rajouter tout un tas de directives pour le poids du backend, faire tourner le trafic sur X backends pour le répartir en fonction de critères (roundrobin, least conn, etc.).
Voilà pour le moment, les services que j’ai mis en place. Après, HAProxy me permettra également de mutualiser l’usage de ports et offrira par exemple la possibilité de se connecter en VPN sur le port 80, sur la même URL qu’une page bidon.

 

Place à la plomberie

Non parce que ça a l’air gros comme ça le HAProxy et NGINX, mais c’est pas plus de 3 jours de boulot le soir entre une série et le dodo. Le plus long, ça a été de rattraper une partie de mes lacunes en réseau et surtout en gestion du réseau sous Linux.

Comme je le disais dans le premier article, j’ai fort bavé devant la conférence d’iMil s’intitulant MindFuck NetBSD. En gros, c’est chouette, pour plus de détail il faudra se référer à la conf qui est dans le lien ;-). Ce qui est dans cette conférence semble très alléchant, ça semble surtout très simple… C’est normal, c’est fait sous NetBSD ! Quand on tente de faire ça sous Debian, on se rend compte que c’est pas du tout une distribution faite pour ce genre d’usage. Je suis tombé sur un article messianique de Philippe Pepiot qui s’est amusé à faire pareil sous Linux. Pour ma part, je suis relativement débutant en réseau, surtout quand il s’agit de problématiques aussi tordues que la gestion de deux routes par défaut, deux tables de routage, le marquage de flux etc.

A noter que c’est toujours un work in progress, donc il me manque encore quelques données à intégrer… Pour le moment, j’ai trouvé une rustine à mon problème qui m’a permit de faire une plateforme fonctionnelle mais que je ne trouve pas intéressant du tout. En gros, tous les services commerciaux de VPN utilisent l’option :

Que le client peut désactiver en se servant de la directive

Ça veut dire que, dans ce cas, on ne reçoit pas les routes du serveur, et on se débrouille comme un grand. C’est ce que je voulais faire initialement, mais le problème est plus vaste que ça ! Quand on active cette option, le keepalive du VPN ne passe pas, donc la connexion tombe et est inutilisable … Je travaille encore sur ce problème. La suite de la solution est déjà trouvée, j’ai lu un peu de documentation sur iproute2 et ip rule, qui sont des programmes très intéressants en terme de gestion de flux sous Linux. En gros, le motif de configuration (une fois qu’on a résolu le problème mentionné ci-dessus est « assez simple ». Par convention, on utilisera les dénominations suivantes : tun0=client VPN IPRedator et tun1=server VPN fait main.

On crée une seconde table de routage appelée VPNcli, puis on ajoute une nouvelle route par défaut dans cette table de routage :

Ensuite, on crée une règle de traitement des flux du VPN :

Et puis le petit bout d’IPTables :

Tout ça serait sensé marcher, si j’arrivais à garder un comportement « normal » côté VPN avec la directive route-noexec … Malheureusement ça n’est pas encore le cas, le support ipredator (très sympa d’ailleurs) m’a dit que la solution à mon problème se trouverait dans un remix de ce post de leur blog. A voir pour la suite !

Ma solution, pour faire suivre mon trafic d’un VPN à l’autre pour le moment a été de faire un truc assez moche, du host routing. On rajoute, dans le fichier /etc/network/interfaces une « assurance vie » :

Donc je reste avec l’option malheureusement commentée :

Le problème de cette solution c’est que tout le trafic du serveur passe forcément par le VPN, bref, ça ne me convient pas encore, mais j’ai obtenu une mise en place du schéma initial ! C’est toujours ça de pris 🙂

Le setup à venir

Le setup en place

La prochaine étape, ça sera donc de gérer correctement les deux tables de routage, de faire du marquage de flux sur les différents VPN (option mark [marque à apposer], disponible en openvpn2.3) pour pouvoir différencier les différents trafic et leur traitement.

Encore du travail ?
– Oui mon seigneuuuuuuuur

4 thoughts on “Mon petit setup à moi – 2/?”

  1. Blitz dit :

    SAlut, je sais pas si c’est la bonne section ou si cela est la hazard de google mais au cas ou.

    J’ai intaller un Qwebirc, le probleme c’est que malgres les compiles il ne prend plus en compte les modifs sur le config.py

    Une idée ?

    1. Doo dit :

      Je suis pas un spécialiste de qweb, j’ai moi même eu un peu de mal à l’installer 🙂

      Ce que je peux te dire c’est que les devs du support de qweb sont très réactifs :
      http://qwebirc.org/installation
      si tu trouves rien, tu peux aller là :
      http://qwebirc.org/irc

  2. Vincent Gallissot dit :

    Hello Doo,
    Tu lance le cron owncloud via la crontab, ce qui est à mon sens une très bonne chose.
    Par contre faut m’expliquer la commande nice sans argument ?! Nice te permet de gérer la priorité d’un processus, du type « nice -n 20 php -f /owncloud/cron.php » si tu veux en priorité très basse. Mais sans argument, ça prend la valeur par défaut 0, qui est la même que si tu lance ta commande sans nice ?!!

    1. Doo dit :

      Ah ben oui tiens, voilà ce qui arrive quand on fait un truc sans lire un bout de man avant 🙂 merci pour l’info mon cher Vincent.
      J’ai rajouté quelques éléments à ma config ownCloud pour permettre à mon firefox sync sur mobile de tourner, au passage :

      keepalive_timeout 70;
      ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
      ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;

      et dans la partie nginx.conf :

      tcp_nopush off;
      tcp_nodelay on;

      ça permet de fluidifier le transit !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *