Zwindler's Reflection https://blog.zwindler.fr Ma vie parmi les lol-cats || je mine des bitcoins dans mon dressing Thu, 02 Apr 2020 12:14:57 +0000 fr-FR hourly 1 https://wordpress.org/?v=5.4 https://blog.zwindler.fr/wp-content/uploads/2017/03/nyanonimous_rond-150x150.png Zwindler's Reflection https://blog.zwindler.fr 32 32 126029280 Épidémie de ruptures de périodes d’essai https://blog.zwindler.fr/2020/03/27/epidemie-de-ruptures-de-periodes-dessai/ https://blog.zwindler.fr/2020/03/27/epidemie-de-ruptures-de-periodes-dessai/#comments Fri, 27 Mar 2020 07:45:00 +0000 https://blog.zwindler.fr/?p=5631 En ce contexte de confinement, les ruptures de période d'essai suite au COVID 19 se multiplient. Pour autant, c'est illégal ! Je vous explique tout ici.

Cet article Épidémie de ruptures de périodes d’essai est apparu en premier sur Zwindler's Reflection.

]]>

COVID 19 + période d’essai = <3

Une fois de plus, je chamboule un peu l’ordre de mes publications relativement à l’actualité virale (aka. COVID 19). Après l’autohébergement d’un système de visioconférence opensource (Jitsi), aujourd’hui, on va parler de rupture du contrat de travail, dans le cadre particulier de la période d’essai.

Comme d’habitude pour tous les autres sujets dans cette catégorie Droit du travail, je rappelle que je ne suis pas juriste. Le droit du travail est un de mes hobbies et je fais un peu de veille là dessus.

Pour ceux qui ne veulent pas y passer du temps, je vous propose de vous résumer tout ça dans un seul et même article. Je commencerai par une petite remise en contexte, ensuite, je vous expliquerai les différents textes de loi ainsi que les jurisprudences et enfin je listerai tous les liens utiles en fin d’article.

Pourquoi parler de ça maintenant ?

Il ne vous aura pas échappé qu’il ne fait pas bon être indépendant ce mois ci (même dans l’informatique). Sur Twitter, je ne compte plus les messages du type "mon client vient de plaquer tous ses prestas, je suis en recherche d’une nouvelle mission". C’est un des aléas qu’on accepte lorsqu’on devient indépendant.

En revanche, là où c’est carrément plus craignosse, c’est quand des #ESN #BestPlaceToWork #BabyFoot #FreeBeerFriday, dans cette période peu faste en prospects, profitent des périodes d’essai pour se délester d’un peu de masse salariale a peu de frais.

Dans le microcosme Bordelais, où tout le monde dans l’IT se connaît, rien que cette semaine j’ai eu deux exemples en deux jours. L’un, consultant, était fortement incité à prendre des congés sans soldes sous peine de se faire virer (ce qui s’est finalement passé, dés le premier jour). L’autre a préféré céder et a accepté de signer un avenant pour décaler son embauche à juin (sans chômage ni rien, of course).

Et bien sûr, je ne vous parle pas de cas de PMEs qui risquent de couler du jour au lendemain si le gérant ne prend pas ce genre de mesures hein ? On parle de SSII avec les reins solides.

Au cas où c’était pas encore clair, ça me plaît pas beaucoup

Et au delà de Bordeaux ?

Vous vous en doutez, ça ne se limite évidemment pas à Bordeaux. La première personne que j’ai vu en parler c’est Shirley Almosni Chiche. Pour ceux qui ne la connaissent pas, je vous invite à aller voir son Twitter (ou LinkedIn), elle réinvente avec humour le recrutement dans l’IT.

Dans les premiers jours du confinement, elle a commencé à recevoir une pluie de message du type : "toutes les personnes en période d’essai ont été virée". A tel point qu’elle a commencé à en parler ouvertement, sous le hashtag #coronaviré et créé un fichier "d’entraide recrutement" où les entreprises qui recherchent même en cette période déposent leurs annonces.

https://twitter.com/shirleyalmosni/status/1240569333140590592?s=20

La presse commence à parler du phénomène : un journaliste de l’Obs a fait un article là dessus (attention, paywall).

Et alors que je pensais que ça ne pouvait pas être pire, il commence même à y avoir des mentions de rupture de 200 périodes d’essai d’un coup dans une ESN de 2700 personnes. C’est tellement énorme que j’ai du mal à y croire et j’espère sincèrement que c’est faux.

De toute façon on le saura vite.

Mais la période d’essai, c’est quoi finalement ?

OK, on a fait le constat. Maintenant on peut rentrer dans le vif du sujet.

Vous l’aurez compris, mon plaisir dans la vie, c’est de citer Légifrance (Article L1221-25). Mais il se trouve que sur service-public.fr, il existe des FAQ plutôt bien faites et bien plus digestes pour les gens normaux :

La période d’essai permet de s’assurer que le salarié embauché convient au poste sur lequel il a été recruté. Elle permet également au salarié d’apprécier si les fonctions occupées lui conviennent

Cette phrase a l’avantage d’être très claire. La période d’essai, c’est pour que l’employeur s’assure que le salarié correspond au poste (et accessoirement au salarié de savoir si le poste lui convient).

Elle a une durée limitée, potentiellement reconductible (avec un délai de prévenance et si le contrat de travail le prévoit). Elle peut surtout être rompue facilement, ce qui a l’avantage, pour l’employeur et pour le salarié de ne pas passer par la case licenciement/démission (et donc éviter indemnités pour l’un, et long préavis pour l’autre). Une fois de plus, moyennant un délai de prévenance qui dépend de la durée pendant laquelle le salarié a été présent dans l’entreprise.

Rupture de la période d’essai

On a souvent tendance (moi le premier) à dire aux gens qui se voient notifier la rupture de leur période d’essai qu’ils ne pourront rien faire. C’est bien évidemment juridiquement inexact. Même si dans les fait, ça va souvent revenir à ça, mais on y reviendra.

Le compte Twitter @AuPalais (a priori tenu par une avocate) résume dans un thread en quoi ce n’est pas si simple :

https://twitter.com/Tux_Ben/status/1239925977595236352?s=20

Grosso modo, si vous vous retrouvez dans le cas des "coronavirés", voici ce que vous devez vérifier :

  • La clause de période d’essai existe-t-elle dans le contrat de travail que vous avez signé (et est valide juridiquement parlant) ?
  • Les délais de prévenance ont-ils été respectés ?
  • Est ce que la période d’essai était justifiée ?
  • Est ce que la période d’essai n’est détournée de sa finalité ?

Il existe déjà une jurisprudence très riche sur des cas de ruptures lors de la période d’essai, notamment pour des cas de discriminations. Le coronavirus n’est donc qu’une nouvelle fausse excuse pour réduire la voilure.

Contester la rupture de sa période d’essai

Dans les faits, AuPalais a bien techniquement raison quand elle dit qu’une rupture de période d’essai abusive est bien évidement interdite et contestable. Mais que peux faire le salarié injustement remercié ?

D’abord, on peut commencer par un courrier recommandé pour contester la rupture de la période d’essai. Comme dit JC Dusse, sur un malentendu… Je vous met en fin d’article un modèle partagé par Shirley (encore elle ;-p).

Comme tout litige de ce genre, on va probablement surtout devoir saisir la juridiction prud’homale (les Prud’hommes) pour rupture abusive de sa période d’essai. Le but sera de prouver que la rupture n’était pas liée aux capacités du salarié. Simplement un moyen pour l’employeur de se débarrasser de la personne.

Parfois, ça sera relativement facile à prouver (preuves écrites, période d’essai rompue avant même que le salarié n’ait commencé à travailler à cause du COVID, …).

Mais dans tous les cas, l’issue sera toujours incertaine. Et quand bien même les prud’hommes donnent raison au salarié, la bataille n’est pas terminée pour autant puisque l’employeur peut se pourvoir en cassation. Un contentieux peut alors durer des années.

Pour quel effet ?

On voit bien que contester la rupture de sa période d’essai est hasardeux et sera probablement coûteux en temps comme en argent pour le salarié (là où l’entreprise a probablement déjà un conseil juridique à disposition).

Cependant, ça peut valoir le coup si le gain à l’issue du contentieux en vaut la chandelle, non ?

Spoiler alert : non.

Imaginons qu’après une longue bataille juridique, le salarié finisse par gagner. La rupture de la période d’essai devient donc un licenciement (par exemple pour raisons économiques ou sans cause réelle et sérieuse) et ouvre droit d’une part à des indemnités de licenciement, et d’autre part potentiellement à des indemnités de dommages-intérêts.

Commençons par les indemnités prud’homales.

Vous vous souvenez peut être de la loi Macron de 2017 avant qu’il ne soit président.

A l’époque, le patronat (surtout le Medef) écumait les plateaux TV/radio pour expliquer que si les dirigeants d’entreprises n’embauchaient pas, c’est qu’ils avaient peur des indemnités en cas de contentieux avec des salariés.

Si le Medef ne martelait pas depuis des années qu’aller aux prud’hommes, c’est risquer de perdre sa boîte, alors que ce n’est quand même pas ce qui se passe dans l’immense majorité des cas, les dirigeants ne seraient pas dans cette illusion.

Philippe Louis, représentant de la CFTC dans https://lentreprise.lexpress.fr/rh-management/droit-travail/plafonnement-des-indemnites-prud-hommes-on-a-monte-ce-sujet-en-epingle_1911319.html

Depuis cette loi, les indemnités sont donc plafonnées (minima/maxima) en fonction de votre temps de présence dans l’entreprise. Vous pouvez retrouver une autre fiche sur service-public.fr à ce sujet.

https://www.service-public.fr/particuliers/vosdroits/F33999

Ainsi, dans le cas d’une période d’essai, vous aurez nécessairement moins d’un an d’ancienneté (6-7 mois grand maximum). Vous aurez donc droit à une indemnité plafonnée à 1 mois de salaire. Et encore, si vous gagnez !

A noter : le plafond est de 6 mois dans le cadre de cas de discrimination, harcèlement, etc. Enfin c’est pas foufou non plus quand on vient de se faire harceler…

Et si vous touchez des dommages-intérêts qui vont au-delà des indemnités légales dont on vient de parler (on parlera alors d’indemnités supra-légales), sachez que ces sommes seront de toute façon déduites de vos allocations pôle emploi (via l’extension du délai de carence).

Elle est pas belle la vie ?

Et le chômage justement ?

Je vais partir du cas que je connais le mieux : l’IT.

Imaginons un développeur salarié qui vient de changer de boite. Il a donc démissionné, et commence dans la nouvelle.

Coronaviré, son nouvel employeur met fin à sa période d’essai, officiellement parce qu’il ne fait pas le taf. Officieusement pour réduire la voilure en cette période de confinement où il va être difficile de lui trouver une mission chez un client.

Si notre dev a cotisé 3 ans consécutivement juste avant, pas de problèmes. Au delà du fait qu’il vient de se faire jeter comme une vieille chaussette, il aura droit à l’allocation Pôle Emploi.

En revanche, s’il n’a pas cotisé assez (ou pas 3 années consécutives, ce qui peut arriver vu le turnover dans l’informatique), il est nécessaire d’avoir travaillé au moins 65 jours dans votre nouvel emploi pour y prétendre (Décret de 2019 sur l’assurance chômage).

https://twitter.com/tifok_/status/1242738453638516738

Tout ceci est expliqué en détail dans cet article de cadremploi.fr ou sur Légifrance.

Récapitulons

Rompre les périodes d’essai pour cause (affichée ou non) de Coronavirus est illégal.

Le faire peut conduire l’employeur a être condamné à verser des indemnités au salarié.

Cependant, encore faudra-t-il que le salarié :

  • engage un recours aux prud’hommes
  • gagne
  • éventuellement, gagne aussi en cassation (~2-3 ans de procédure)
  • obtienne une indemnité

Pour au final recevoir au mieux un mois de salaire (et tout ce qui sera au dessus sera déduit du chômage via le délai de carence).

Et enfin, si vous n’aviez pas cotisé 3 ans de suite, il y a de grandes chances pour que vous n’ayez pas le chômage non plus (délai de carence de minimum 4 mois).

Je sais pas ce que vous en pensez, mais moi j’ai l’impression que le salarié (seul) à tout à perdre et surtout rien à y gagner à aller aux prud’hommes. La solution est peut être que les salariés soient solidaires dans ces périodes et tentent de faire valoir leurs droits ensemble (CSE, association, …).

Tant que ça ne sera le cas, les employeurs peu scrupuleux continueront à faire comme bon leur semble.

Cet article Épidémie de ruptures de périodes d’essai est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2020/03/27/epidemie-de-ruptures-de-periodes-dessai/feed/ 4 5631
Visualisez les limites de votre confinement avec unkm.fr https://blog.zwindler.fr/2020/03/25/unkm-fr/ https://blog.zwindler.fr/2020/03/25/unkm-fr/#comments Wed, 25 Mar 2020 09:00:00 +0000 https://blog.zwindler.fr/?p=5625 Service en ligne permettant de tracer un cercle de 1km de rayon autour de votre habitation dans le cadre des sorties sportives suite au confinement COVID-19

Cet article Visualisez les limites de votre confinement avec unkm.fr est apparu en premier sur Zwindler's Reflection.

]]>
Aujourd’hui, je vais faire un bref article pour parler du side project [qu’un collègue](https://twitter.com/Pixeye33) vient de démarrer et que je trouve génial.

A moins d’avoir vécu confiné AVANT la crise du coronavirus (ahah), vous êtes probablement au courant que les déplacements sont très limités (restez chez vous). Cependant il existe une dérogation depuis le début du confinement décrété le 16 mars 2020 : aller brièvement faire du sport.

Au début, le flou était total, les consignes contradictoires. Beaucoup s’en sont d’ailleurs amusés (notamment les réponses du CM du Ministère des Sports sur Twitter).

Heureusement, depuis lundi soir, les règles ont été précisées :

Et alors ?

Sauf que 1km autour du domicile, à moins d’habiter au centre d’une route de la forme d’un cercle de 1km de rayon, c’est pas facile à délimiter. On peut bien prendre une carte routière et tracer un cercle (c’est très digital) mais avec le numérique on doit pouvoir faire mieux !

(vous avez vu le troll subtil digital/numérique?)

Long story short, mon collègue @Pixeye33 a eu la bonne idée de faire un petit service en ligne pour vous aider à faire ça.

Le site s’appelle https://unkm.fr et comme son nom l’indique il va vous tracer un cercle de 1km de rayon à l’endroit où vous allez cliquer sur la carte.

Pour le maire de Bordeaux ça donne ça

Point appréciable, il n’y a pas de trackers ;-). Ce qui n’est peut être pas le cas d’autres services en ligne…

Merci Kimetrak (ping NextInpact)

Mise à jour du 02/04/2020

Plusieurs nouvelles fonctionnalités très utiles ont fait leur apparition dans l’application :

  • la possibilité d’utiliser la position actuelle de votre navigateur pour accélérer la recherche de la position où vous vous trouvez
  • l’affichage des coordonnées GPS du point choisi dans l’URL, ce qui permet de la sauvegarder si vous voulez revenir ou partager cette position avec quelqu’un

Et surtout, grâce à une contribution de Jean-Marie Favreau

  • la possibilité de tracer un parcours (pour une promenade) circulaire aux limites du cercle de 1km de rayon de votre confinement. Cette nouvelle fonctionnalité est hyper utile ! Merci à lui

Cet article Visualisez les limites de votre confinement avec unkm.fr est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2020/03/25/unkm-fr/feed/ 5 5625
Supprimer un namespace bloqué à Terminating https://blog.zwindler.fr/2020/03/23/supprimer-un-namespace-bloque-a-terminating/ https://blog.zwindler.fr/2020/03/23/supprimer-un-namespace-bloque-a-terminating/#comments Mon, 23 Mar 2020 07:15:00 +0000 https://blog.zwindler.fr/?p=5401 Checklist des choses à vérifier lorsque vous n'arrivez pas à supprimer un namespace dans Kubernetes ou qu'il reste à l'état Terminating

Cet article Supprimer un namespace bloqué à Terminating est apparu en premier sur Zwindler's Reflection.

]]>

Forcer la suppression d’un namespace bloqué à "Terminating" dans Kubernetes

Il y a quelques mois, j’ai eu des soucis pour supprimer un namespace lorsque j’ai voulu démonter mon cluster Ceph (monté avec Rook).

On aurait pu croire que ça m’a énervé (bon ok, si un peu quand même) mais ça m’a permis de mettre la main sur plusieurs commandes sympa avec kubectl donc tout n’est pas perdu ;-).

Voyez ce récit comme une checklist des choses à vérifier si jamais vous avez du mal à supprimer des objets dans Kubernetes !

Note: dans la même veine, n’hésitez pas à aller voir les articles que j’ai écris sur kubectl, notamment les tips and tricks !

La base

Pensant avoir correctement supprimé les objets Ceph dans mon cluster, j’ai donc terminé le nettoyage par une suppression toute bête du namespace

kubectl --context=sandbox delete ns rook-ceph

Sauf que, patatra, en essayant de vérifier qu’il était bien supprimé :

kubectl --context=sandbox get ns rook-ceph
NAME        STATUS        AGE
rook-ceph   Terminating   88d

Le namespace est toujours présent, et reste bloqué à l’état "Terminating".

Qu’à cela ne tienne, je tente de le re-supprimer. Ça ne marche pas :

kubectl --context=sandbox delete ns rook-ceph
Error from server (Conflict): Operation cannot be fulfilled on namespaces "rook-ceph": The system is ensuring all content is removed from this namespace.  Upon completion, this namespace will automatically be purged by the system

Forcer la suppression

Une rapide recherche sur le net me conseille d’ajouter les flags "–force", à obligatoirement associer avec le flag "–grace-period=0" (si vous ne le mettez pas, il vous dira de le mettre de toute façon…)

kubectl --context=sandbox delete ns rook-ceph --force --grace-period=0
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
Error from server (Conflict): Operation cannot be fulfilled on namespaces "rook-ceph": The system is ensuring all content is removed from this namespace.  Upon completion, this namespace will automatically be purged by the system.

Flute !

Vérifier qu’il ne reste pas des objets Kubernetes, dans le namespace ou associés

Bon, généralement quand j’arrive pas à supprimer un namespace, c’est qu’il reste un PVC qui traine, lui même attaché à un PV. Mais là non plus, rien :

kubectl --namespace=rook-ceph get pvc
No resources found in rook-ceph namespace.
kubectl get pv

Vérifier les CRD aussi !

Un truc à vérifier aussi dans le cas de rook, c’est qu’il ne reste pas de CRD (CustomRessourceDefinition) que vous n’avez pas l’habitude de manipuler et qui seraient encore présente dans le namespace

dgermain$ kubectl delete storageclass rook-ceph-block
Error from server (NotFound): storageclasses.storage.k8s.io "rook-ceph-block" not found
dgermain$ kubectl delete storageclass rook-cephfs
Error from server (NotFound): storageclasses.storage.k8s.io "rook-cephfs" not found

dgermain$ kubectl --context=sandbox get crd
volumes.rook.io                                  2019-08-19T09:46:08Z
dgermain$ kubectl --context=sandbox delete crd volumes.rook.io

Utiliser des scripts pour débloquer les objets en "Terminating"

Là ça commence à devenir pénible. Comme je ne suis évidemment pas le premier à avoir le problème, des gens ont écris des scripts pour faciliter la suppression d’objets bloqués au stade Terminating. Ces scripts prennent en charge la plupart des cas courants. Attention cependant à ce que vous faites avec (soyez sûrs de vous) !

dgermain:~/sources/knsk$ git clone https://github.com/thyarles/knsk/

dgermain:~/sources/knsk$ kubectl config use-context sandbox
Switched to context "sandbox".

dgermain:~/sources/knsk$ chmod +x knsk.sh
dgermain:~/sources/knsk$ ./knsk.sh
Deleting rook-ceph... done!

Lister tous les Objets du cluster qui s’appellent rook-ceph

Last but not least. La solution j’ai fini par la trouver en utilisant la commande suivante, qui permet de lister TOUS les types objets existants dans votre cluster :

kubectl api-resources --verbs=list --namespaced -o name

A partir de là, j’ai rajouté un petit xargs pour rechercher, dans tout le cluster, tous les objets s’appelant rook-ceph parmis tous les types d’objets qui existent. Et là surprise :

kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n rook-ceph
No resources found in rook-ceph namespace.
No resources found in rook-ceph namespace.
No resources found in rook-ceph namespace.
[...]
No resources found in rook-ceph namespace.
NAME        DATADIRHOSTPATH   MONCOUNT   AGE   STATE     HEALTH
rook-ceph   /var/lib/rook     1          88d   Created   HEALTH_OK
No resources found in rook-ceph namespace.
[...]
No resources found in rook-ceph namespace.
Error from server (NotAcceptable): the server was unable to respond with a content type that the client supports (get pods.metrics.k8s.io)
No resources found in rook-ceph namespace.
[...]

OUPS ! Il restait un CRD "cephcluster" que j’avais oublié de supprimer ! Sauf que cet objet n’apparaissait pas avec une requête d’affichage classique.

kubectl -n rook-ceph get cephcluster
NAME        DATADIRHOSTPATH   MONCOUNT   AGE   STATE     HEALTH
rook-ceph   /var/lib/rook     1          88d   Created   HEALTH_OK

kubectl -n rook-ceph delete cephcluster rook-ceph
cephcluster.ceph.rook.io "rook-ceph" deleted

Et c’est pas fini !

Malheureusement, ce n’est pas totalement terminé ! Notre namespace n’a plus d’objets qui bloquent sa suppression. Pour autant, il est encore bloqué dans l’état Terminating.

kubectl -n rook-ceph delete cephcluster rook-ceph
cephcluster.ceph.rook.io "rook-ceph" deleted
^C

Dans ce cas de figure, on peut soit relancer le script knsk, soit, à la main, patcher l’objet pour vider la métadata "finalizers" et débloquer le processus de suppression. Ca revient au même, mais je vous le met pour que vous compreniez ce que vous faites :

dgermain:~/sources/knsk$ kubectl -n rook-ceph patch cephclusters.ceph.rook.io rook-ceph -p '{"metadata":{"finalizers": []}}' --type=merge
cephcluster.ceph.rook.io/rook-ceph patched

Et maintenant, votre namespace est supprimé !

Cet article Supprimer un namespace bloqué à Terminating est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2020/03/23/supprimer-un-namespace-bloque-a-terminating/feed/ 2 5401
Ta visio Open Source comme un pro avec Jitsi https://blog.zwindler.fr/2020/03/17/ta-visio-open-source-comme-un-pro-avec-jitsi/ https://blog.zwindler.fr/2020/03/17/ta-visio-open-source-comme-un-pro-avec-jitsi/#comments Tue, 17 Mar 2020 07:55:00 +0000 https://blog.zwindler.fr/?p=5604 Tutoriel d'installation de la solution de visio conférence Jitsi Meet, qui permet de créer des conférences à la volée sans création d'utilisateur préalable

Cet article Ta visio Open Source comme un pro avec Jitsi est apparu en premier sur Zwindler's Reflection.

]]>

Jitsi Meet au secours de la France qui télétravaille

COVID-19 oblige, j’ai un peu modifié l’ordonnancement de mes articles pour reparler d’un sujet que j’avais traité il y a 3-4 ans : la visioconf avec Jitsi Meet. Pourquoi ce sujet ? D’abord parce que pas plus tard qu’il y a 5 jours, NextInpact (mon journal préféré) a relayé les mésaventures de Framasoft suite à l’épidémie.

En effet, Framasoft (que vous connaissez forcément) propose de longue date des outils/services en ligne gratuit. Le souci, c’est que le but est ici d’éduquer les gens et leur montrer qu’on peut autohéberger de nombreux services habituellement payants chez de gros éditeurs (ou gratuits en échange de vos données personnelles).

Mais, pris par la panique de devoir passer tout un tas de gens à l’arrache sur un mode massivement télétravail, beaucoup de gens se sont tournées vers des solutions toutes prêtes, surchargeant au moins de manière temporaire les serveurs de Framasoft.

Mais vous l’avez bien compris, le but, c’est d’apprendre à faire soit-même, comme le fait Framasoft, avec Jitsi Meet :).

Notes additionnelles

Si jamais vous cherchez des solutions toutes faites, sachez que de nombreuses entreprises de la tech mettent à disposition ce genre de solutions de manière temporairement gratuite pour soulager les équipes IT et "faire leur part" pour lutter contre la propagation du virus. Les derniers en date sont OVH qui propose un service de téléconférence gratuit jusqu’à 24h et 50 participants, mais j’ai aussi entendu parlé de discord pour de la visio à 50 et d’autres services qui font sauter leurs limites habituelles dans le contexte Coronavirus.

Parallèlement à cet article sur Jitsi, sachez que NextCloud propose une alternative libre (NextCloud Talk) dans la dernière version. Je ne l’ai pas encore testée, mais la communauté NextCloud FR est très active je suis sûr qu’ils ont du faire des tutos (Genma ?).

Et Jitsi dans tout ça ?

C’est quoi exactement Jitsi ?

Multi-platform open-source video conferencing

  • Share your desktop, presentations, and more
  • Invite users to a conference via a simple, custom URL
  • Edit documents together using Etherpad
  • Pick fun meeting URLs for every meeting
  • Trade messages and emojis while you video conference, with integrated chat.

C’est donc une plateforme relativement complète de visio, a priori plutôt scalable (possibilité de faire des confs à plus de 100), qui permet de partager son écran et de chatter.

Le gros avantage c’est que c’est dans un navigateur et que c’est très simple d’utilisation. On ouvre la page web, on rentre un nom de salle dans une barre de texte, et voilà.

Installation

Avant de commencer, je me suis posé la question du sizing. Nécessairement ça va dépendre fortement de la charge que vous attendez, mais sachez qu’au minimum il vous faudra une machine avec 1 vCPU et 1Go de RAM. Le double serait le mieux, car Jitsi se compose de plusieurs applications Java (c’est donc un peu gourmand même sans charge).

https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md

En soit, l’installation de Jitsi est assez triviale, en particulier sur une Debian ou une Ubuntu récente.

Instruction d’installation disponibles sur https://jitsi.org/downloads/ubuntu-debian-installations-instructions/

Ici, voilà les commandes que j’ai tapé pour installer Jitsi sur une Ubuntu 18.04 vierge :

sudo apt upgrade 
sudo apt install gnupg2

wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add -

sudo sh -c "echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list"

sudo apt update
sudo apt install jitsi-meet

Lors de l’installation, le terminal nous promptera pour le nom d’hôte public sur lequel le service sera disponible et si on souhaite générer un certificat ou en fournir un soit même.

Cependant, comme souvent avec les sites qui disent "regardez c’est trop simple d’installer notre soft, c’est juste apt install monsoftgenial", en vrai il manque des bouts ;)

Firewall

A moins d’avoir une machine chez un cloud provider pas trop regardant et sur laquelle vous installez le soft sans se poser de question, vous allez probablement avoir mis (ou vouloir mettre) du filtrage de port devant vos serveurs.

Comme vous vous en doutez, il va falloir ouvrir des ports pour que ça fonctionne correctement. On trouve l’info des ports utilisés par Jitsi dans la documentation d’installation (un peu plus complète) disponible sur Github.

Grosso modo, si tous les composants de jitsi sont installés sur la même machine, vous avez les ports suivants à ouvrir sur Internet (ou en LAN si vous ne souhaitez utiliser Jitsi que sur votre réseau Interne) :

  • 443/TCP pour le serveur web de la page d’accueil
  • 4443/TCP (jitsi-meet videostream)
  • 10000 => 20000 en TCP et en UDP

La dernière plage de 10000 port est très probablement bien trop grande dans une grande majorité des cas et peut normalement être configurée dans Jitsi (mais je n’ai pas les commandes exactes).

Jitsi dans un réseau NATé

Je n’allais pas commander une nouvelle machine juste pour mes tests Jitsi. J’ai donc installé une VM sur mes hyperviseurs persos, dans lequel le réseau virtuel est NATé.

Et manque de bol, dans ce cas là, il faut ajouter deux lignes dans un fichier de configuration (deux lignes que j’ai mis du temps à trouver mais qui sont là aussi, dans la doc… Passons).

Dans la machine sur laquelle vous avez installé Jitsi, ouvrez le fichier suivant et ajoutez y les deux lignes qui suivent (en remplaçant bien entendu les parties entre crochets par les vraies IPs).

vi /etc/jitsi/videobridge/sip-communicator.properties
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=[IP_MACHINE_LAN]
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=[IP_PUBLIQUE_SERVICE]

Premier test

Maintenant qu’on a configuré le firewall et la configuration spécifique pour le NAT, on essaye de faire sa première conf et … voilà ce que ça donne :

Comme vous pouvez le voir sur ce superbe cliché, j’ai connecté 3 devices, dont un smartphone, depuis mon wifi vers mon serveur chez Hetzner.

J’ai testé avec Chrome et Firefox, les deux fonctionnent mais il arrive que Jitsi conseille plutôt d’utiliser Chrome. Historiquement, c’était bien mieux supporté, en tout cas.

Pour le smartphone, il existe une application sur l’Android Store et sur F-Droid qui m’a paru assez complète.

Partage d’écran

C’était une des déceptions que j’avais eu il y a 3 ans lorsque j’avais essayé l’outil. On teste et on se dit : "Cool, la vidéo fonctionne… Mais qu’en est-il ?"

Et là c’est (c’était) le drame. A l’époque, j’avais surtout fais le tuto pour cette partie, car il était nécessaire de compiler soit même une extension pour chaque navigateur (et je n’avais réussi à faire fonctionner que celle de Chrome (cf mon précédent article).

Heureusement, aujourd’hui, ça fonctionne out of the box !

Avec quelques limitations tout de même. Si sur Chrome, j’ai pu partager n’importe quelle de mes fenêtres ouvertes, je n’ai réussi à partager que mon navigateur avec Firefox. Je ne sais pas si c’est un souci de mon côté ou une limitation de l’outil.

Quelques features sympa

Dans les fonctionnalités "nice to have", il existe comme dans un autre outil propriétaire qui en fait massivement la pub à la télé, la possibilité de flouter le fond pour qu’on ne voit pas le bazar que c’est chez vous par exemple. Ça marche assez bien mais ça consomme énormément de CPU (surtout si vous avez un portable avec un CPU un peu faiblard) et ça rajoute quand même un peu de latence.

On peut espérer que cette fonctionnalité encore en bêta finira par s’améliorer.

Ma tête n’est pas floutée, c’est l’essentiel…

Le chat fonctionne bien mais la gestion des emoji se limite à une 15aine de signe. Quand on est habitué à Slack et aux émoji personnalisés, c’est vraiment pauvre…

Il existe bien entendu une fonction pour demander la parole (et ainsi éviter que ça soit le bazar quand on est nombreux), ainsi que des fonctions pour se mute ou couper sa caméra.

On peut également choisir sa qualité vidéo et voir la bande passante sur le poste local.

Mais quelques manques

Je n’ai pas eu le temps de jouer extensivement avec l’outil, mais il me semble qu’une partie de mes remarques d’il y a 3 ans sont cependant toujours d’actualité.

L’outil se veut simple : pas d’inscription nécessaire et réunion simple à créer. Le corollaire est que l’outil est parfois simpliste. Pas d’interface d’administration pour vérifier (voire limiter) les consommations de bande passante au niveau global sur le serveur, qui est connecté et quand, etc.

De même, n’importe qui, de base peut créer une conférence. Si on est un peu parano on peut s’imaginer plein de choses… (A noter, on peut protéger l’accès à une conférence par un mot de passe une fois qu’on l’a créée).

Bref, quelques points encore à améliorer pour avoir une solution 100% équivalente aux acteurs payants. Ces mêmes points qu’il y a 3 ans et qui avaient des solutions de contournement mais non triviales (notamment Openfire). Donc à voir si c’est toujours le cas aujourd’hui.

Mais en attendant que je me penche là dessus, enjoy :)

Sources et bonus

Cet article Ta visio Open Source comme un pro avec Jitsi est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2020/03/17/ta-visio-open-source-comme-un-pro-avec-jitsi/feed/ 15 5604
Proxmox VE 6 + pfsense sur un serveur dédié (2/2) https://blog.zwindler.fr/2020/03/09/proxmox-ve-6-pfsense-sur-un-serveur-dedie-2-3/ https://blog.zwindler.fr/2020/03/09/proxmox-ve-6-pfsense-sur-un-serveur-dedie-2-3/#comments Mon, 09 Mar 2020 11:49:55 +0000 https://blog.zwindler.fr/?p=5589 Tutoriel de déploiement d'un serveur Proxmox VE 6 sécurisé par un serveur PFsense

Cet article Proxmox VE 6 + pfsense sur un serveur dédié (2/2) est apparu en premier sur Zwindler's Reflection.

]]>

Note : cet article a été écrit par Charles Bordet, et se veut être une version à jour de cette suite d’articles écrits sur ce blog (mais avec des versions obsolètes de Proxmox et de PFSense). Merci à lui !

Dans l’article précédent, nous avons mis en place notre serveur Proxmox, l’avons sécurisé, puis avons téléchargé puis installé une machine virtuelle PFSense qui va nous faire office de point d’entrée unique.

Routage du trafic vers la PFSense

Comme nous l’avons déjà évoqué, l’hyperviseur est en première ligne. Et la PFSense est en 2e ligne. Et les VM en 3e ligne.

L’objectif, c’est d’avoir la PFSense en 1e ligne, et les VM en 2e ligne. L’hyperviseur va disparaître en ne devenant rien de plus qu’un routeur.

La première faille à corriger, c’est qu’il existe un raccourci qui permet de passer directement de l’hyperviseur aux VM puisqu’ils sont tous sur le réseau LAN. Essayez par exemple de pinger 192.168.9.10 depuis l’hyperviseur, ou de pinger 192.168.9.1 depuis la VM.

Ça on va le bloquer.

Sur l’hyperviseur, on va ajouter une route qui dit : Tous les paquets vers le LAN doivent passer par l’interface WAN de la PFSense. C’est cette règle qui nous permet de forcer tout le traffic à passer par la PFSense, comme si la PFSense était en frontal, avant d’arriver dans le LAN.

On crée un fichier /root/pfsense-route.sh avec les lignes suivantes :

#!/bin/sh

## IP forwarding activation
echo 1 > /proc/sys/net/ipv4/ip_forward

## Rediriger les paquets destinés au LAN pour l'interface WAN de la PFSense
ip route change 192.168.9.0/24 via 10.0.0.2 dev vmbr1

Pour que ce fichier se lance automatiquement dès qu’on boot, on lance la commande chmod +x /root/pfsense-route.sh et on ajoute à la fin du fichier /etc/network/interfaces la ligne suivante en gras à la fin du bloc de configuration de vmbr2 :

[...]
auto vmbr1
    iface vmbr1 inet static
    address 10.0.0.1
[...]

auto vmbr2
    iface vmbr2 inet static
[...]
    bridge_fd 0
    post-up /root/pfsense-route.sh

Et on exécute le fichier simplement en écrivant son chemin dans la console : /root/pfsense-route.sh.

À présent, si vous essayez de nouveau de ping l’hyperviseur depuis la VM, ou l’inverse, vous aurez des messages Destination Host Unreachable, ce qui indique que la PFSense bloque tout !

On va remédier à cette situation parce que les pings vont bien nous servir plus tard pour débugger.

Dans l’interface de la PFSense, on va commencer par aller dans Status / System Logs. Puis cliquez sur l’onglet Firewall. Le but ici c’est de vous montrer un moyen de débugger au cas où vous auriez des problèmes.

Sur cette page, vous verrez toutes les connexions bloquées par le pare-feu.

Si vous descendez dans la page, vous allez voir les pings qui ont été bloqués.

Bon. On va rien faire de spécial sur cette page. C’était juste pour vous montrer.

On va plutôt aller dans Firewall/Rules. Cliquez sur "Add" puis entrez les paramètres suivants :

  • Action : Pass
  • Interface : WAN
  • Address Family : IPv4
  • Protocol : ICMP
  • Source : Any
  • Destination : Any

Cette règle assez permissive permet d’autoriser tous les paquets en protocole ICMP. Une fois ajoutée, n’oubliez pas d’appliquer les changements. Puis réessayez de faire pinger vos machines. Le ping est de retour ! Mais il passe par la PFSense cette fois-ci.

Port forwarding de la PFSense

C’est là qu’intervient le très long script d’iptables de m4vr0x.

J’ai passé beaucoup de temps sur ce script et au final je le comprends plutôt bien à présent.

On va voir morceau par morceau comment il fonctionne.

Note importante : Ne lancez pas les instructions une par une. En effet, au début on bloque toutes les connexions. Donc votre connexion SSH va être fermée et vous serez enfermé à l’extérieur.

Heureusement, les modifications iptables ne résistent pas à un reboot. Donc si vous faites cette bêtise, redémarrez le serveur depuis l’interface de votre provider.

À la place, enregistrez-le dans le fichier /root/iptables, rendez le fichier exécutable, puis exécutez-le.

Première partie :

#!/bin/sh

    # ---------
    # VARIABLES
    # ---------

## Proxmox bridge holding Public IP
PrxPubVBR="vmbr0"
## Proxmox bridge on VmWanNET (PFSense WAN side) 
PrxVmWanVBR="vmbr1"
## Proxmox bridge on PrivNET (PFSense LAN side) 
PrxVmPrivVBR="vmbr2"

## Network/Mask of VmWanNET
VmWanNET="10.0.0.0/30"
## Network/Mmask of PrivNET
PrivNET="192.168.9.0/24"
## Network/Mmask of VpnNET
VpnNET="10.2.2.0/24"

## Public IP => Set your own
PublicIP="xx.xx.xx.xx"
## Proxmox IP on the same network than PFSense WAN (VmWanNET)
ProxVmWanIP="10.0.0.1"
## Proxmox IP on the same network than VMs
ProxVmPrivIP="192.168.9.1"
## PFSense IP used by the firewall (inside VM)
PfsVmWanIP="10.0.0.2"


    # ---------------------
    # CLEAN ALL &amp; DROP IPV6
    # ---------------------

### Delete all existing rules.
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
### This policy does not handle IPv6 traffic except to drop it.
ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD DROP
    
    # --------------
    # DEFAULT POLICY
    # --------------

### Block ALL !
iptables -P OUTPUT DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP

    # ------
    # CHAINS
    # ------

### Creating chains
iptables -N TCP
iptables -N UDP

# UDP = ACCEPT / SEND TO THIS CHAIN
iptables -A INPUT -p udp -m conntrack --ctstate NEW -j UDP
# TCP = ACCEPT / SEND TO THIS CHAIN
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP

    # ------------
    # GLOBAL RULES
    # ------------

# Allow localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Don't break the current/active connections
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# Allow Ping - Comment this to return timeout to ping request
iptables -A INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT

Cette première partie un peu longue ne fait pas grand chose. Au début, on définit les variables. Ça permet d’éviter de ré-écrire des milliers de fois les mêmes adresses IPs et de rendre le script un peu plus lisible. N’oubliez pas de changer l’adresse IP publique.

Par défaut, on spécifie qu’on interdit tout. Tous les paquets sont droppés.

Ensuite, on crée des chaînes qui vont capturer toutes les nouvelles connexions TCP et UDP, respectivement.

Et enfin, on ajoute des règles un peu de base :

  • On accepte les connexions localhost
  • On ne stoppe pas les connexions existantes. Comme votre connexion SSH par exemple.
  • On autorise les pings. Parce que c’est pratique pour débugger.

Ça, vous pouvez le lancer, mais attention, si vous perdez votre connexion SSH, vous ne pourrez pas la renouveler. Donc on ajoute la suite :

    # --------------------
    # RULES FOR PrxPubVBR
    # --------------------

### INPUT RULES
# ---------------

# Allow SSH server
iptables -A TCP -i $PrxPubVBR -d $PublicIP -p tcp --dport 21153 -j ACCEPT
# Allow Proxmox WebUI
iptables -A TCP -i $PrxPubVBR -d $PublicIP -p tcp --dport 8006 -j ACCEPT

Ces règles sont à propos de l’interface vmbr0, celle qui nous relie à l’Internet mondial. On ajoute deux règles :

  • On autorise les nouvelles connexions sur le port SSH qui passent par vmbr0 et dont la destination est notre IP publique.
  • On autorise les nouvelles connexions sur le port 8006 qui passent par vmbr0 et dont la destination est notre IP publique.

Ici, il vous faudra changer le port 21153 pour le port SSH que vous aurez choisi ! Précédemment dans le tutorial, j’avais utilisé 21153, donc pour rester cohérent j’ai remis le même ici.

Ça c’est seulement pour les paquets entrant, donc les personnes qui veulent initier une connexion avec nous.

Plus tard, on pourra même supprimer ces règles. À la place, on se connectera au VPN, et à partir de là on aura accès au SSH ou au Proxmox.

Ensuite, les paquets sortants :

### OUTPUT RULES
# ---------------

# Allow ping out
iptables -A OUTPUT -p icmp -j ACCEPT

### Proxmox Host as CLIENT
# Allow HTTP/HTTPS
iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p tcp --dport 443 -j ACCEPT
# Allow DNS
iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p udp --dport 53 -j ACCEPT

D’abord, on autorise les pings à sortir. Cette règle est redondante avec une autre précédente où on autorisait les pings dans tous les sens.

L’idée, c’est que la règle précédente est très permissive pour pouvoir débugger. Mais elle est pas censée rester pour toute la vie.

Par contre, autoriser un ping sortant, ça peut toujours servir à l’occasion, et ça pose zéro problème de sécurité.

Puis j’autorise les paquets HTTP et HTTPS à sortir. Ça c’est ce qui va nous donner accès à l’internet. D’ailleurs vous pouvez essayer. Envoyez un ping vers 1.1.1.1 avant d’entrer ces nouvelles règles, ça devrait être bloqué, puis ré-essayez après avoir entré ces nouvelles règles, et ça devrait marcher !

Cette règle vous servira par exemple à télécharger des images ISO ou à mettre à jour le serveur. Ce n’est pas cette règle qui sert à donner accès à l’internet au VM par contre.

Et c’est tout pour les règles output. Vous noterez que m4vr0x en avait ajouté pas mal plus. Je vous conseille d’en rajouter seulement si vous en avez besoin. De base, on est parcimonieux.

Par exemple les règles output pour le port SSH et le port 8006 ne sont pas nécessaires. En effet, on les accepte déjà dans INPUT, ce qui permet à votre ordinateur local d’initier une connexion avec le serveur. Une fois la connexion initiée, tous les paquets sont autorisés (c’est la règle qu’on avait ajouté dans les GLOBAL RULES). La plupart des règles concernent les nouvelles connexions.

Finalement, il ne reste plus qu’à dire qu’on route tout le trafic vers la PFSense :

### FORWARD RULES
# ----------------

### Redirect (NAT) traffic from internet 
# All tcp to PFSense WAN except 21153, 8006
iptables -A PREROUTING -t nat -i $PrxPubVBR -p tcp --match multiport ! --dports 21153,8006 -j DNAT --to $PfsVmWanIP
# All udp to PFSense WAN
iptables -A PREROUTING -t nat -i $PrxPubVBR -p udp -j DNAT --to $PfsVmWanIP

# Allow request forwarding to PFSense WAN interface
iptables -A FORWARD -i $PrxPubVBR -d $PfsVmWanIP -o $PrxVmWanVBR -p tcp -j ACCEPT
iptables -A FORWARD -i $PrxPubVBR -d $PfsVmWanIP -o $PrxVmWanVBR -p udp -j ACCEPT

# Allow request forwarding from LAN
iptables -A FORWARD -i $PrxVmWanVBR -s $VmWanNET -j ACCEPT

Le début est une règle de PREROUTING. Ça veut dire que l’action s’exécute sur le paquet avant toute autre chose. Par exemple, si José essaie de se connecter sur le port 3812 de votre Nextcloud, on veut pas forcément le dropper. Ce genre de décision sera le futur boulot de la PFSense. Sans la règle de pré-routing, le paquet serait droppé par défaut.

Donc à la place, on l’envoie… vers la PFSense.

Notez que cette règle s’applique SAUF pour les ports SSH et 8006, qui ont un traitement un peu particulier. De nouveau, plus tard, quand vous aurez mis le VPN, on pourra aussi supprimer ces règles.

Le paragraphe suivant va de pair avec ce qu’on vient de faire. En gros ça dit : Si un paquet est en transfert de l’internet mondial vers la PFSense, alors on l’autorise. Et ça tombe bien, puisqu’on vient juste de dire que tous les paquets qui viennent de l’internet mondial sont automatiquement transférés vers la PFSense.

Finalement, on fait aussi l’inverse. Tous les paquets qui sont en transfert depuis la PFSense (et donc qui se dirigent de toute vraisemblance vers l’internet mondial) sont acceptés aussi. La communication, ça va dans les deux sens.

Donc là, je résume : Un paquet vient de l’internet mondial. On le pré-route vers la PFSense. On accepte ce transfert. La PFSense le reçoit. La PFSense va prendre une décision, par exemple l’envoyer vers une VM, recevoir une réponse, puis renvoyer ce paquet vers l’internet mondial. On accepte ce transfert de nouveau.

On a tout ce qu’il faut pour que les VMs aient accès à l’internet mondial.

SAUF ! Le port forwarding. La petite astuce en gros qui permet à une machine d’un réseau local à accéder à l’internet mondial sans avoir d’IP publique :

### MASQUERADE MANDATORY
# Allow WAN network (PFSense) to use vmbr0 public adress to go out
iptables -t nat -A POSTROUTING -s $VmWanNET -o $PrxPubVBR -j MASQUERADE

Là maintenant votre LAN est raccordé à l’internet.

Sauf si… vous avez choisi VirtIO comme modèle de réseau.

Si vous pingez 1.1.1.1 depuis votre VM Ubuntu, vous allez réussir à joindre l’internet mondial. C’est un signe que les règles que nous avons mises fonctionnent bien. Mais… pourtant, l’accès à l’internet ne va pas forcément marcher.

C’est un problème qui m’a cassé la tête pendant longtemps. Jusqu’à ce que je tombe sur ce thread au titre évocateur : Quelqu’un a-t-il réussi à foutre un putain de PFSense avec Proxmox.

La solution est donc d’aller dans System / Advanced / Networking au niveau des paramètres PFSense et de cocher la case Disable hardware checksum offload.

Et pouf, ça marche.

D’ailleurs, à partir de maintenant, vous pouvez vous amuser à regarder les logs du firewall de la PFSense et vous verrez toutes les gentilles personnes qui se font refouler.

Bon bah on est pas mal là !

On a bien avancé, mais il reste encore quelques petits détails à voir :

  • On doit toujours passer par une VM Ubuntu Desktop pour paramétrer la PFSense. Pas pratique.
  • Le Proxmox est accessible depuis l’internet mondial. Pas optimal niveau sécurité.
  • On ne sait pas comment servir un service depuis une VM qui soit accessible à l’internet mondial (un serveur nginx par exemple).
  • Et aussi comment servir un service pour des besoins internes (un serveur SSH par exemple).

On va voir comment résoudre tout ça dans la prochaine partie. Et puis après on verra comment mettre un VPN en place pour que ce soit bien sécurisé.

Hébergement de services

Mais je suis sûr que vous avez hâte d’utiliser le potentiel de votre hyperviseur dès maintenant ! En tout cas, moi j’avais hâte :D Donc faisons-le, mais promettez-moi qu’après vous ferez les étapes pour mettre le VPN.

Ok.

Commençons par héberger un serveur nginx, probablement le truc le plus simple et sans aucune configuration à mettre en place

Un serveur nginx sur l’internet mondial

Pour l’exemple ici, on va utiliser notre VM UbuntuDesktop. C’est vraiment pour l’exemple, parce que je pense que c’est mieux d’isoler les services. 1 VM = 1 service.

On va donc aller sur la VM, et dans le terminal on install nginx: sudo apt install nginx (faites un update d’abord).

Une fois l’installation faite, vérifiez que le serveur fonctionne bien en allant sur http://localhost à partir de la VM. Vous devriez voir l’écran de bienvenue de nginx.

Maintenant, on veut arriver à accéder à cette page depuis l’internet mondial. Depuis chez nous quoi. Pour ça, on va aller dans la configuration de la PFSense, et cliquer sur Firewall/NAT, puis ajouter :

  • Interface : WAN
  • Protocol : TCP
  • Destination : Any
  • Destination Port Range : 8001
  • Redirect target IP : 192.168.9.10
  • Redirect target port : 80
  • Description : Serveur nginx

Ici il faut bien avoir en tête qu’on se met du point de vue de la VM dans le LAN. Donc destination signifie la destination du paquet qui part de la VM. On veut qu’il arrive dans l’internet mondial, sur le port 8001. Ce choix de port est complètement libre.

Le Redirect target IP, c’est l’IP de la VM, ainsi que le port initial du serveur nginx. Là on n’a pas le choix par contre.

On valide et on applique les changements.

Vous remarquerez qu’une règle a automatiquement été ajoutée dans Firewall/Rules. Oui parce que c’est bien de mettre un NAT en place, mais si le port 80 n’est pas ouvert au niveau de la PFSense, les paquets ne passeront pas.

On attend une petite minute, et on essaie d’accéder : http://proxmox.example.com:8001.

Gagné !

Un serveur SSH sur l’internet privé

Bon, maintenant supposons qu’on veuille mettre en place un serveur SSH.

Oui parce que la console via l’interface de Proxmox, c’est ok, mais bon, autant utiliser le terminal dont on a l’habitude.

C’est différent du serveur nginx parce que cette fois-ci, on n’a pas besoin de le déployer publiquement. Moi je dis que si un service est réservé à un usage privé, il faut le laisser privé. Sinon on multiplie les angles d’attaque pour les méchants.

Donc là l’objectif c’est de pouvoir se connecter en SSH sur notre machine UbuntuDesktop à partir de l’hyperviseur. Donc oui, il faut d’abord SSH dans l’hyperviseur, et à partir de là, on SSH dans la VM. Trop d’étapes ? Plus tard, avec le VPN, vous pourrez directement SSH dans la machine sans cette étape intermédiaire.

Premièrement, installons le serveur SSH sur la VM Ubuntu : sudo apt install openssh-server. De base, il va écouter sur le port 22, et on va laisser ça comme ça.

Vous l’avez compris, il va falloir ouvrir le port sur la PFSense. Pas de NAT cette fois-ci, juste une ouverture de port. Donc dans Firewall/Rules :

  • Action : Pass
  • Interface : WAN
  • Address Family : IPv4
  • Protocol : TCP
  • Source : Single host = 10.0.0.1
  • Destination : LAN net (on pourrait se limiter à notre VM, mais on va probablement vouloir se connecter en SSH systématiquement à toutes les VMs)
  • Destination port Range : 22
  • Description : SSH pour les VMs

On valide, on applique les changements, on attend une petite minute, et on essaie depuis l’hyperviseur : ssh charles@192.168.9.10.

Timeout.

Ah !

Pourquoi ?

C’est là que je vous annonce que tout à la fin de ce tutorial, vous trouverez une section Comment débugger qui vous apprendra comment écouter des paquets et comprendre ce qui se passe sur vos machines. Voici un petit récap en attendant.

Un moyen de comprendre les flux de paquets, pourquoi ils sont bloqués, où est-ce qu’ils sont bloqués, etc., c’est d’utiliser la commande tcpdump qui permet de sniffer le trafic sur votre machine. Cette commande m’a énormément aider pour suivre le tuto de m4vr0x, donc je vous donne l’astuce aussi.

Un tcpdump -i vmbr1 -p tcp permet d’écouter sur l’interface WAN. Outre le bruit des méchants qui tapent à votre porte, on s’attend à voir des paquets SSH aller de 10.0.0.1 vers 192.168.9.10. Il n’en est rien. Ça veut dire quoi ? Ça veut dire que les paquets ne partent même pas de la machine. Pourquoi ?

Les iptables ! Mais oui. On n’a jamais dit qu’on acceptait de faire sortir des paquets sur le port 22.

Une autre astuce de tonton : Dans le fichier iptables qu’on avait créé, vous pouvez rajouter l’instruction suivante : iptables -A OUTPUT -p tcp -o vmbr1 -j LOG. Placez-la avant les instructions qui bloquent tout (donc vers le début du fichier). Ça vous permettra d’enregistrer tout le trafic qui correspond à l’instruction (en l’occurrence, ici, les paquets sortants en TCP sur l’interface vmbr1), et donc de voir ce qui est bloqué et ce qui ne l’est pas. Les logs s’enregistrent dans /var/log/syslog.

Ici, tout simplement, on va dire qu’on autorise les paquets à sortir sur l’interface vmbr1. Rajoutez à la fin du fichier iptables ces quelques lignes :

    # --------------------
    # RULES FOR PrxVmWanVBR
    # --------------------

### Allow being a client for the VMs
iptables -A OUTPUT -o $PrxVmWanVBR -s $ProxVmWanIP -p tcp -j ACCEPT

Rassurez-vous, normalement on ne devrait pas avoir à toucher à ce fichier de nouveau.

Ici, vous avez peut-être deux questions qui vous viennent à l’esprit.

On avait pas déjà l’ensemble du trafic qui était autorisé de l’hyperviseur vers la PFSense ?! Alors, oui, mais seulement en FORWARD. On avait mis une règle qui acceptait tous les paquets qui provenaient de l’internet mondial et qui étaient transférés vers la PFSense. Là, dans ce cas, on accepte tous les paquets en provenance de l’hyperviseur vers la PFSense.

Pourquoi on ne limite pas au port 22 ? C’est un peu brutal cette ouverture générale non ? C’est vrai. L’idée, c’est de ne pas avoir à toucher à ce fichier dès qu’on veut rajouter un service. On sous-traite la gestion des autorisations à la PFSense. Et comme c’est seulement les connexions qui sont issues de l’hyperviseur, donc les communications internes, ce n’est pas gênant.

De nouveau, le VPN résoudra ce genre de questions.

À présent, essayez de vous connecter en SSH depuis l’hyperviseur vers la VM, et ça marche !

Accéder à la PFSense depuis l’internet mondial

Dernier petit point important avant de passer au VPN : Comment accéder à la PFSense depuis votre laptop sans utiliser cette VM qui lag du cul ? (Oui bon désolé mais là j’écris ce tutorial en étant en Asie et ma VM est en Allemagne, c’est horrible le lag !)

C’est très simple. On va juste ouvrir le port HTTPS sur la PFsense. Ajoutons la règle suivante :

  • Action : Pass
  • Interface : WAN
  • Address Family : IPv4
  • Protocol : TCP
  • Source : Any
  • Destination : This firewall (self)
  • Destination Port Range : HTTPS
  • Description : Accès à la PFSense depuis l’internet mondial

À présent, si vous vous connectez sur https://host.domain.name, vous pourrez accéder à la PFSense.

Sécuriser les services privés avec un VPN

Bon, c’est bien tout ça. On est presque au bout.

Mais il reste des problèmes :

  • J’aime pas trop avoir cette PFSense accessible par n’importe qui. Y’a que moi qui en ai besoin après tout.
  • Pareil pour l’hyperviseur Proxmox, que ce soit au niveau de l’accès SSH ou de l’interface web.
  • Et puis c’est chiant pour SSH dans une VM. Il faut faire 2 étapes. C’est long 2 étapes !

Woh woh.. calmos !

Le VPN va résoudre tous ces problèmes.

L’idée c’est qu’on va créer un nouveau réseau virtuel : 10.2.2.0/24.

La PFSense sera dans ce réseau virtuel. Et on va pouvoir se connecter dans ce réseau virtuel, de telle sorte que notre laptop aura une IP privée du type 10.2.2.2 (le 10.2.2.1 sera réservé à la PFSense).

À partir de là, modulo 2-3 changements, on pourra accéder au LAN à travers la PFSense. Et évidemment, il n’y a que nous qu’on aura le droit de se connecter au VPN.

Et le truc super cool, c’est que la PFSense rend cette création de VPN su-per-sim-ple.

Allez, c’est parti ! Déjà, il faut créer des certificats.

Création de l’autorité de certification

Dans la PFSense, on clique sur System/Cert. Manager. puis Ajouter :

  • Descriptive Name : L’autorité de Certification
  • Method : Create an internal Certificate Authority
  • Key length : 2048
  • Digest Algorithm : sha256
  • Lifetime : 3650
  • Common Name : example.com (changez pour le nom de votre autorité)
  • Country Code : FR

Création du certificat pour le serveur

Maintenant on clique sur l’onglet « Certificates », puis Ajouter :

  • Method : Create an internal Certificate
  • Descriptive Name : Le serveur VPN
  • Certificate authority : Choisissez votre autorité de certification nouvellement créée
  • Key length : 2048
  • Digest Algorithm : sha256
  • Lifetime : 3650
  • Common Name : vpn.example.com (changez pour le nom du serveur VPN)
  • Certificate Type : Server Certificates

Création du certificat pour le client

On recrée un nouveau certificat, mais changer le type à la fin :

  • Method : Create an internal Certificate
  • Descriptive Name : Le client VPN
  • Certificate authority : Choisissez votre autorité de certification nouvellement créée
  • Key length : 2048
  • Digest Algorithm : sha256
  • Lifetime : 3650
  • Common Name : vpn-client.example.com (changez pour le nom du client VPN)
  • Certificate Type : User Certificates

C’est fini pour la création de certificats !

Création du serveur VPN

On va dans VPN/OpenVPN et Ajouter :

  • Server mode : Remote Access (TLS + User Auth)
  • Protocol : UDP
  • Interface : WAN
  • Local Port : 18223 : De nouveau, on change le port par défaut.
  • Description : Mon VPN
  • TLS Configuration : Activé
  • Peer Certificate Authority : Choisissez votre autorité de certification
  • Server Certificate : Choisissez le certificat pour le serveur
  • IPv4 Tunnel Network : 10.2.2.0/24
  • Redirect IPv4 Gateway : Activé. Cette case vous permettra d’accéder à l’internet à travers le VPN. Sinon, vous pouvez spécifier le réseau local auquel vous souhaitez accéder avec le VPN (192.168.9.0/24 dans notre cas).
  • Concurrent connections : 3. Une pour l’ordi, une pour le téléphone, et une pour un attaquant. Non je déconne :D Mettez 2. Ou en tout cas, mettez le nombre correspondant au nombre d’appareils que vous connecterez simultanément.
  • Compression : Disable Compression. Conseillé pour ne pas être sensible aux attaques VORACLE.
  • Push Compression : Cochez la case. Ne pas cocher cette case m’empêchait de me connecter via mon laptop sous linux. Mais ça marchait avec Android. Cocher juste la case et épargnez-vous le mal de crâne.
  • Dynamic IP : Cochez la case.

Et voilà !

Maintenant il nous faut un utilisateur et on pourra se connecter.

Création de l’utilisateur pour le VPN

Dans System/User manager, cliquez sur Ajouter.

  • Disabled : On ne coche pas la case.
  • Username : charles
  • Password : xxx

Enregistrer. Puis retournez éditer l’utilisateur et ajoutez-lui le certificat client que nous avons créé plus tôt. Dans User Certificates, cliquez sur Ajouter, puis :

  • Method : Choose an existing certificate
  • Existing Certificate : Le Client VPN

On enregistre.

Configuration du client

On est bon !

On peut facilement exporter un fichier de configuration pour automatiquement configurer votre client VPN, que ce soit sous Windows, Mac, Linux, Android, ou votre machine à café intelligente. Oui oui, il est conseillé de connecter vos objects connectés à un VPN si vous souhaitez y accéder à distance. Ce sont de vraies passoires de sécurité.

On va dans System/Package Manager, puis Available Packages, et on cherche export.

Puis on install openvpn-client-export.

On retourne dans VPN/OpenVPN, et on trouve le nouvel onglet Client Export.

  • Remote Access Server : Mon VPN
  • Host Name Resolution : Other – et on choisit notre IP publique.
  • Use Random Local Port : On coche la case.

On enregistre et on scrolle jusqu’en bas.

Ici on a plein de possibilités d’exports.

Moi je prends le Most Clients parce que ça marche chez moi.

Voilà voilà.

Ensuite, sur mon ordinateur local, qui est un Ubuntu, je vais dans la configuration Réseau, et je clique sur le petit + à côté de VPN. Je choisis "Import from file…" et j’importe le fichier que je viens juste de télécharger. Il vous faudra peut-être installer le client openvpn d’abord, si vous n’avez pas l’option.

Normalement, tout est déjà pré-rempli, sauf, le username et le password. Entrez ceux de l’utilisateur qu’on a créé plus tôt.

Et voili voiloù !

Ça marche chez vous ?

Parce que chez moi, pas encore…

Ah oui. Toujours ces histoires de pare-feu. C’est ennuyant à la fin.

Ouverture des chakras

Il y a deux modifications à faire.

Imaginez un paquet du VPN. Il arrive sur votre serveur. Il demande son chemin pour aller vers son réseau, c’est-à-dire 10.2.2.0/24. Que lui dit la table de routage ?

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         xx.xx.xx.xx     0.0.0.0         UG        0 0          0 vmbr0
10.0.0.0        0.0.0.0         255.255.255.252 U         0 0          0 vmbr1
xx.xx.xx.xx     0.0.0.0         255.255.255.224 U         0 0          0 vmbr0
192.168.9.0     10.0.0.2        255.255.255.0   UG        0 0          0 vmbr1

En gros : retourne chez toi.

On va rajouter une route pour le VPN. Retournez dans le fichier /root/pfsense-route.sh et rajoutez cette ligne :

## Rediriger les paquets destinés au VPN pour l'interface WAN de la PFsense
ip route add 10.2.2.0/24 via 10.0.0.2 dev vmbr1

Ensuite, exécuter le fichier. Assurez-vous que la route est bien correcte avec netstat -r -n.

Là on dit aux paquets destinés au réseau VPN d’aller vers la PFSense. Elle saura bien quoi en faire. Est-ce qu’on doit modifier les iptables ? Non, les paquets en transfert qui viennent de l’internet mondial sont déjà acceptés.

Alors c’est bon ?

Non.

Il faut que la PFSense accepte ces paquets aussi. Dans l’interface, on rajoute deux règles. La première dit d’accepter les paquets en UDP qui sont à destination de la PFSense sur le port du VPN :

  • Action : Pass
  • Interface : WAN
  • Address Family : IPv4
  • Protocol : UDP
  • Source : Any
  • Destination : WAN net
  • Destination port range : 18223 (mettez le port du VPN)
  • Description : Accès au VPN depuis l’internet mondial

Maintenant, vous pouvez tester le VPN. Vous devriez pouvoir vous connecter et aussi accès à l’internet mondial en étant connecté. Oubliez pas d’activer les changements après avoir créé la règle, ça m’arrive tout le temps.

Ah oui en fait non l’internet mondial ne va pas marcher. On n’a pas autorisé les paquets qui proviennent du VPN. On ajoute cette nouvelle règle :

  • Action : Pass
  • Interface : OpenVPN
  • Address Family : IPv4
  • Protocol : Any
  • Source : Network – 10.2.2.0/24
  • Destination : Any
  • Description : Accès à l’internet mondial depuis le VPN

Et voilà !

À présent, depuis le VPN, vous avez accès à :

  • L’internet mondial
  • Les services du WAN, c’est-à-dire la PFSense et le Proxmox (et le SSH vers Proxmox)
  • Le réseau LAN. Tapez par exemple 192.168.9.10 dans votre navigateur, et vous tomberez sur le serveur nginx qu’on a déployé plus tôt.

C’est pas beau ça ?

Bravo ! C’est un solide travail que vous avez fait pour en arriver là.

Le VPN vous sauvera

On pourrait s’arrêter là.. Sauf que. J’ai pas arrêté de vous dire tout le long du tuto que « Tel truc sera résolu quand on aura le VPN ». Eh bien il est temps de résoudre ces problèmes.

Protéger la PFSense

Déjà, la PFSense. À l’heure actuelle, elle est disponible sur les internets mondiaux. Si vous allez voir les logs, vous verrez plein d’individus qui s’y heurtent. C’est pas forcément très rassurant.

Et puis, est-ce qu’on a vraiment besoin d’avoir l’interface disponible à la vue de tout le monde ? Bien sûr que non.

Alors supprimez-moi cette règle qu’on avait ajouté :

Dans le doute, vous pouvez seulement désactiver la règle en cliquant sur le ✓. Ça vous évitera de la recréer complètement si vous vous êtes planté quelque part.

Vous n’aurez plus accès en tapant https://hostname.domain.name mais plutôt l’IP du LAN : https://192.168.9.254. Pour changer le domaine, il faudra mettre en place un serveur DNS interne.

Si vous retournez dans les logs, vous n’en verrez pas moins. Vous en verrez encore plus même ! Puisqu’à présent, vous verrez le blocage du port 443.

Protéger l’interface web du Proxmox

Là, on va faire pareil, mais un peu différent. À l’heure actuelle, on accède à l’interface web de Proxmox sans passer par la PFSense.

À la place, on va :

  1. Rediriger le port 8006 vers la PFSense (en supprimant l’exception dans les iptables). Ceci annulera l’accès depuis l’internet mondial.
  2. Autoriser d’accéder au port 8006 du serveur proxmox depuis la PFSense. Ceci activera l’accès depuis le VPN.

Dans le fichier des iptables, on va éditer la ligne suivante :

iptables -A PREROUTING -t nat -i $PrxPubVBR -p tcp --match multiport ! --dports 21153,8006 -j DNAT --to $PfsVmWanIP

On supprime tout simplement le 8006. Et on exécute le fichier. À présent, vous n’avez plus accès à l’interface web Proxmox du tout !

Oh, et on peut aussi supprimer ces lignes là : la règle qui accepte les paquets sur 8006 aussi, cette ligne-là :

iptables -A TCP -i $PrxPubVBR -d $PublicIP -p tcp --dport 8006 -j ACCEPT
iptables -A OUTPUT -o $PrxVmWanVBR -s $ProxVmWanIP -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT

Autrement dit :

  • On arrête d’accepter les pings dans tous les sens
  • On arrête d’accepter les paquets entrant sur 8006
  • On arrête d’accepter les paquets sortant sur le port SSH

Rappelez-vous que le serveur Proxmox n’est pas une VM ordinaire. C’est une VM avec un fichier iptables ! Il faut juste qu’on lui dise d’accepter les paquets qui viennent de la PFSense. Par où ? Par vmbr1. Rappelez-vous qu’on a condamné l’accès vmbr2. Voici la règle à rajouter dans les iptables :

iptables -A TCP -i $PrxVmWanVBR -d $ProxVmWanIP -p tcp --dport 8006 -j ACCEPT

Exécutez le fichier. À présent, vous pouvez accéder à https://10.0.0.1:8006.

Est-ce qu’on a besoin d’ajouter une règle dans PFSense ? Non ! On a déjà une règle qui dit : Depuis le VPN, on a accès à tout.

Protéger le SSH du Proxmox

Bon. Là, on pourrait faire exactement la même opération pour protéger le SSH du Proxmox. De telle sorte qu’il ne soit accessible que depuis le VPN.

Mais ça devient un peu dangereux… Qu’est-ce qui se passe si vous perdez accès au VPN ? Genre vous supprimez la config par erreur. Ou votre ordi meurt et vous n’avez pas backup la config ?

Vous allez passer un sale dimanche.

Alors il est toujours possible de résoudre le problème si votre provider vous donne un accès à la console. Je sais que chez Hetzner, c’est possible gratuitement pendant 3 heures. Mais il faut prendre rendez-vous, c’est un peu galère.

C’est pourquoi mon choix est de garder l’accès SSH sur l’internet mondial. Par contre, il faut être bien sûr d’avoir activé fail2ban.

Ah ? On me dit dans l’oreillette que le script iptables efface toutes les règles de fail2ban. Oops.

À la fin du script des iptables, on rajoute l’instruction suivante : service fail2ban restart.

Dernière petite chose : Le script iptables ne se lance pas automatiquement au boot. Donc si le Proxmox redémarre, pouf on perd toutes nos règles. C’est beta.

Pour résoudre ça, on va lancer apt install iptables-persistent. Suivez les consignes, et à présent les règles persisteront après un reboot.

Par contre, si jamais vous changez le fichier des iptables, alors lancez l’instruction iptables-save > /etc/iptables/rules.v4.

Nettoyage des règles superflues

Maintenant qu’on a le VPN, on peut supprimer quelques règles dans la PFSense.

  • Autoriser les pings ? Finis les pings ! On supprime.
  • NATer le serveur nginx ? Oui bon ça ok on garde.
  • Autoriser le SSH pour les VMs ? Plus besoin ! Le VPN a accès à tout automatiquement.
  • Accès au VPN depuis l’internet mondial ? Euuh oui ça on garde !

Au final, voici mes règles (en gris clair celles qui sont désactivées) :

Petite checklist pour vérifier que tout marche bien :

Depuis le VPN :

  • On a accès à la PFSense sur https://192.168.9.254
  • On a accès au Proxmox sur https://10.0.0.1:8006
  • On a accès au serveur web nginx sur http://192.168.9.10
  • On a accès au serveur web nginx sur l’IP publique et port 8001.
  • On peut se connecter en SSH à charles@192.168.9.10

Hors du VPN :

  • Pas d’accès à la PFSense sur https://hostname.domain.name
  • Pas d’accès au Proxmox sur https://hostname.domain.name:8006
  • On a accès au serveur web nginx sur l’IP publique et port 8001.
  • On ne peut pas se connecter en SSH à charles@192.168.9.10

Checks ? Checks !

Comment débugger

Je ne m’attends pas forcément à ce que TOUT marche dans ce tutorial.

Ça marche pour moi.

Mais vous avez une machine différente, vous êtes dans le turfu, vous avez un provider différent, vous êtes peut-être même gaucher, qui sait ! Ça me paraît plus important de vous apprendre à vous débrouiller par vous-même que vous donner une liste d’instructions à copier/coller, et puis que quand ça ne marche pas vous soyez coincé.

Je présente donc dans cette section les outils que j’ai appris et que j’ai trouvé très utiles pour débugger.

Sniffer vos paquets

Quand vous essayez de pinger un serveur, ou juste de vous y connecter, et que ça ne marche pas, c’est frustrant.

Le pointeur clignote, il se passe rien, et vous savez qu’il ne va rien se passer. Juste si vous attendez 1 minute ou 2, vous allez voir un joli "Timeout".

Ça peut être parce que le paquet s’est perdu, parce qu’il a été mangé par un pare-feu, ou même parce que le service auquel vous tentez d’accéder est hors ligne. Pour comprendre le cheminement d’un paquet, on peut utiliser tcpdump.

L’option -i permet de spécifier l’interface sur laquelle vous écoutez. Par exemple : tcpdump -i vmbr0.

L’option -p permet de spécifier le protocole que vous écoutez. Par exemple : tcpdump -p udp.

Et l’option port permet de spécifier le port. Par exemple : tcpdump port 22.

Vous allez voir, ou non, si un paquet sort ou entre de chez vous ou non. S’il ne sort pas, il est en toute vraisemblance bloqué par iptables ou le pare-feu de la machine sur laquelle vous êtes.

Vous pouvez utiliser cette instruction sur l’hyperviseur, sur une VM, et aussi sur la PFSense.

Loggez les iptables

Est-ce que le script iptable est en train de dropper les paquets que vous envoyez ?

Rajouter une instruction dans votre script avant l’instruction qui potentiellement droppe votre paquet. Par exemple, ajoutez :

iptables -A OUTPUT -o vmbr1 -s 10.0.0.1 -p tcp -j LOG

En gros l’idée c’est de remplacer la fin (ACCEPT) par LOG. Et ensuite les logs s’afficheront dans /var/log/syslog.

Utilisez les logs de PFSense

Dans l’interface de la PFsense, vous pouvez aller dans Status / System Logs, puis Firewall, pour voir toutes les connexions bloquées. La vôtre apparaît ? Il faudrait peut-être créer une règle. La vôtre n’apparaît pas ? Alors soit elle est passée, soit elle n’est même pas arrivée sur la PFSense.

Au passage, en cliquant sur le petit +, vous pouvez facilement ajouter une règle qui concerne spécifiquement la connexion qui a été bloquée.

Si vous suspectez qu’elle est passée, alors regardez par où elle est partie en sniffant les paquets de la machine. Soit avec tcpdump, soit en allant dans Diagnostics/Packet Capture.

Ah oui, et si vous venez juste de mettre à jour les règles du pare-feu.. donnez-lui quelques minutes. Ça m’est arrivé de me casser la tête sur un problème, de décider d’y revenir plus tard, et quand je suis revenu, le problème était résolu comme par magie. Il fallait juste attendre un peu.

Un problème avec le VPN ? Les logs sont dans Status / System Logs, puis OpenVPN.

Cet article Proxmox VE 6 + pfsense sur un serveur dédié (2/2) est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2020/03/09/proxmox-ve-6-pfsense-sur-un-serveur-dedie-2-3/feed/ 16 5589
Proxmox VE 6 + pfsense sur un serveur dédié (1/2) https://blog.zwindler.fr/2020/03/02/deploiement-de-proxmox-ve-6-pfsense-sur-un-serveur-dedie/ https://blog.zwindler.fr/2020/03/02/deploiement-de-proxmox-ve-6-pfsense-sur-un-serveur-dedie/#comments Mon, 02 Mar 2020 07:35:00 +0000 https://blog.zwindler.fr/?p=5550 Tutoriel de déploiement d'un serveur Proxmox VE 6 sécurisé par un serveur PFsense

Cet article Proxmox VE 6 + pfsense sur un serveur dédié (1/2) est apparu en premier sur Zwindler's Reflection.

]]>

Note : cet article a été écrit par Charles Bordet, et se veut être une version à jour de cette suite d’articles écrits sur ce blog (mais avec des versions obsolètes de Proxmox et de PFSense). Merci à lui !

Il y a un peu plus d’un an, je souscrivais pour la première fois à un VPS.

Mon objectif ?

Sortir de l’écosystème Google en auto-hébergeant mes propres services.

J’avais déjà eu l’occasion d’utiliser des serveurs sur EC2, mais de manière très ponctuelle et plutôt limitée. J’avais besoin d’une grosse machine pour faire des calculs, et 2 jours plus tard je coupais tout.

Rien à voir avec l’hébergement continu, performant et sécurisé de services comme un Nextcloud, un Gitlab, et autres applis web que je voulais m’auto-fournir.

C’était avant tout un test pour moi.

Est-ce que j’allais trouver dans le monde de l’open source suffisamment de bonnes alternatives, et est-ce que j’allais réussir à les héberger ?

Bilan au bout d’un an : J’en suis plutôt content. J’ai beaucoup appris et j’ai remplacé quasi tous les services Google.

Sauf que…

Mes services sont répartis sur plusieurs VPS, et c’est un peu le bordel. Et puis j’ai pas de backups, à part ceux proposés par Hetzner. Mes bases de données ne sont pas répliquées. Et puis.. niveau sécurité, y’avait rien.

C’est à ce moment-là que je suis retourné sur le blog qui tout au début m’avait permis de démarrer (un certain Dryusdan), et j’ai trouvé cet article : Installer un cluster hyperconvergé avec Proxmox, Ceph, Tinc, OpenVSwitch.

C’est marrant parce que je ne comprenais rien à ce titre. Et aujourd’hui.. ben c’est pas beaucoup plus clair :D

Mais l’article m’a servi de nouveau point de départ.

J’ai tapé "Proxmox" dans Google.

Je suis tombé sur https://www.proxmox.com/en/ et je n’ai même pas compris à quoi ça pouvait potentiellement servir.

Et puis, de fil en aiguille, je suis tombé sur l’article de m4vr0x : Déploiement de Proxmox VE 5 sur un serveur dédié – part 1.

Et là, j’ai compris.

Proxmox allait me servir à démarrer/arrêter mes propres VPS de manière complètement flexible, et en plus m4vr0x me présentait un tuto détaillé étape par étape pour avoir une infrastructure robuste et sécurisée.

Top !

J’ai commencé le tutoriel, et puis je me suis rapidement aperçu que ce que j’avais à l’écran n’était pas strictement identique aux étapes décrites par m4vr0x. Je me suis retrouvé à fouiller parmi les quelques 300 commentaires de l’article. Et même avec les nombreuses questions et réponses, je me suis retrouvé complètement bloqué.

Mon plus gros problème, c’est que je ne comprenais rien à ce que je faisais.

C’est quoi une gateway ? Un routeur ? iptables ? Une masquerade ? Je ne comprenais rien à ces termes et ça m’empêchait de progresser.

Alors j’ai appris.

J’ai documenté ce que je faisais. Mes expériences, mes succès, mes réussites, avec les liens vers les articles ou documentations qui m’ont apportés des solutions.

J’ai pris un cours de réseau sur OpenClassrooms que je vous conseille très fortement si vous aussi vous avez l’impression d’avoir loupé un trimestre à la fac et que iptables n’était même pas parmi les langues étrangères proposées.

Et deux mois plus tard… ça y est.

J’ai mis en place mon serveur dédié avec l’hyperviseur Proxmox.

Il est sécurisé par PFSense.

Certains services sont accessibles sur l’internet mondial, et d’autres seulement via le VPN privé, selon l’usage.

Et mon objectif du jour, c’est de reprendre le tutoriel de m4vr0x, le remettre au goût du jour de 2020, et aussi de détailler les étapes où je me suis retrouvé bloqué, afin que vous ne le soyez pas.

Mon gros problème quand j’ai commencé à rentrer dans ce monde de l’administration système, c’était le langage. Imaginez lire le code des impôts. Vous comprenez rien. Par contre, quand vous allez sur service-public.fr, on vous explique la loi avec des termes plus simples de tous les jours.

Cet article, je l’adresse aussi à mon moi d’il y a deux mois qui ne comprenait rien à ces termes.

D’ailleurs, je me présente rapidement : Je m’appelle Charles, je suis data scientist, et mon objectif est aussi d’utiliser ce serveur pour mes analyses de données et mes outils professionnels.

Prêt ? C’est parti !

L’architecture

Sans surprise, je vais reprendre l’architecture proposée par m4vr0x et son magnifique schéma : Infrastructure Proxmox

Ça c’est notre objectif final qu’on détaillera un peu plus tard.

Proxmox VE

Proxmox, c’est une solution d’hyperviseur, de virtualisation, qui s’installe sur un serveur dédié. À la place d’avoir une Debian classique, vous avez une Debian légèrement modifiée qui vous donne Proxmox. Donc Proxmox, c’est avant tout un OS.

C’est opensource et gratuit.

Ce que j’aurais aimé qu’on me dise dès le début, c’est que Proxmox, c’est un peu comme VMware ou VirtualBox. On l’installe, et ensuite on peut créer des machines virtuelles dont on configure les composants comme on veut.

PFSense

PFSense, c’est aussi un OS complet, cette fois-ci basé sur FreeBSD, qui va nous servir de pare-feu, de routeur, et aussi de VPN. Je suis sûr qu’il y a plein d’autres choses qu’on peut faire avec PFSense.

Au début, je me demandais pourquoi utiliser PFSense alors que jusqu’ici j’utilisais toujours ufw qui était pas mal. En plus, Proxmox propose lui aussi des fonctionnalités de pare-feu.

Déjà un intérêt c’est que PFSense filtre les paquets avant qu’ils arrivent sur la VM. Alors que ufw (ou iptables, c’est pareil) regarde les paquets une fois qu’ils sont sur la VM. Subtile différence.

Ensuite, c’est une solution complète avec une belle interface qui va faire plus qu’un firewall basique.

  • La PFSense permet d’isoler le réseau local (LAN) qui va contenir toutes les VMs de l’internet mondial.
  • La PFSense a une belle interface qui permet d’aller voir les logs, extraire les paquets (très utile pour débugger !), et paramétrer tout ce qui a besoin de l’être.
  • La PFSense est remplie d’outils utiles : Routeur, serveur DHCP, VPN, DNS, et sûrement d’autres que je ne comprends pas mais qui seront utiles plus tard pendant la vie d’adulte.

Le hardware

Pas de comparaison de différents providers ici.

Pour ma part, j’utilise Hetzner depuis le début, et c’est eux que j’ai choisi pour mon serveur dédié, notamment via le Server Auction.

J’ai pris une grosse machine avec :

  • un Intel Xeon E5-1650V3
  • 2 HDD de 4 To
  • 256 Go de RAM
  • 1 IP publique (pas de failover pour le moment mais ça ne change strictement rien à ce tuto)

Tout ça pour environ 85€/mois. Bon plan ? Mauvais plan ? En vrai j’en sais trop rien. Je tenais à avoir beaucoup beaucoup de RAM parce que j’en ai régulièrement besoin pour mes analyses de données.

Le seul hic c’est que comme le serveur est hébergé en Allemagne, quand je me connecte au VPN tout l’internet passe en allemand.

L’installation

Hetzner ne propose pas directement d’image Proxmox, ce qui est un peu dommage. Les pages d’aide proposent de partir d’une Debian et d’upgrader vers Proxmox tout à la main. Franchement pas évident.

Heureusement, il existe une image non officielle que j’ai utilisée et avec laquelle tout s’est très bien passé.

Pour ça, il suffit de démarrer le serveur en mode Rescue (on peut l’activer à tout moment dans l’interface).

Une fois connecté en SSH, on accède aux images avec l’utilitaire installimage. Dans la liste des OS proposés, choisissez « Other (!!NO SUPPORT!!) ». Oui hein c’est pas très rassurant tous ces points d’exclamation. Mais faites-moi confiance.

C’est là que les images Proxmox apparaissent. J’en ai 3 pour Jessie, Strech, et Buster, qui correspondent respectivement à Debian 8, 9, et 10. Évidemment on va prendre Buster.

Ensuite, un éditeur va s’ouvrir pour choisir la configuration du Proxmox.

HARD DISK DRIVE(S)

Ici je ne touche à rien, je monte mes deux HDDs :

DRIVE1 /dev/sda
DRIVE2 /dev/sdb

SOFTWARE RAID

Ici je laisse les valeurs par défaut aussi, ce qui me donne un Software RAID 1 :

SWRAID 1
SWRAIDLEVEL 1

HOSTNAME

Ici, on demande spécifiquement un FQDN. Par exemple : proxmox.example.com. Vous pouvez d’ailleurs dès maintenant paramétrer vos DNS pour qu’ils redirigent vers ce FQDN.

PARTITIONS

Et finalement, la partie la plus marrante, on crée les partitions.

L’idée c’est d’avoir une partition pour le boot, et une partie pour LVM (Logical Volume Management). Moi ce que je comprends c’est que LVM est un système de partitionnement qui est plus flexible que la méthode traditionnelle et donc plus adaptée pour ce qu’on veut faire.

Ensuite, dans la partie LVM, je mets une partition swap et tout le reste pour mon utilisation future.

Au final, ça donne :

PART /boot ext3 512M
PART lvm vg0 all
LV vg0 swap swap swap 2G
LV vg0 root / ext4 all

OPERATING SYSTEM IMAGE

Là on change rien. Hetzner a déjà pré-rempli avec l’image Proxmox qu’on souhaite utiliser.

Pour sortir de ce fichier, on peut faire F10. Bon ça marche pas chez moi, à la place j’ai le menu "File" de ma console qui se déroule. Du coup je fais deux fois Échap et ça marche aussi. On enregistre évidemment.

Et l’installation va se faire toute seule.

Si vous avez fait une bêtise, pas d’inquiétude. Redémarrez le serveur en mode Rescue et placez-vous sur la case départ (vous ne toucherez rien du tout par contre).

Une fois l’installation terminée, redémarrez, puis vous aurez accès à l’interface de Proxmox à l’adresse https://proxmox.example.com:8006 (changez avec votre FQDN bien entendu !).

Première ligne de sécurité

Le serveur SSH

Votre serveur est up.

Et déjà il est attaqué.

S’il y a un truc que j’ai appris ces deux derniers mois, c’est qu’il y a des tonnes de bots dont le seul objectif est de parcourir toutes les IPv4 (ça se fait en quelques heures) et de toquer à la plupart des ports classiques.

Maintenant imaginez qu’un bot tombe sur un prompt où on lui demande un mot de passe. Que va-t-il faire ? Bruteforcer le mot de passe bien sûr !

J’ai redémarré mon serveur à 06:39:35, et à 06:40:09 je recevais ma première attaque.

La première chose que je fais, c’est sécuriser le serveur SSH :

  • Je crée un nouvel utilisateur principal avec un accès sudo
  • J’interdis de se connecter directement à root en SSH
  • J’interdis de se connecter avec un mot de passe en SSH
  • Je change le port du SSH. Prenez un port aléatoire après 1000 (en général je regarde l’heure qu’il est et ça me donne un numéro de port)

Voici les commandes :

# adduser tomtom
# usermod -aG sudo tomtom
# su - tomtom
# mkdir ~/.ssh
# chmod 700 ~/.ssh
# vim ~/.ssh/authorized_keys # là j'ajoute ma clé SSH
# chmod 600 ~/.ssh/authorized_keys

Puis je modifie le fichier /etc/ssh/sshd_config avec les options suivantes :

Port 21153
PermitRootLogin no
PasswordAuthentication no

Et puis on redémarre le serveur SSH : /etc/init.d/ssh restart. Pro tip : Assurez-vous bien de pouvoir vous connecter avec l’utilisateur que vous venez de créer. Sinon, vous êtes bon pour reprendre de zéro :D

Juste avec ça, vous devriez voir le nombre d’attaques dans /var/log/auth.log drastiquement se réduire.

Mais ça ne suffit pas et ça ne protège pas d’une attaque bruteforce. Pour ça, il va falloir installer fail2ban. Cet outil va lire les logs, identifier un attaquant (quelqu’un qui essaie de forcer la porte d’entrée) et bannir son IP. On peut le configurer pour le SSH mais aussi pour plein d’autres outils !

On l’installe avec apt install fail2ban. Puis on crée un nouveau fichier /etc/fail2ban/jail.local avec la configuration suivante :

[DEFAULT]

bantime = 84600
findtime = 600
maxretry = 3

destemail = tomtom@example.com
sendername = Fail2ban

action = %(action_mwl)s

[sshd]
enabled = true
port = 21153

En fait c’est surtout la dernière partie qui est obligatoire. Il faut activer l’outil pour le SSH, et spécifier le port que vous avez modifié précédemment. Et n’oubliez pas de redémarrer le service : systemctl restart fail2ban.

Testez alors si ça marche en essayant de vous connecter depuis une autre IP que la vôtre. Bah oui sinon vous allez vous bannir vous-même. Donc utilisez un VPN ou bien connectez-vous en premier sur un serveur distant, et depuis ce serveur distant, essayez de vous faire bannir.

Comment voir si ça marche ? Regardez les logs /var/log/auth.log et /var/log/fail2ban.log.

Configurer votre serveur SMTP

Normalement vous devriez recevoir des emails de la part de fail2ban (avec la configuration ci-dessus).. si vous avez configuré postfix, qui vient de base avec Proxmox.

Si vous avez suivi jusque là, il y a de bonnes chances pour que vous n’y ayez pas encore touché. Là on le fait pour fail2ban, mais Proxmox peut aussi vous notifier de certains événements importants, donc c’est une étape importante, pas seulement pour fail2ban.

Lancez donc un dpkg-reconfigure postfix et choisissez les options suivantes :

  • Internet Site.
  • System mail name = proxmox.example.com.
  • Postmaster mail recipient = tomtom.
  • Other destinations to accept mail from : Laissez les valeurs par défaut, c’est-à-dire : proxmox, proxmox.example.com, proxmox.example.com, localhost.example.com, localhost.
  • Force synchronous updates on mail queue? Non.
  • Local networks = On laisse par défaut.
  • Mailbox size limit = 0
  • Local address extension character = +
  • Internet Protocols = all

La console va vous parler, puis redémarrez le service avec systemctl restart postfix.

L’interface Proxmox

Ensuite j’aime bien créer encore un autre utilisateur, qui lui n’aura pas d’accès sudo, et qui sera réservé à Proxmox.

Après avoir tapé adduser proxmox, il faudra vous connecter en root sur l’interface Proxmox et ajouter l’utilisateur dans Datacenter / Permissions / Users.

Pour lui donner des accès, vous pouvez taper les commandes suivantes (tirées de la documentation : User Management) :

pveum groupadd admin -comment "System Administrators"
pveum aclmod / -group admin -role Administrator
pveum usermod proxmox@pam -group admin

Vous pouvez restreindre ces accès à tout moment.

Pendant que vous êtes connectés avec root, vous pouvez aussi en profiter pour placer un certificat Let’s Encrypt et éviter d’avoir l’avertissement du navigateur pour le HTTPS. Plus de détails ici : Signez l’UI de Proxmox VE avec Let’s Encrypt, c’est (encore plus) trivial

Voilà.

Maintenant, on n’aura plus besoin de root. On peut se déconnecter et tout faire avec le nouvel utilisateur.

Et voilà ! Maintenant, on a une belle interface, ouverte à l’internet entier, avec un petit écran de logi… hein quoi ? Eh ouais, on peut se faire bruteforce le Proxmox là ! D’ailleurs c’est peut-être en train d’arriver en ce moment même !

Retour sur fail2ban

Cette fois-ci on ne va pas changer le port par défaut parce que… Proxmox ne permet pas de le configurer.

Notez aussi que cette étape est un peu optionnelle dans le sens où dans le futur, on pourra bloquer l’ouverture de Proxmox sur le monde réel et ne pouvoir y accéder que depuis le VPN.

Mais j’ai tendance à penser qu’on n’est jamais trop prudent…

Retournez dans le fichier /etc/fail2ban/jail.local et ajoutez la configuration suivante :

[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
logpath = /var/log/daemon.log

Et on ajoute la partie suivante dans le fichier /etc/fail2ban/filter.d/proxmox.conf :

[Definition]
failregex = pvedaemon[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =

Cette deuxième partie, elle sert justement à repérer les messages d’erreurs causés par les méchants qui essaient de se connecter.

Et on oublie pas de redémarrer fail2ban.

Là pour tester c’est un peu plus compliqué que pour le SSH, mais par exemple vous pouvez essayer de le faire depuis votre téléphone (pas sur la connexion wifi hein !).

Bon. On a bien avancé. Mais on n’a pas fait grand chose non plus.

Configuration du réseau

Dans cette partie, mon objectif est vraiment de reprendre exactement le schéma de m4vr0x :

Infrastructure Proxmox détaillée

Le truc de base à garder en tête, c’est qu’en frontal, on a l’hyperviseur. C’est incontournable.

On doit forcément passer par l’hyperviseur pour atteindre une VM.

Du coup, si notre pare-feu EST une VM, ben… ça casse un peu tout le délire. C’est un peu comme si le gardien du château était au fond du jardin.

C’est pour ça que notre objectif, ça va être de router automatiquement TOUT le trafic vers la VM pare-feu. Donc vers la PFSense.

En temps normal, on devrait avoir la PFSense en frontal, et derrière elle on aurait le réseau local.

C’est pourquoi la PFSense est connectée à deux réseaux :

  • Le WAN
  • Le LAN

J’ai mis du temps à comprendre ça en lisant le tuto de m4vr0x, mais en fait le WAN c’est censé être l’internet mondial, et le LAN c’est tout le réseau local avec les machines qui sont cachées derrière la PFSense. Et entre les deux, il y a la PFSense.

Du coup on essaie de reconstituer ce schéma dans notre situation un peu biscornue.

En routant tout le trafic automatiquement de l’hyperviseur vers la PFSense, c’est un peu comme si la PFSense était en frontal.

Et ce petit router tout le trafic automatiquement se traduit en une LONGUE série d’instructions iptables.

Voilà.

Allez, on y va.

Paramétrage des interfaces virtuelles

Déjà, on crée les réseaux WAN et LAN.

Connectez-vous sur votre interface Proxmox https://proxmox.example.com:8006 (avec votre utilisateur spécial, pas le root !), cliquez sur votre node, puis System > Network :

Créer les interfaces bridge pour Proxmox

Sur son tuto, m4vr0x avait 2 interfaces (2 NIC on dit). Moi avec Hetzner j’en ai qu’une. Au début j’ai cru que c’était game over pour moi. En fait non, 1 seule suffit. C’est comme pour lotus.

Juste un petit conseil. On fait un petit backup des interfaces comme elles ont été configurées par le provider d’abord : cp /etc/network/interfaces /etc/network/interfaces.bak.

On crée un premier bridge en cliquant sur Create/Linux Bridge et on remplit comme suit :

  • Name : vmbr0
  • IPv4/CIDR : Choisissez l’IP qui était auparavant sur votre interface NIC. En gros c’est votre IP publique. Il faut aussi ajouter le CIDR.
  • Gateway (IPv6) : Idem, choisissez la Gateway qui était sur l’interface NIC.
  • IPv6/CIDR : Idem que pour l’IPv4. J’ai pris le choix d’en mettre une, comme Hetzner m’en a fourni une. Je me dis qu’en 2020 y’a plus d’IPv4 disponible, donc y’a un moment va falloir s’y mettre.
  • Gateway (IPv6) : Idem.
  • Autostart : On coche.
  • VLAN aware : On laisse décoché.
  • Bridge ports : Là vous mettez le nom de votre première interface. Celle dont vous avez extrait l’IP et la Gateway.
  • Comment : L’internet mondial.

Si jamais vous ne savez pas ce que c’est que le CIDR ou la Gateway, c’est là que je vous recommande très chaudement le cours d’OpenClassrooms que je citais au début. Franchement, vous n’en ressortirez que plus compétent sur les réseaux et ce sont quelques heures investies qui vous en feront gagner beaucoup d’autres plus tard.

Je remets discrètement le lien ici : Apprenez le fonctionnement des réseaux TCP/IP

Et si vous avez juste oublié comment calculer le CIDR à partir de votre masque, vous pouvez utiliser cette table de correspondance.

Là, si vous validez, vous aller avoir un message d’erreur. Il faut au préalable supprimer les infos IP/Gateway de l’interface du NIC. En plus si vous laissez l’IP sur le NIC et le bridge, vous allez avoir des problème (j’en sais quelque chose).

Pour être 100% honnête, je ne suis pas sûr que ce bridge soit indispensable. Je ne vois pas trop ce qu’il apporte de plus par rapport à directement utiliser l’interface NIC. Là c’est un peu comme si on mettait une double porte pour rentrer chez soi.

Ensuite, un deuxième bridge. Celui-ci sera un bridge "virtuel", ça veut dire qu’il ne sera connecté sur aucune réelle interface NIC. On va avoir un premier bridge virtuel qui donnera sur le réseau WAN, et un deuxième bridge virtuel qui donnera sur le réseau LAN. C’est une manière de créer des réseaux privés distincts.

Imaginez qu’on crée une première porte virtuelle qui mène vers le monde de WAN, et une deuxième porte virtuelle qui mène vers le monde de <s>Jumanji</s> LAN.

Pour ce deuxième bridge, on rentre :

  • Name : vmbr1
  • IPv4/CIDR : 10.0.0.1/30.
  • Comment : WAN

m4vr0x rentrait la valeur "WAN" dans bridge port. Mais en fait 1) je crois que ça n’était pas utile, et 2) Proxmox 6 vous empêche d’assigner une interface qui n’existe pas. Si vous tenez vraiment à le faire, il faudra éditer à la main le fichier /etc/network/interfaces.

Je le mets quand même dans Comment parce que c’est utile pour s’en rappeler.

Pour l’IP, on utilise un CIDR = 30 pour être sûr de n’avoir que 2 IPs de disponible. Oui, on évite de se donner une plage avec des millions d’IPs si on n’en a pas besoin. Là, si jamais un brigan arrive à se relier je-ne-sais-comment au réseau WAN, eh bien il ne pourra pas avoir d’IP.

Et finalement le dernier bridge :

  • Name : vmbr2
  • IPv4/CIDR : 192.168.9.1/24.
  • Comment : LAN

Ici c’est un peu pareil, mais on se laisse la possibilité d’avoir 256 IPs, puisqu’on ne sait pas combien de machines virtuelles on va avoir exactement.

Allez, on valide en cliquant sur Reboot tout en haut de l’interface.

C’est peut-être le moment de vous montrer une petite astuce si jamais vous vous êtes planté. En fait, quand j’ai suivi le tuto de m4vr0x, j’ai réussi à m’enfermer dehors de mon serveur une bonne dizaine de fois.

La solution, pour Hetzner, c’est de passer en mode Rescue, puis de monter le volume LVM en suivant les instructions de cette page d’aide. Par exemple, l’idée ça pourrait être de remettre le fichier /etc/network/interfaces dans son état initial.

L’idée, c’est que même si j’ai l’impression que mon tutorial est fail-proof, je suis sûr qu’il ne l’est pas. C’est probablement impossible de l’être. Par contre, on peut apprendre les outils pour réparer nos conneries. Et ça nous rend confiant pour essayer des trucs.

Bon allez. On vérifie son contenu de /etc/network/interfaces et on passe à la suite :

auto lo
iface lo inet loopback

iface lo inet6 loopback

auto enp4s0
iface enp4s0 inet manual
    up route add -net xx.xx.xx.xx netmask 255.255.255.224 gw xx.xx.xx.xx dev enp4s0

auto vmbr0
iface vmbr0 inet static
    address  xx.xx.xx.xx
    netmask  27
    gateway  xx.xx.xx.xx
    bridge-ports enp4s0
    bridge-stp off
    bridge-fd 0
#L'internet mondial

iface vmbr0 inet6 static
    address  xx:xx:xx::xx
    netmask  64
    gateway  fe80::1

auto vmbr1
iface vmbr1 inet static
    address  10.0.0.1
    netmask  30
    bridge-ports none
    bridge-stp off
    bridge-fd 0
#WAN

auto vmbr2
iface vmbr2 inet static
    address  192.168.9.1
    netmask  24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
#LAN

Notez que j’ai une règle de routage au début avec la ligne qui commence par up route add. Cette ligne était déjà là avant, alors je n’y ai pas touché.

Déploiement de PFSense

On va télécharger la dernière version sur le site : PFSense. Moi j’ai pris une architecture AMD64 et l’ISO.

Évidemment on vérifie le checksum. Ça sert à rien de passer des heures sur la sécurité si on télécharge un fichier trafiqué. Je suis sympa je vous donne même la commande : openssl dgst -sha256 Downloads/pfSense-CE-2.4.4-RELEASE-p3-amd64.iso.gz.

Puis on l’upload dans le volume de stockage local sur l’interface de Proxmox.

Si comme moi vous avez une connexion un peu pourrite, on peut aussi le télécharger directement sur le serveur :

cd /var/lib/vz/template/iso
wget https://nyifiles.pfsense.org/mirror/downloads/pfSense-CE-2.4.4-RELEASE-p3-amd64.iso.gz 
openssl dgst -sha256 pfSense-CE-2.4.4-RELEASE-p3-amd64.iso.gz
gunzip pfSense-CE-2.4.4-RELEASE-p3-amd64.iso.gz

Et pouf l’ISO va apparaître dans votre interface.

Maintenant on lance une VM (et pas un CT).

General

  • Node : Choisissez votre node.
  • VM ID : On peut laisser la valeur par défaut (100 normalement).
  • Name : PFSense.

OS

  • Use CD/DVD disc image file (iso) : Storage = local et ISO image est le fichier qu’on vient d’uploader.
  • Guest OS = Linux 5.x

System

  • Graphic card : VMware compatible
  • SCSI Controller : VirtIO SCSI

Hard Disk

  • Bus/Device : VirtIO Block / 0.
  • Storage : local.
  • Disk size : 8 GB.
  • Format : QEMU

CPU

  • Sockets : 1
  • Cores : 2

Si vous voulez vous pouvez mettre plus de cœurs. Je ne pense pas que ça change grand chose étant donné que la VM ne va pas être gourmande du tout.

Memory

  • Memory : 512.

Idem, vous pouvez mettre plus, mais pour commencer vous pouvez très bien mettre cette valeur et l’augmenter plus tard si le besoin s’en fait ressentir.

Network

  • Bridge : vmbr1
  • Model : Intel E1000 ou VirtIO

Pour ce dernier point, ça dépend si vous aimez les problèmes ou non. Intel E1000 semble fonctionner. VirtIO aussi mais sous certaines conditions. En fait, je me suis retrouvé avec des VM qui pouvaient pinger l’internet mondial mais les requêtes tcp/udp ne passaient pas. Ça m’a rendu fou.

On y reviendra. Moi j’ai pris VirtIO.

Pour l’instant, on valide.

La PFSense a besoin d’être connectée à 2 interfaces réseau : Le WAN et le LAN. Bah oui puisque c’est justement elle qui va faire le lien entre les deux interfaces. Pour l’instant, elle n’est connectée que à vmbr1, qui correspond au WAN.

Cliquez sur la VM, puis Hardware, et "Add/Network Device". Choisissez vmbr2 et le même modèle que vous aviez choisi pour vmbr1.

Maintenant on peut démarrer la VM.

Installation de PFSense

En allant sur Console, vous allez pouvoir afficher l’écran de la machine.

Choisissez Install pfSense.

Ensuite, on vous demande votre disposition clavier. Vous pouvez sélectionner ce que vous voulez, de toute façon après il vous remet en qwerty (sympa).

Pour le partitionnement, choisissez Auto: Guided Disk Setup, sauf si vous êtes un expert.

Les choses vont alors se faire toutes seules, jusqu’à :

Dites-lui non, puis rebootez.

Après le reboot, choisissez de ne pas configurer de VLAN :

Pour la WAN interface, choisissez l’interface vtnet0, qui est l’équivalent de vmbr1.

Pour la LAN interface, choisissez l’interface vtnet1, qui est l’équivalent de vmbr2.

On arrive alors sur le menu principal de la PFSense. Ce menu bien moche, c’est l’écran d’accueil. Oui oui. Rassurez-vous, plus tard on aura une interface web bien plus jolie. Pour l’instant, tapez 2 pour assigner des adresses IP à vos interfaces :

Pour le WAN, on va lui donner :

  • DHCP : no
  • IPv4 : 10.0.0.2
  • Subnet bit count : 30
  • Upstream gateway address : 10.0.0.1
  • DHCP6 : no
  • IPv6 : Rien (appuyez sur Entrée)
  • Do you want to revert HTTP as the webConfigurator protocol? no

L’écran principal va réapparaître. De nouveau on tape 2, et cette fois-ci on configure le LAN :

  • IPv4 : 192.168.9.254
  • Subnet bit count : 24
  • Upstream gateway address : Rien (appuyez sur Entrée)
  • IPv6 : Rien (appuyez sur Entrée)
  • Activer le serveur DHCP : No
  • Do you want to revert HTTP as the webConfigurator protocol? no

Finalement, on nous annonce que le webConfigurator est disponible à l’adresse https://192.168.9.254. On va donc s’y connecter pour continuer la configuration.

… Quoi ? … Ça ne marche pas ? … Sûr ? … C’est con …

Oui je reprends les blagues de m4vr0x, et alors :D ?

Bon l’idée c’est juste qu’on a un réseau local ici, donc non on ne peut pas y accéder depuis l’internet mondial. Il faut être dans le LAN pour y accéder. Les machines qui sont dans le LAN sont l’hyperviseur et la PFSense. Et les deux.. n’ont pas d’interface graphique.


Petit debugging tip. Normalement, là où vous en êtes, vous devriez être capable de pinger l’hyperviseur depuis la PFSense. À partir du menu principal, tapez 7 puis l’IP de l’hyperviseur (10.0.0.1). Le ping devrait fonctionner.

Par contre, si vous essayez de pinger la PFSense, ça ne va pas marcher. En effet, par défaut, la PFSense est inaccessible depuis le WAN. Parce que le WAN, c’est l’internet mondial, c’est le monde dangereux. Dans notre cas particulier, le WAN c’est seulement l’hyperviseur pour l’instant, mais plus tard, tout le trafic de l’internet mondial viendra de l’interface du WAN.

Donc quand on ping depuis la PFSense, ça marche parce que c’est la PFSense qui initie la connexion, donc en face on sait qu’on a un copain, donc on accepte sa réponse de ping.

Mais quand on ping vers la PFSense, ça ne marche pas parce qu’elle ne vous connaît pas et elle ne parle pas aux inconnus.

J’ai mis des semaines à comprendre ça, et de nombreuses personnes n’en plaignaient dans les commentaires, donc ça me semblait important de faire cette parenthèse.


Du coup, comment on va accéder à cette interface web ?

On va devoir créer une machine dans le réseau LAN qui dispose d’une interface graphique. Par exemple, une simple Ubuntu Desktop. Téléchargeons-la directement depuis le serveur :

cd /var/lib/vz/template/iso
wget http://releases.ubuntu.com/18.04.4/ubuntu-18.04.4-desktop-amd64.iso

Puis, on crée une nouvelle VM avec le paramétrage suivant.

General

  • Node : Choisissez votre node.
  • VM ID : On peut laisser la valeur par défaut (101 normalement).
  • Name : UbuntuDesktop.

OS

  • Use CD/DVD disc image file (iso) : Storage = local et ISO image est le fichier qu’on vient d’uploader.
  • Guest OS = Linux 5.x

System

  • Graphic card : VMware compatible
  • SCSI Controller : VirtIO SCSI

Hard Disk

  • Bus/Device : VirtIO Block / 0.
  • Storage : local.
  • Disk size : 25 GB.
  • Format : QEMU

On peut mettre moins de storage mais il faut garder à l’idée que c’est une VM temporaire de toute façon. Une fois que tout sera en place, on pourra la détruire.

CPU

  • Sockets : 1
  • Cores : 4

Memory

  • Memory : 4096.

Pareil, on peut mettre moins de mémoire RAM.

Network

  • Bridge : vmbr2
  • Model : Intel E1000 ou VirtIO

Là évidemment on se plante pas ! La VM et toutes les autres VM qu’on créera seront toujours sur le vmbr2, donc le LAN ! Et là vous êtes content d’avoir écrit WAN ou LAN en commentaires du bridge puisque ça vous évite de vous perdre.

De toute façon, si vous vous branchez sur le WAN, il n’y aura pas d’IP disponible.

Je passe sur les détails de l’installation de Ubuntu, elle n’est vraiment pas compliquée.

Ce qui est important, c’est de vous paramétrer une IP, étant donné qu’il n’y a pas de serveur DHCP pour vous en assigner une automatiquement.

Allez dans les Paramètres puis choisissez Réseau. Activez la connexion, et dans les paramètres, l’onglet IPv4, rentrez les paramètres suivants :

  • IPv4 Method = manuel
  • Address = 192.168.9.10
  • Netmask = 255.255.255.0
  • Gateway = 192.168.9.254
  • DNS = 1.1.1.1

Et là, c’est bon !

Comment ça l’accès internet ne marche pas ?!

Évidemment qu’il ne marche pas ! Suivez un peu. On a une VM qui est connectée au réseau LAN seulement. Le réseau LAN est-il relié à l’internet mondial ? Seulement à travers la PFSense. Et comme la PFSense bloque tout, on n’a pas accès.

Par contre, vous devriez être capable de pinger l’hyperviseur et la PFSense avec ping 192.168.9.1 et ping 192.168.9.254.

Et finalement, vous allez même pouvoir vous connecter à l’interface web de la PFSense en ouvrant une page web et en tapant https://192.168.9.254/.

Cette interface n’est pour le moment accessible que depuis le réseau local. Et heureusement, parce que par défaut, les identifiants sont :

  • Username = admin
  • Password = pfsense

Au démarrage, l’appli vous propose un wizard de configuration. Suivez simplement les consignes.

  • Hostname : Correspond à la partie avant le domaine. Par exemple, dans proxmox.example.com, l’hostname c’est proxmox.
  • Domain : Et le domaine, c’est l’autre partie restante.
  • DNS : 1.1.1.1

Le reste peut être laissé par défaut, jusqu’à l’étape 4 sur l’interface WAN. Normalement tout est bien pré-rempli. Toutefois, détail important, il faut désactiver la case Block RFC1918 Private Networks.

Cette option permet de bloquer les paquets qui parviennent d’un réseau privé d’entrer par l’interface WAN. Un réseau privé, c’est un réseau dont l’IP commence par 10, 172.16, ou 192.168. Et comme notre WAN est justement sur un réseau privé, eh bien cette option bloque tout.

En temps normal, le WAN correspond à l’internet mondial. Dans notre cas spécifique, ce n’est pas le cas, et on doit donc décocher cette case.

Continuez puis finissez par changer le mot de passe de l’admin.

À la fin, on vous propose de vérifier si une mise à jour. Vous pouvez essayer…

… sauf que vous n’avez toujours pas accès à l’internet sur votre VM ! (suivez un peu)

Il reste maintenant la partie la plus fun : Envoyer tout le trafic sur la PFSense, configurer PFSense et déployer une application.

Et vous l’aurez dans dans le prochain épisode !

Cet article Proxmox VE 6 + pfsense sur un serveur dédié (1/2) est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2020/03/02/deploiement-de-proxmox-ve-6-pfsense-sur-un-serveur-dedie/feed/ 3 5550
Transparent Hugepages : mesurer l’impact sur les performances https://blog.zwindler.fr/2020/02/24/transparent-hugepages-mesurer-limpact-sur-les-performances/ https://blog.zwindler.fr/2020/02/24/transparent-hugepages-mesurer-limpact-sur-les-performances/#comments Mon, 24 Feb 2020 07:30:00 +0000 https://blog.zwindler.fr/?p=5514 Comprendre à quoi servent et mesurer l'impact des Transparents Hugepages sous Linux

Cet article Transparent Hugepages : mesurer l’impact sur les performances est apparu en premier sur Zwindler's Reflection.

]]>

Encore les Transparent Hugepages ?

Il y a quelques jours, j’ai posté un article pour vous aider à désactiver les Transparent Hugepages.

A là suite de ça, Seboss666 (qui tient un super blog bien Geek/sysadmin comme j’aime) m’a fait remarquer en commentaire que j’expliquais surtout comment désactiver les THP. Mais je n’ai pas beaucoup parlé d’à quoi ça sert (à part que c’est mal aimé, comme SELinux) et si ça a vraiment un impact sur les perfs.

Il m’a passé un article hyper intéressant, en anglais, sur le sujet. Comme je ne l’aurais pas mieux écris moi-même ET que le but du blog est d’être une ressource francophone, j’ai donc proposé à l’auteur, Alexandr Nikitin, de le traduire en français. Le voilà donc.

Introduction

TL;DR ce post a pour but d’expliquer en un mot ce que sont les Transparent Hugepages (THP), décrire les techniques qui seront utilisées pour mesurer leur impact sur les performances et enfin, montrer leur effet sur une application réelle.

Il est inspiré par un thread a propos des Transparent Huge Pages sur le "Mechanical Sympathy group". Ce thread expose les pièges, les problématiques de performances ainsi que l’état actuel dans les dernières versions du kernel. Une grosse quantité d’information peut y être trouvé.

En général, vous allez trouver beaucoup de recommendations sur Internet à propos des Transparent Hugepages. La plupart d’entre eux vous diront de désactiver totalement les THP, comme Oracle Database, MongoDB, Couchbase, MemSQL, NuoDB. Certains logiciels utilise la fonctionnalité, comme par exemple PostgreSQL (la fonctionnalité hugetlbpage, pas exactement les THP) et Vertica. Il existe beaucoup de retours d’expériences de professionnels qui ont eu à se battre contre des freeze de leur système et l’ont "corrigé" simplement en désactivant les THP. 1, 2, 3, 4, 5, 6. Toutes ces histoires tendent à propager une vision faussée et le préjugé que cette fonctionnalité est dangereuse.

Malheureusement, je n’ai pas trouvé de post qui mesure ou montre comment mesurer l’impact et les conséquences d’activer ou de désactiver cette fonctionnalité. C’est ce que ce post va tenter de répondre.

Les Transparent Hugepages en bref (presque)

Pour fonctionner, presque toutes les applications et les systèmes d’exploitation nécessitent de la mémoire "virtuelle". La mémoire virtuelle de tous les logiciels est ensuite mappée dans la mémoire physique. Ce mapping est géré par le système d’exploitation, qui maintient une structure de donnée en RAM (page table). Pour passer de l’adresse virtuelle à l’adresse physique (page table walking), on utilise un composant du CPU (la MMU). En plus de servir de table de traduction, la MMU sert également de cache des pages récemment utilisées. On appelle ce cache le Translation lookaside buffer (TLB).

Lorsqu’une adresse virtuelle doit être traduite dans une adresse physique, on cherche d’abord dans le TLB. Si un résultat est trouvé (TLB hit), l’adresse physique est retournée et l’accès à la mémoire peut continuer. Cependant, si on ne trouve pas de résultat (TLB miss), la MMU va devoir rechercher le mapping de l’adresse dans la table de pages (page table) si il existe.

Ce processus de "page table walk" est coûteux en temps car il peut nécessiter plusieurs accès à la mémoire (cependant, avec de la chance on peut retrouver la page mémoire dans un des caches L1/L2/L3 du CPU). Cependant, on ne peut pas non plus compter tout le temps sur le TLB car sa taille est limitée (généralement quelques centaines de pages, au maximum).

Les systèmes d’exploitation gèrent la mémoire virtuelle en utilisant des pages (des blocks contigus de mémoire). Généralement, la taille d’une page mémoire est de 4 Ko. Petite règle de trois, 1 Go de RAM équivaut à 256000 pages, et 128 Go à 32,7 millions de pages. Clairement, on ne va pas pouvoir tout stocker dans le TLB et nous allons donc souffrir de problèmes de performances à cause des "TLB miss". Il y a deux façons d’améliorer cette situation. La première est d’augmenter la taille du TLB. Cependant, c’est coûteux et l’impact n’est pas significatif, surtout sur les systèmes disposant d’une très grande quantité de RAM. La seconde consiste à augmenter la taille d’une page est ainsi, avoir moins de pages à mapper. Les OS et les CPUs modernes sont typiquement capable de supporter des pages "larges" de 2 Mo, voire même de 1 Go. Ainsi, avec des pages de 2 Mo, 128 Go de RAM devient seulement 64000 pages.

Ce n’est pas pour rien que Linux supporte les Transparent Hugepages. C’est une optimisation ! Cela permet de gérer un grand nombre de pages de manière automatique et transparente pour les applications. Les bénéfices sont évidents : pas de modification à faire du coté des application, le nombre de "TLB miss" est réduit, le "page table walking" devient moins coûteux. Cette fonctionnalité peut être découpée en deux parties : allocation et maintenance.

Le THP fonctionne de la même manière pour ce qui est de l’allocation de la mémoire et nécessite que le système d’exploitation trouve des blocs alignés et contigus de mémoire. Dans ce cas précis, il souffre également des mêmes problèmes que les pages de mémoire classiques, à savoir la fragmentation. Si l’OS ne sait pas trouver de blocs de mémoire continus, il va essayer de "compacter", réclamer les partions inutilisées ou "page out" les autres pages. Ce processus est couteux et peut provoquer de grosses latences (jusqu’à quelques secondes). Heureusement, ce problème a été adressé dans la version 4.6 du kernel Linux (avec l’option defer) ; l’OS retourne dans le mode classique (page de 4K) si jamais il ne trouve pas de place pour une hugepage.

La deuxième partie est la maintenance. Si une application ne modifie ne serait ce qu’un seul octet de mémoire, elle va consommer la taille d’une page entière, à savoir 2 Mo si on utilise des hugepages, ce qui est clairement un gaspillage de mémoire vive. Pour palier à ça, il existe une tâche de fond qui s’appelle khugepaged. Ce processus scanne les pages et essaye de défragmenter et concaténer toutes les pages presque vides dans une seule page. Cependant, même si c’est une tâche de fond, elle va bloquer les pages sur lesquelles elle fonctionne, ce qui peut aussi provoquer des pic de latence. Un dernier problème reste qu’il est parfois nécessaire de découper les grosses pages, car tous les composants de l’OS ne supportent pas les hugepages. C’est le cas de la swap par exemple. L’OS doit alors découper les grosses pages en plus petites pour ces composants là. Encore une fois, cette opération peut dans certain cas dégrader les performances et augmenter la fragmentation.

Le meilleur endroit pour apprendre comment fonctionnent les Transparent Hugepage est évidemment la documentation officielle du Kernel Linux. Cette fonctionnalité dispose de plusieurs éléments de configuration ainsi que des flags pour modifier son comportement. Ils évoluent avec le Kernel lui même.

Comment le mesurer ?

C’est probablement la partie la plus importante de ce post. Basiquement, il y a deux façon de mesurer l’impact de cette fonctionnalité : les CPU counters et les kernel functions.

CPU counters

Commençons par les CPU counters. J’utilise perf, qui est un outil génial et simple pour réaliser ce genre de mesures. Perf dispose nativement d’alias pour les événements du TLB : dTLB-loads, dTLB-load-misses pour les hit et les miss en load; dTLB-stores, dTLB-store-misses (idem mais pour les stores).

[~]# perf stat -e dTLB-loads,dTLB-load-misses,dTLB-stores,dTLB-store-misses -a -I 1000
#           time             counts unit events
     1.006223197         85,144,535      dTLB-loads                                                    
     1.006223197          1,153,457      dTLB-load-misses          #    1.35% of all dTLB cache hits   
     1.006223197        153,092,544      dTLB-stores                                                   
     1.006223197            213,524      dTLB-store-misses                                             
...

Et la même chose pour les instructions (iTLB-load, iTLB-load-misses).

[~]# perf stat -e iTLB-load,iTLB-load-misses -a -I 1000
#           time             counts unit events
     1.005591635              5,496      iTLB-load
     1.005591635             18,799      iTLB-load-misses          #  342.05% of all iTLB cache hits
...

En réalité, perf supporte seulement un petit sous ensemble de tous les événements alors que les CPUs ont des centaines de compteurs pour évaluer la performance. Pour les CPUs Intels par exemple, on peut trouver la liste de tous les compteurs disponibles sur le site Intel Processor Event Reference, dans le Intel® 64 and IA-32 Architectures Developer’s Manual: Vol. 3B ou bien encore dans les sources du Kernel Linux. Le manuel du développeur contient également des codes d’événements que nous devons passer pour analyser les performances.

Si on regarde les compteurs relatifs au TLB, voilà ce qu’on peut trouver d’intéressant :

MnemonicDesctiptionEvent Num.Umask Value
DTLB_LOAD_MISSES.MISS_CAUSES_A_WALKMisses in all TLB levels that cause a page walk of any page size.08H01H
DTLB_STORE_MISSES.MISS_CAUSES_A_WALKMiss in all TLB levels causes a page walk of any page size.49H01H
DTLB_LOAD_MISSES.WALK_DURATIONThis event counts cycles when the page miss handler (PMH) is servicing page walks caused by DTLB load misses.08H10H
ITLB_MISSES.MISS_CAUSES_A_WALKMisses in ITLB that causes a page walk of any page size.85H01H
ITLB_MISSES.WALK_DURATIONThis event counts cycles when the page miss handler (PMH) is servicing page walks caused by ITLB misses.85H10H
PAGE_WALKER_LOADS.DTLB_MEMORYNumber of DTLB page walker loads from memory.BCH18H
PAGE_WALKER_LOADS.ITLB_MEMORYNumber of ITLB page walker loads from memory.BCH28H

Perf supporte le compteur *MISS_CAUSES_A_WALK via un alias. Mais nous devrons trouver l’identifiant numérique des autres événements pour les passer en arguments. Point important, les numéros d’événements et les valeurs umask associées dépendent de chaque CPU. Par exemple, la liste ci dessus est spécifique à l’architecture Intel Haswell ! Il vous sera nécessaire d’adapter ces codes à votre CPU.

Une des métriques clé est le nombre de cycle CPU passés à faire du page table walking :

[~]# perf stat -e cycles \
>   -e cpu/event=0x08,umask=0x10,name=dcycles/ \
>   -e cpu/event=0x85,umask=0x10,name=icycles/ \
>   -a -I 1000
#           time             counts unit events
     1.005079845        227,119,840      cycles
     1.005079845          2,605,237      dcycles
     1.005079845            806,076      icycles
...

Une autre métrique importante est le nombre de lecture mémoire qui causent des TLB miss ; ces lectures ne profitent pas du cache CPU et sont donc coûteuses :

[~]# perf stat -e cache-misses \
>   -e cpu/event=0xbc,umask=0x18,name=dreads/ \
>   -e cpu/event=0xbc,umask=0x28,name=ireads/ \
>   -a -I 1000
#           time             counts unit events
     1.007177568             25,322      cache-misses
     1.007177568                 23      dreads
     1.007177568                  5      ireads
...

Kernel functions

Une autre façon surpuissante de mesurer l’impact des THP sur les performances et la latence est d’utiliser les fonctions de tracing/probing du Kernel Linux. J’utilise SystemTap pour ça, qui est un outil pour instrumenter dynamiquement les systèmes Linux en production.

La première fonction intéressante pour le cas qui nous intéresse est __alloc_pages_slowpath. Elle est exécutée lorsqu’il n’y a pas de bloc contigu de mémoire vive disponible lors d’une allocation. A son tour, cette fonction appelle la fonction de "récupération" et de "compaction" des pages, qui je le rappelle est une opération très couteuse qui peut engendrer des pics de latence.

La seconde fonction intéressante est khugepaged_scan_mm_slot. Elle est exécutée en tâche de fond par le thread khugepaged du Kernel. Ce thread scanne les hugepages et essaye de les compacter en une seule.

J’utilise un script SystemTap pour mesurer le temps d’exécution d’une fonction. Ce script stocke tous les temps d’exécution en microsecondes et affiche périodiquement un histogramme. Il ne consomme que quelques Mo par heure, en fonction du nombre d’exécutions. Le premier argument est la sonde à utiliser, le second est un nombre (en ms) pour afficher les statistiques.

#! /usr/bin/env stap
global start, intervals

probe $1 { start[tid()] = gettimeofday_us() }
probe $1.return
{
  t = gettimeofday_us()
  old_t = start[tid()]
  if (old_t) intervals <<< t - old_t
  delete start[tid()]
}

probe timer.ms($2)
{
    if (@count(intervals) > 0)
    {
        printf("%-25s:\n min:%dus avg:%dus max:%dus count:%d \n", tz_ctime(gettimeofday_s()),
             @min(intervals), @avg(intervals), @max(intervals), @count(intervals))
        print(@hist_log(intervals));
    }
}

Voici un exemple avec la fonction __alloc_pages_slowpath :

[~]# ./func_time_stats.stp 'kernel.function("__alloc_pages_slowpath")' 1000

Thu Aug 17 09:37:19 2017 CEST:
 min:0us avg:1us max:23us count:1538
value |-------------------------------------------------- count
    0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  549
    1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  541
    2 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@                 377
    4 |@@@@                                                54
    8 |@                                                   12
   16 |                                                     5
   32 |                                                     0
   64 |                                                     0
...

Il est également intéressant de savoir observer l’état général de l’OS. Un bon exemple peut être la fragmentation de la mémoire. /proc/buddyinfo est un outil utilise pour aider au diagnostic dans ce genre de cas. Buddyinfo va nous donner des pistes pour estimer la taille maximale que l’on peut allouer sans risque, ou pourquoi la précédent allocation a échoué par exemple. De même, on peut aussi trouver des informations utiles dans /proc/pagetypeinfo.

cat /proc/buddyinfo
cat /proc/pagetypeinfo

Vous pouvez en apprendre plus en lisant la documentation officielle ou alors en lisant cet article.

JVM

La JVM supporte les Transparent Hugepages via l’ajout de l’option -XX:+UseTransparentHugePages. Cependant, on aura alors un message d’avertissement contre de possibles problèmes de performance :

-XX:+UseTransparentHugePages On Linux, enables the use of large pages that can dynamically grow or shrink. This option is disabled by default. You may encounter performance problems with transparent huge pages as the OS moves other pages around to create huge pages; this option is made available for experimentation.

Il est intéressant d’activer l’usage des large pages pour le "Metaspace" :

-XX:+UseLargePagesInMetaspace Use large page memory in metaspace. Only used if UseLargePages is enabled.

De plus, utiliser l’option -XX:+AlwaysPreTouch avec les hugepages peut être une bonne idée. Cela permet de réallouer toute la mémoire physique utilisé par le tas (heap) et ainsi éviter une surcharge supplémentaire due à l’initialisation ou à la compaction. Cependant, cela induira une augmentation du temps nécessaire pour initialiser la JVM.

-XX:+AlwaysPreTouch Enables touching of every page on the Java heap during JVM initialization. This gets all pages into the memory before entering the main() method. The option can be used in testing to simulate a long-running system with all virtual memory mapped to physical memory. By default, this option is disabled and all pages are committed as JVM heap space fills.

Aleksey Shipilёv montre l’impact sur la performance dans son article de post JVM Anatomy Park #2: Transparent Huge Pages.

Un exemple de la vie réelle : une JVM très chargée

Regardons maintenant quel impact ont réellement les Transparent Hugepages sur une application réelle. Prenons une application lancée dans une JVM : un serveur TCP basé sur netty et recevant un trafic important. Le serveur reçoit jusqu’à 100k requêtes par secondes, analyse chaque requête, effectue un appel réseau à une base de données pour chacun des appels, fait un certain nombre de calculs dessus, puis retourne un réponse. L’application en question possède une heapsize de 200 Go. Les mesures ont été réalisées sur des serveurs de production, ainsi que la charge réelle de production. Les serveurs n’étaient pas surchargés et recevaient 50% du nombre maximal de requêtes qu’ils étaient capables de traiter.

Transparent Hugepages désactivées

Désactivons les THP :

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

La première chose à faire et de mesurer les TLB misses. Ici on a environ 130 millions de TLB misses. Le ratio Miss/Hit est de 1% (ce qui ne semble pas énorme, au premier abord).

[~]# perf stat -e dTLB-loads,dTLB-load-misses,iTLB-load-misses,dTLB-store-misses -a -I 1000
#           time             counts unit events
...
    10.007352573      9,426,212,726      dTLB-loads                                                    
    10.007352573         99,328,930      dTLB-load-misses          #    1.04% of all dTLB cache hits   
    10.007352573         26,021,651      iTLB-load-misses                                              
    10.007352573         10,955,696      dTLB-store-misses                                             
...

Cependant, regardons plus précisément combien nous ont coûté en temps CPU ces TLB misses :

[~]# perf stat -e cycles \
>   -e cpu/event=0x08,umask=0x10,name=dcycles/ \
>   -e cpu/event=0x85,umask=0x10,name=icycles/ \
>   -a -I 1000
#           time             counts unit events
...
    12.007998332     61,912,076,685      cycles
    12.007998332      5,615,887,228      dcycles
    12.007998332      1,049,159,484      icycles
...

Oui, vous avez bien vu ! Plus de 10% des cycles CPUs sont utilisés pour parcourir la page table.

Le compteur suivant montre que nous avons 1 million de lectures RAM causées par des TLB misses (sachant que chacunes de ces lectures coûtent 100 ns chacunes) :

[~]# perf stat -e cpu/event=0xbc,umask=0x18,name=dreads/ \
>    -e cpu/event=0xbc,umask=0x28,name=ireads/ \
>    -a -I 1000
#           time             counts unit events
...
     6.003683030          1,087,179      dreads
     6.003683030            100,180      ireads
...

Tous les nombres que je viens de vous montrer sont intéressants, mais ils ne sont pas vraiment "exploitables". Les métriques les plus importantes pour un développeur d’application sont les métriques de l’application elle-même. Regardons donc comment la métrique de la latence end-to-end de l’application. Voilà les mesures (en microsecondes) qui ont été récoltées pendant quelques minutes :

  "max" : 16414.672,
  "mean" : 1173.2799067016406,
  "min" : 52.112,
  "p50" : 696.885,
  "p75" : 1353.116,
  "p95" : 3769.844,
  "p98" : 5453.675,
  "p99" : 6857.375,

Transparent Hugepages activées

Maintenant on va pouvoir commencer à faire des comparaisons ! Activons les THP :

echo always > /sys/kernel/mm/transparent_hugepage/enabled
echo always > /sys/kernel/mm/transparent_hugepage/defrag # consider other options too

Et lançons la JVM avec les options -XX:+UseTransparentHugePages, -XX:+UseLargePagesInMetaspace et -XX:+AlwaysPreTouch.

La première métrique que nous avions collecté (les TLB misses) ont été divisés par 6, passant de 130 millions à environ 20 millions. Mathématiquement, le ratio miss/hit tombe de 1% à 0,15%. Voici les nombres exacts :

[~]# perf stat -e dTLB-loads,dTLB-load-misses,iTLB-load-misses,dTLB-store-misses -a -I 1000
#           time             counts unit events
     1.002351984     10,757,473,962      dTLB-loads                                                    
     1.002351984         15,743,582      dTLB-load-misses          #    0.15% of all dTLB cache hits  
     1.002351984          4,208,453      iTLB-load-misses                                              
     1.002351984          1,235,060      dTLB-store-misses                                            

Les cycles CPU passés à parcourir la page table ont également diminué d’un facteur 5, d’environ 6,7 milliards à 1,3 milliards. Cette fois ci, nous avons donc utilisé seulement 2% de notre CPU à réaliser du "page table walking" :

[~]# perf stat -e cycles \
>   -e cpu/event=0x08,umask=0x10,name=dcycles/ \
>   -e cpu/event=0x85,umask=0x10,name=icycles/ \
>   -a -I 1000
#           time             counts unit events
...
     8.006641482     55,401,975,112      cycles
     8.006641482      1,133,196,162      dcycles
     8.006641482        167,646,297      icycles
...

Et enfin, le nombre de lecture en RAM a diminué de 1 million à 350k

[~]# perf stat -e cpu/event=0xbc,umask=0x18,name=dreads/ \
>    -e cpu/event=0xbc,umask=0x28,name=ireads/ \
>    -a -I 1000
#           time             counts unit events
...
    12.007351895            342,228      dreads
    12.007351895             17,242      ireads
...

Tout ça c’est bien beau, mais, une fois encore, les nombres qui vont le plus nous intéresser, c’est l’effet réel que ça va avoir sur notre application. Voici les chiffres de la latence end-to-end de l’application :

  "max" : 16028.281,
  "mean" : 946.232869010599,
  "min" : 41.977000000000004,
  "p50" : 589.297,
  "p75" : 1080.305,
  "p95" : 2966.102,
  "p98" : 4288.5830000000005,
  "p99" : 5918.753,

La différence entre les deux runs sur les 95 percentiles est quasiment de 1 milliseconde ! Voici ce que cela représente visuellement :

Source : https://alexandrnikitin.github.io/blog/images/transparent-hugepages-measuring-the-performance-impact/grafana.png

Nous venons donc de mesurer l’amélioration apportée par l’activation des Transparent Hugepages. Cependant, nous savons que l’activation des THP peut avoir un impact sur les performances (à cause de l’overhead de la "maintenance" que nous avons expliqué plus haut) ainsi que les risques de pic de latence. Nous devons donc également les mesurer. Regardons le thread kernel khugepaged qui s’occupe de la défragmentation des hugepages. La mesure qui suit a été réalisée sur une durée d’environ 24 heures. Comme vous pouvez le constater, le temps maximum d’exécution est de 6 millisecondes et il y a de nombreuses exécutions qui ont pris moins d’une milliseconde. Si ce processus est en tâche de fond, mais il bloque les pages concernées pendant qu’il travaille dessus. Voici l’histogramme :

[~]# ./func_time_stats.stp 'kernel.function("khugepaged_scan_mm_slot")' 60000 -o khugepaged_scan_mm_slot.log
[~]# tail khugepaged_scan_mm_slot.log

Thu Aug 17 13:38:59 2017 CEST:
 min:0us avg:321us max:6382us count:10834
value |-------------------------------------------------- count
    0 |@                                                   164
    1 |@                                                   197
    2 |@@@                                                 466
    4 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  6074
    8 |@@@@@@                                              761
   16 |@@                                                  318
   32 |                                                     65
   64 |                                                     13
  128 |                                                      1
  256 |                                                      3
  512 |@@@                                                 463
 1024 |@@@@@@@@@@@@@@@@@@                                 2211
 2048 |                                                     85
 4096 |                                                     13
 8192 |                                                      0
16384 |                                                      0

Une autre fonction important du kernel est __aloc_pages_slowpath. Cette fonction aussi peut provoquer des pics de latence si un block contigue de mémoire n’est pas disponible. Lors de la mesure, l’histogramme est bien meilleur ici. Le temps maximum d’allocation était de 288 microsecondes. Même en le faisant tourner pendant des heures voire même des jours, nous sommes devenus confiant dans le fait que cette fonctionnalité n’allait pas provoquer de longs pics de latence.

[~]# ./func_time_stats.stp 'kernel.function("__alloc_pages_slowpath")' 60000 -o alloc_pages_slowpath.log
[~]# tail alloc_pages_slowpath.log

Tue Aug 15 10:35:03 2017 CEST:
 min:0us avg:2us max:288us count:6262185
value |-------------------------------------------------- count
    0 |@@@@                                                237360
    1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@     2308083
    2 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  2484688
    4 |@@@@@@@@@@@@@@@@@@@@@@                             1136503
    8 |@                                                    72701
   16 |                                                     22353
   32 |                                                       381
   64 |                                                         7
  128 |                                                       105
  256 |                                                         4
  512 |                                                         0
 1024 |                                                         0

Alors comment se fait il que les Transparents Hugepages fonctionnent aussi bien dans ce cas précis ? D’abord, on remarque un amélioration significative de la performance car dans ce cas précis on travaille avec une grande quantité de RAM. De même, on ne remarque pas de pics de latences car il n’y a pas de surcharge en terme de RAM sur le serveur. Il y a beaucoup de RAM (256 Go), la JVM sait tirer partie des THP, pré-alloue la totalité des 200 Go de heap dès le démarrage et ne la redimensionne jamais.

Conclusion

Ne suivez pas aveuglément les recommandation que vous trouvez sur Internet ! Mesurez, mesurez, mesurez encore !

Les Transparent Hugepages sont une optimisation et qui peut avoir de réelles conséquences positives sur la performance, mais avec des inconvénients et des risques qui peuvent entrainer des conséquences imprévues. Le but de ce post était de donner les clés pour mesurer les gains potentiels et gérer les risques. Le Kernel Linux et ces fonctionnalités évoluent et certains des problèmes des THP ont été adressés dans les dernières versions, comme par exemple l’option "defer" de la défragmentation, qui permet à l’OS de repasser sur une allocation de taille normale, si jamais il n’est pas possible d’en allouer une large.

Note de zwindler : Encore merci à l’auteur (Alexandr Nikitin) pour son article, qui m’a appris beaucoup de choses !

Cet article Transparent Hugepages : mesurer l’impact sur les performances est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2020/02/24/transparent-hugepages-mesurer-limpact-sur-les-performances/feed/ 3 5514
Créer un VPN distribué avec Tinc https://blog.zwindler.fr/2020/02/17/creer-un-vpn-distribue-avec-tinc/ https://blog.zwindler.fr/2020/02/17/creer-un-vpn-distribue-avec-tinc/#comments Mon, 17 Feb 2020 07:30:00 +0000 https://blog.zwindler.fr/?p=4660 Tutoriel pas à pas pour monter un VPN multipoint (full mesh) avec Tinc

Cet article Créer un VPN distribué avec Tinc est apparu en premier sur Zwindler's Reflection.

]]>

Faire un VPN Tinc fullmesh sans monter un gros réseau IPSec

Un des gros problèmes que j’ai rapidement eu à régler lorsque j’ai voulu monter des clusters de serveurs Proxmox VE chez des providers de serveurs physiques, c’est la façon dont est gérée le clustering dans PVE.

Les concepteurs de PVE ne veulent pas que l’on monte des clusters sur Internet et mettent volontairement le plus de bâtons dans les roues pour vous empêcher de le faire. J’exagère à peine.

En version 5.x, PVE se basait sur la version 2 de corosync par multicast (bloqué par tous les providers) et qu’en v6.x, on nous bride en demandant explicitement un sous réseau LAN dédié, autant dire qu’on est pas aidé.

OpenVPN vs Tinc

Une solution que j’ai expérimenté est de monter un serveur OpenVPN sur un des serveurs et de connecter les autres dessus. J’ai d’ailleurs fait un tuto là dessus pour PVE.

Cette approche n’est pas optimale : si on a 2 machines, c’est bon, mais si on en a 3 ou plus, on se retrouve soit avec un SPOF, soit à devoir monter un maillage complexe de couples serveur-client. Au delà de 3, c’est pratiquement ingérable.

Au contraire, Tinc est un logiciel libre (GPLv2) permettant de monter des VPNs multipoints (full mesh routing) entre des machines sur Internet. Tinc est prévu pour notre cas d’usage !

le vrai logo de Tinc (la photo en haut du blog c’est Supercopter, of course)

On sécurise

Comme tout service "ouvert" sur Internet, il est évidemment nécessaire de faire du firewalling pour bloquer le trafic malveillant. Pour information, Tinc utilise le port 655 en TCP et UDP, que vous devrez donc ouvrir dans les deux sens entre l’ensemble de vos serveurs, mais bloquer pour le reste d’Internet.

A noter, ce n’est pas confirmé mais la page principale de Tinc indique qu’il est possible que ce logiciel (tout comme OpenVPN, Wireguard et IPSec) soit vulnérable à la CVE-2019-14899.

On l’installe et on le configure

On va devoir installer le package/binaire sur toutes les machines du VPN. Pas trop de soucis de ce côté, tinc est multiplateforme (Windows aussi) et est packagé dans de nombreuses distrib Linux. Sur les dépôts Debian, tinc est présent sans souci et j’imagine que ça sera le cas pour d’autres distribs aussi.

apt install tinc

Une fois installé, on peut créer notre VPN. Pour déclarer un VPN, il faut ajouter le nom de celui ci dans un fichier de configuration global :

echo "vpnzwindler" >> /etc/tinc/nets.boot

On créé ensuite un répertoire du même nom, contenant lui même un dossier hosts.

mkdir -p /etc/tinc/vpnzwindler/hosts

Dans ces dossiers, on va créer fichier de configuration, /etc/tinc/vpnzwindler/tinc.conf. Ce fichier va nous permettre de décrire le node courant et qui doit se connecter à qui.

Name = node01
AddressFamily = ipv4
Address = 1.1.1.1
Device = /dev/net/tun
Mode = switch
ConnectTo = node02
ConnectTo = node03
ConnectTo = node04
[...]

Dans les informations importantes, Name va être le nom (arbitraire) du node pour tout le VPN, Address représente l’adresse IP publique de votre node, et ConnectTo, la liste des autres Names des autres nodes.

A partir de là, on peut demander à tinc de nous générer des couples clé publique/clé privée pour tous nos serveurs. Sur tous les nodes du VPN, lancer :

echo -e '\n\n' | tincd -n vpnzwindler -K4096

Si tout se passe bien et que tous les fichiers de conf et dossiers ont été créés correctement, tinc devrait créer un couple clé privée/clé publique, puis créer un fichier /etc/tinc/vpnzwindler/hosts/node01 (sur celui dont le Name est node01).

Envoyez (par scp par exemple) l’ensemble des fichiers dans le dossier hosts sur tous les serveurs. Maintenant, tous les VPNs sauront quelle IP publique contacter et avec quel clé authentifier le trafic.

Autre méthode : tinc invite / tinc join

Une feature sympa de tinc, mais seulement en 1.1 (la dernière version), est la possibilité d’ajouter des nodes à un VPN existants via une simple commande tinc invite (voir la doc).

Je ne l’ai pas testée mais a priori tinc créé une URL qui permet d’inviter n’importe qui et de configurer son node avec un tinc join.

The whole URL is around 80 characters long and looks like this: server.example.org:12345/cW1NhLHS-1WPFlcFio8ztYHvewTTKYZp8BjEKg3vbMtDz7w4

Configuration du réseau de l’OS

Maintenant qu’on a tous les prérequis, on peut configurer l’aspect réseau de notre VPN. Ça dépend de votre distribution bien sûr (où dans le cas de PVE, si vous utilisez OpenVSwitch ou pas par exemple). Dans le cas d’une Debian récente, on va gérer tout ça avec ip.

Pour gérer cette partie, Tinc va vous demander de créer 2 scripts. Un tinc-up.sh et un tinc-down.sh, respectivement pour le démarrage et l’extinction de l’interface VPN.

cat /etc/tinc/vpnzwindler/tinc-up
#!/bin/bash
/sbin/ip link set vpnzwindler up
/sbin/ip addr add 10.0.0.1/24 dev vpnzwindler
/sbin/ip route add 10.0.0.0/24 dev vpnzwindler

cat /etc/tinc/vpnzwindler/tinc-down
#!/bin/bash
/sbin/ip link set vpnzwindler down

chmod +x tinc-*

Rien de bien compliqué ici, on demande au binaire ip de créer une interface vpnzwindler. Puis on lui affecte l’IP virtuelle 10.0.0.1 (notre node01). Enfin d’ajouter une route pour que tout le trafic du VPN passe par cette interface.

On le démarre

Dernière étape, on va demander à systemd de nous démarrer le vpn qu’on vient de créer dès le démarrage de la machine.

systemctl daemon-reload
systemctl enable tinc@vpnzwindler
systemctl start tinc@vpnzwindler

Et voilà !!! Vous avez maintenant un VPN multipoint simple et efficace !

root@node01 ~ # ping node02
PING node02 (10.0.0.2) 56(84) bytes of data.
64 bytes from node02 (10.0.0.2): icmp_seq=1 ttl=64 time=17.1 ms

Cet article Créer un VPN distribué avec Tinc est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2020/02/17/creer-un-vpn-distribue-avec-tinc/feed/ 6 4660
Redis, MongoDB, RabbitMQ, désactiver les Transparent Huge Pages https://blog.zwindler.fr/2020/02/10/redis-mongodb-rabbitmq-desactiver-les-transparent-huge-pages/ https://blog.zwindler.fr/2020/02/10/redis-mongodb-rabbitmq-desactiver-les-transparent-huge-pages/#comments Mon, 10 Feb 2020 07:30:00 +0000 https://blog.zwindler.fr/?p=2585 Explication de ce que sont les transparent Huge pages et surtout comment les désactiver sur vos serveurs Linux

Cet article Redis, MongoDB, RabbitMQ, désactiver les Transparent Huge Pages est apparu en premier sur Zwindler's Reflection.

]]>

Transparents Huge Pages

Les THP et moi, ça remonte à quelques années (i.e.n un brouillon qui traine depuis longtemps); Mais j’ai de nouveau eu besoin de toucher aux Transparent Huge Pages il y a peu donc c’est une bonne occasion de m’y remettre.

Redis, MongoDB, RabbitMQ, Kafka… Tout ces logiciels vous demandent, à l’installation ou dans la documentation, de désactiver ce paramètre système de vos serveurs Linux.

01-07-2020 03:46:32.730 +0000 WARN ulimit – ulimits: This instance is running on a machine that has kernel transparent huge pages enabled. This can significantly reduce performance and is against best practices. Turn off kernel transparent huge pages using the method that is most appropriate for your Linux distribution.

Même dmesg me dit de le désactiver :'(

Dans cet article, je vais vous montrer à quoi ça sert, mais surtout comment on va faire pour le désactiver (le plus proprement possible).

Mais au fait, c’est quoi ?

Avant de lui couper la chique, le mieux c’est quand même peut-être de savoir de quoi il s’agit avant de respecter les précos des éditeurs.

Note : Ca me fait penser à SELinux, la première chose qu’on nous demande de désactiver quand on installe un progiciel sur RHEL et qu’on connait au final assez mal…

Pour faire bref, la gestion de la mémoire par le CPU passe par une couche d’abstraction : la mémoire est découpée en pages de taille fixe (par défaut 4ko) et le CPU garde une table de conrrespondance de ces pages dans la MMU.

Pour des raisons de performance, il peut être intéressant, sur nos systèmes récents ayant beaucoup de RAM, d’avoir des pages plus grosses pour faciliter le travail du CPU (aka des "huge pages"). Cependant, il est nécessaire de modifier le code de l’application pour tirer parti des HugePages. Arrive alors une autre couche d’abstraction, les Transparent Huge Pages. Vous avez deviné, pour faire ça de manière transparente !

Je vous met en bas de l’article quelques liens pour comprendre en détail de quoi on parle.

Oneshot

Maintenant qu’on sait ce que c’est, on peut le désactiver en tout quiétude.

Déjà, on va commencer par vérifier l’état de notre OS, pour savoir un peu où on en est au niveau des THP. Pour ça, un simple cat de /sys/kernel/mm/transparent_hugepage/enabled nous donnera l’info :

cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Il existe 3 valeurs possibles pour ce paramètre : always, madvise et never. always et never sont simples à comprendre, et pour ce qui est de madvise, il s’agit d’un paramètre intermédiaire qui dit que par défaut, les THP sont désactivées, mais que les applications peuvent utiliser un appel "madvise" pour allouer des THP dans la zone mémoire réservée pour ça.

Ici, on va donc vouloir désactiver les THP totalement (donc never).

Pour se faire, on peut simplement utiliser la commande suivante :

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Attention cependant, le paramètre ne sera pris en compte que jusqu’au prochain reboot.

Les méthodes classiques pour désactiver durablement les THP

A partir de là, on va vouloir le désactiver pour les prochains boots. On va donc devoir indiquer d’une manière ou d’une autre à l’OS qu’il faut désactiver ce paramètre, activé par défaut.

La plupart des logiciels vous conseillent de faire un service qui ne fait que ça et qui sera lancé au démarrage de votre machine (ex. vertica, couchbase, …).

Je suis pas fan, je trouve que modifier un paramètre au démarrage ne devrait pas se faire comme ça.

La façon la plus "propre" de le faire est probablement de modifier la configuration du bootloader (souvent GRUB). Si vous avez GRUB, c’est assez facile de le faire puisque c’est une option à ajouter dans le grub :

cat /etc/default/grub
[...]
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300"
GRUB_CMDLINE_LINUX=""
[...]

## APRES
cat /etc/default/grub
[...]
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300 transparent_hugepage=never"
GRUB_CMDLINE_LINUX=""

Cependant, cette méthode nécessite de reconstruire votre fichier grub (avec grub2-mkconfig) donc j’imagine que c’est pour cela que cette méthode n’est pas mise en avant.

Une méthode alternative pour désactiver les transparent Huge Pages

Si vous ne vous sentez pas de modifier votre bootloader et que vous n’aimez pas, comme moi, l’idée de faire un service pour faire un echo au boot, il reste une dernière possibilité.

apt install sysfsutils
echo "kernel/mm/transparent_hugepage/enabled = never" >> /etc/sysfs.conf
echo "never" >> /sys/kernel/mm/transparent_hugepage/enabled

L’avantage, c’est que, contrairement à la modif du GRUB, ça va être ultra simple du coup d’automatiser ça avec Ansible. Je vais pouvoir intégrer la modification dans mes playbooks d’installation des logiciels cités en début d’article !

---
- hosts: all
  become: yes
  tasks:
  - name: "Install sysfsutils"
    apt:
      name: "{{item}}"
      state: present
    loop:
    - sysfsutils
  - name: "Disable permanently Transparent Huge Pages"
    lineinfile:
      path: /etc/sysfs.conf
      line: kernel/mm/transparent_hugepage/enabled = never
  - name: "Disable THP for this boot"
    shell: "echo 'never' >> /sys/kernel/mm/transparent_hugepage/enabled"

Et voilà :D

Cet article Redis, MongoDB, RabbitMQ, désactiver les Transparent Huge Pages est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2020/02/10/redis-mongodb-rabbitmq-desactiver-les-transparent-huge-pages/feed/ 5 2585
Retour d’expérience : 1 an à 90% https://blog.zwindler.fr/2020/02/03/retour-dexperience-1-an-a-90/ https://blog.zwindler.fr/2020/02/03/retour-dexperience-1-an-a-90/#comments Mon, 03 Feb 2020 07:30:00 +0000 https://blog.zwindler.fr/?p=5357 Retour d'expérience sur mon passage à 90% pour garder ma fille : les conditions, le regard des autres, les activités

Cet article Retour d’expérience : 1 an à 90% est apparu en premier sur Zwindler's Reflection.

]]>

Quoi !? Tu travailles à 90% !

Aujourd’hui, pas de technique. Je vais vous faire un petit retour d’expérience sur la situation professionnelle et personnelle dans laquelle je suis depuis maintenant 1 an : travailler à temps partiel, à 90% pour être précis.

Même si ce n’est qu’un 90%, c’est un choix personnel qui a eu conséquences multiples, plus ou moins fortes, à la fois sur ma vie personnelle et professionnelle.

Pourquoi en parler ?

J’ai hésité un moment avant d’écrire cet article.

D’abord parce qu’il me concerne personnellement et que je n’ai pas forcément envie de parler publiquement de ma vie privée. Parallèlement à ça, j’imagine (et c’est bien normal), que ma vie ne vous intéresse pas plus que ça de toute façon ;-p.

En revanche, je pense que mon retour d’expérience sur ce que j’ai vécu peut en intéresser d’autres, qui auraient le même genre de projet de vie que moi. A ces gens-là, je peux raconter ce que j’y ai trouvé de bon, de moins bon, de franchement génial.

Pourquoi ne pas en parler ?

Parmi les autres freins qui m’ont longtemps fait hésiter à en parler, c’est le regard des autres. Je me suis longtemps demandé ce qu’on allait penser de moi, le jour où j’allais demander de passer de 100% à 90%.

Car on ne va pas se le cacher, on vit dans un monde professionnel encore bien conservateur. Parfois même rétrograde.

Pour illustrer mon propos, je vous invite à aller faire un tour sur LinkedIn, où le salarié (souvent un homme bizarrement) travaillant 70h / semaine est régulièrement glorifié. Autant vous dire que quand j’essaye de ramener ces gens-là à la réalité, je me prends régulièrement des "fainéants" ou autre noms d’oiseaux.

Cet « expert » en « remise en forme du retail » s’insurge qu’on parle des ponts à la TV. Comme si ça n’était jamais arrivé les années précédentes…

On pourrait se dire que ça se limite aux réseaux sociaux, bien sûr, mais cette ambiance du siècle dernier (ou celui d’avant encore), je l’ai aussi vécu IRL.

Pour la petite histoire :

Un jour, ayant eu envie de faire moi-même une galette des rois, le directeur de l’entreprise, abasourdi que ce soit moi qui fasse la cuisine, a fait le tour des employés présents pour leur faire des blagues machistes, sexistes, voire même limite homophobe sur moi. Ambiance.

Bref, dans ce genre de contextes où un bon salarié est un salarié – surtout si c’est un homme! – qui veut travailler toujours plus, au début, je n’étais pas sûr d’assumer le fait de vouloir moins travailler. Encore moins en parler ouvertement.

Mais d’ailleurs, pourquoi vouloir un contrat à 90% ?

Car peut être que c’est eux qui ont raison ? Que je suis effectivement un fainéant ? ;-p

Il y a un an et demi, je suis devenu papa.

Être papa, c’est une fierté, mais c’est surtout une responsabilité. Je n’imaginais pas une seule seconde un monde où je serai père, mais pas impliqué. Je VEUX passer du temps avec ma fille.

Note : C’est un choix personnel, que chacun est libre de partager ou pas. Pas de jugement de ma part.

Je vous passe volontairement la galère pour trouve un mode de garde (ceux qui n’y sont pas encore, vous allez voir, c’est fun). Après avoir cherché une crèche et finalement trouvé une nounou, on a fait un rapide calcul (naïf) : en la faisant garder 5 jours par semaine pendant 10h/jour (choix standard avec deux parents travaillant en horaires de bureau), notre fille allait plus vivre avec la nounou que nous (si on décompte la nuit). Et ça ne nous paraissait pas acceptable.

Nous avons donc décidé de faire garder notre fille un jour de moins pour passer plus de temps avec elle.

Comment faire ?

Ce qu’il faut savoir quand on est sur le point d’être jeune parent, c’est qu’il existe plusieurs dispositions dans la loi et ce n’est pas forcément facile de s’y retrouver. (Et comme vous le savez, j’aime bien parler du droit du travail)

La plus importante d’entre elle est le congé parental, qui permet à n’importe quel parent de réduire son activité professionnelle (voire de la stopper totalement). Il existe un guide sur service-public.fr plutôt bien fait pour voir les conditions et autres modalités.

Grosso modo, ce qu’il faut savoir c’est que :

  • Le congé est ouvert à tout salarié ayant au moins 1 an d’ancienneté dans l’entreprise à la naissance ou l’adoption de l’enfant.
  • La durée initiale du congé parental est de 1 an maximum (renouvelable généralement 2 fois)

Notre idée initiale était donc, que pour la première année, ma femme se mette à 80% les 6 premiers mois, pour garder notre fille le mercredi, puis qu’à ses 6 mois, je prenne le relais pendant 6 mois également.

Pourquoi cette alternance de 80% à 6 mois ?

Effectivement, ça peut paraître un peu étrange au premier abord. La raison est économique.

Je suis conscient que j’ai beaucoup de chance d’avoir un métier qui me permet d’envisager la possibilité de passer à temps partiel. Pour autant, accueillir un tout petit, c’est un changement important dans le budget d’une famille.

Parallèlement à ce que je viens de dire pour le congé parental, il existe plusieurs aides financières, chacune avec leurs conditions :

Un point intéressant est que PreParE et CMG peuvent se cumuler tant que l’activité pro est entre 50 et 80% (mais pas à 90%) et que la PreParE est versée jusqu’au 1 an de l’enfant dans la limite de 6 mois par parent.

De cette manière, en alternant 6 mois à 80% chacun lors de la première année de l’enfant, on peut donc bénéficier à la fois de la PreParE et de la CMG, ce qui permet de réduire un peu les charges de cette première année.

Giphy – The hangover

Note : Malheureusement, toute cette belle planification que nous avions faite s’est heurtée à la dure réalité de la loi. N’ayant pas 1 an d’ancienneté au moment de la naissance de ma fille, je n’ai pas pu bénéficier d’un congé parental (et donc des aides associées). Nous avons donc décidé de simultanément passer à temps partiel par avenant au contrat de travail (avec un mercredi sur deux chacun).

Comment ça a été accueilli ?

Je l’ai dit en introduction. C’était LA grande inquiétude que j’avais. Quand j’ai fais la demande de temps partiel, je ne savais pas à quoi m’attendre de la part de mon manager, de mes collègues, des RHs…

Au final, j’ai été très vite rassuré. Je ne sais pas si cette situation s’est généralisée, si les mentalités ont évolués, si je suis bien tombé, etc.

Les retours sur ma décision ont été extrêmement positifs. La plupart des gens ont été très compréhensifs :

  • A aucun moment je n’ai eu de remarque négative ou sexiste, dans un environnement très masculin
  • Mon manager (et son remplaçant) ainsi que les ressources humaines ont accepté mon choix avec bienveillance
  • Lorsque je leur en ai parlé, certains collègues et connaissances ont exprimé l’envie de faire pareil

C’est bête à dire peut être, mais c’est aussi ce genre de choses qui font que je suis bien au travail : être compris en tant qu’être humain, avec mes priorités, au-delà de la simple productivité brute.

Des études sur le temps au travail dans l’IT ?

En cherchant à en savoir plus, j’ai eu du mal à trouver des chiffres sur les temps partiels dans l’IT. Je n’ai trouvé que 2 études et malheureusement avec assez peu de répondants :

  • une de fin 2011 sur developper.com qui montrait que la majorité des salariés de l’IT bossaient plus que 40h/semaine, avec un taux de "temps partiel" extrêmement faible (2%)
  • l’étude faite en fin d’année par Okiwi, limités au bassin bordelais, qui montre une bien meilleure proportion sous les 35h/semaine (autour de 8%). Naïvement, je suis tenté de penser que le monde du travail évolue dans le bon sens, même si rien ne permet de s’assurer que le temps partiel correspond à une réelle volonté des salariés d’y être et pas une situation subie

Est ce que ça gêne l’organisation de l’équipe ?

C’était une autre question. Dans la mesure du possible, ma seconde priorité était quand même que ma décision impacte le moins possible mon équipe.

Dans la pratique, ça aurait été un peu plus compliqué si le plan initial du 80% avait pu aboutir, car je fais aussi des astreintes. Évidemment, je ne peux pas être d’astreinte en même temps que je suis de garde avec ma fille.

Au final, en 90% avec seulement un mercredi sur deux où je ne suis pas dispo, je n’impacte pas ni la rotation des astreintes, ni l’exploitation courante des infrastructures et des services que je gère. L’équipe est suffisamment multi-compétences pour répondre, au moins au premier niveau, à toutes les problématiques que je gère habituellement.

Qu’est ce que ça change dans mon travail ?

Concrètement, pas grand chose. Déjà, le fait que mon 90% soit organisé de la sorte implique qu’une semaine sur deux, je travaille normalement.

Ensuite, comme nous communiquons beaucoup par messagerie instantanée et par mail, il est très facile pour moi ou mes collègues de prévenir quand je ne suis pas disponible.

Pour ce qui est de mon travail en lui même, au-delà de la simple exploitation des services informatiques, il faut juste en tenir compte lorsqu’on planifie des deadlines.

Éventuellement, la seule petite difficulté que j’ai c’est lorsque je dois dépiler une tonne de mails et de slack le jeudi matin, car la plupart des mes collègues ont travaillés normalement le mercredi. De toute façon, la plupart ayant déjà été traités par quelqu’un d’autre.

M’occuper de ma famille

Parce que c’est finalement le but ! Avoir plus de temps pour profiter des miens.

Si jamais le doute persiste toujours, j’aimerai vous confirmer que ce jour où je ne travaille pas est tout sauf un jour de congés ! S’occuper seul, toute une journée, d’une petite d’un an et demi ce n’est vraiment pas reposant ;-p.

Il y a une vraie différence entre un week end (où on peut voir la famille, voir des amis, s’en occuper alternativement, …). Le mercredi, si vous ne faites rien, vous êtes seuls et ça peut devenir long.

Ce que j’en retire

Car au final, il ne faut pas oublier que je fais AUSSI ce 90% pour moi.

Passer du temps pour s’occuper de notre fille, "c’est notre projet".

J’ai vraiment l’impression de passer du temps avec elle. Le week end passe toujours très vite, il y a toujours beaucoup à faire… Et le soir, même en s’organisant pour être à la maison à 18h (ce qui n’est déjà pas très startup-nation), avec un dodo à 19h30, certes on rigole mais c’est vite fini. On profite, mais on ne prend pas le temps.

Ce mercredi sur 2, c’est du temps où je ne m’occupe QUE d’elle. C’est un temps entre elle et moi.

Récap’ de mon 90%

Voilà donc en résumé, après 1 an, ce que je pense de mon 90% :

  • c’est une baisse de revenus (10% de nos salaires) qui n’est pas neutre. Ma femme et moi avons la chance de pouvoir le faire mais nous sommes conscient que ce n’est pas le cas de tout le monde.
  • dans mon entourage, les gens ont plutôt bien compris notre choix. Certains ont même eu envie de le faire à leur tour.
  • dans mon entreprise, ce choix est très bien compris et accepté. Les mentalités changent et c’est bien !
  • il faut trouver des choses à faire pour profiter pleinement de cette journée en plus avec vos enfants. Moi qui suis plutôt introverti et casanier, il a fallut que je sorte de ma zone de confort mais c’est vraiment pour le mieux.
  • je me sens vraiment acteur de l’épanouissement de ma fille, ce qui était le but dès le départ.

Inutile de le dire, j’ai évidemment prolongé d’un an supplémentaire :-)

Si vous voulez discuter de ça avec moi, n’hésitez pas à laisser un commentaire, à me contacter sur Twitter ou m’écrire un e-mail.

Bonus

L’envie d’écrire cet article a été aussi inspirée par ce post de Fabien LAMARQUE, un indépendant sur Bordeaux, qui, pour d’autres raisons, a cherché lui aussi un autre équilibre vie pro/vie perso que le classique "5 jours par semaine".

Dans un tout autre genre, je vous conseille cet excellent sketch de Karim Duval "Élever son enfant en mode Start-up" qui me fait mourir de rire.

Source : https://www.youtube.com/watch?v=Ps3UNPLpmKc

Cet article Retour d’expérience : 1 an à 90% est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2020/02/03/retour-dexperience-1-an-a-90/feed/ 18 5357