diff --git a/content/Discussions/marre-filtrage-securite-hebergeurs.md b/content/Discussions/marre-filtrage-securite-hebergeurs.md new file mode 100644 index 0000000..a10e945 --- /dev/null +++ b/content/Discussions/marre-filtrage-securite-hebergeurs.md @@ -0,0 +1,87 @@ +Title: Marre du filtrage "sécurité" des hébergeurs ! +subtitle: ; On rale +Date: 2012-09-05 18:57 +Modified: 2012-09-05 18:57 +Tags: online, hébergement, sécurité, blocage +keywords: online, hébergement, sécurité, blocage +Slug: marre-filtrage-securite-hebergeurs +Authors: Victor +Status: published + +[TOC] + +## Votre hébergeur roxx ! + +
Auneffet, ses serveurs HP et DELL vous donne accès à une carte ILO ou DRAC, qui permet de faire plein de choses sympas pour gérer votre serveur à un niveau supérieur.
+ +Entre autre, grâce à ces cartes, vous pouvez décider de booter votre serveur sur une iso de votre cru, qui est bien sûr votre distribution Linux préférée trop bien que vous pouvez plus vous en passer.
+ +(Ou alors, vous voulez juste installer un système en gérant correctement le partitionnement, ce qui est pas encore gagné via les interfaces web...).
+ ++ +
Sauf que bon, charger une image iso de 600Mo depuis chez vous, avec votre ADSL de merde by "******", ça rend tout de suite le truc moins sexy.
+ +C'est alors que tout frétillant vous vous dites "Mais oui" !
+ +Car oui ! vous avez un autre serveur dédié chez le même hébergeur (car décidément vous le kiffez à mort).
+ +Quoi de plus simple alors que d'installer une petite machine virtuelle sur le deuxième serveur, avec une interface graphique pour lancer la magnifique applet (appliquette) java permettant de faire votre bonheur ?
+ +## Et ouais. Sauf que non + +[MODE GROGNE : ON]
+ +Car, pour des raisons plus ou moins fallacieuses, vous allez vite déchanter.
+ +Votre hébergeur, dans un souci constant de pourvoyer à votre sécurité (Ca fait partie du contrat ??) applique un filtrage sur ce qui se passe dans son réseau.
+ +Manque de bol, il considère ses propres adresses IP comme pas de confiance, et donc bloque tout accès à sa propre console depuis une machine de son propre réseau. (On croit rêver...)
+ +Comment font les techniciens pour intervenir ? Mystère... Sans doute un VPN/proxy installé chez un concurrent est-il le seul moyen pour les pauvres hères de travailler dans des conditions décentes.
+ +Quoiqu'il en soit, après avoir installé votre distribution GNU/Linux avec une interface graphique GNU/Linux, avoir fait la configuration de NAT qui va bien (car votre hébergeur est toujours un gros extrémiste sécurise son réseau, voir plus bas) vous chargez votre navigateur libre préféré, et vous vous mangez un méchant "403, Forbidden". Autrement nommé "Mais c'est pas vrai, y'a une erreur ! WTF ?"
Sauf que, forum à l'appui, d'erreur il n'y a point.
+ +Pour éviter tout système de rebond (Entendez un méchant qui a piraté un serveur et qui voudrait accéder à la console pour en acheter un autre), on bloque, sans possibilité de rémission. Sans se poser de questions. Et tant qu'à faire, sans même un message un peu verbeux (403 Forbidden Apache powaa!)
+ +Résultat des courses : Vous vous résignez finalement à charger votre iso via votre machine locale, avec votre connexion ADSL à l'upload plus que douteux. Si en plus vous êtes en entreprise et que tout le reste de la boîte utilise la même connexion pour powner du FTP ou télécharger des contenus sous licence Creative Commons, préparez vous à avoir des remontées violentes. Mais bon vous bossez, c'pas d'votre faute hein.
+ ++ +
Résultat des courses, 2eme vue : Vous avez perdu 1h à installer votre machine virtuelle, pour rien. Vous perdez ensuite 5h de votre journée à regarder avancer une jauge à la con. Bah oui, parce que comme c'est sécurisé, il y a un timeout, donc si jamais vous êtes pas là à cliquer régulièrement sur votre applet java pour lui dire que sisi, ça bosse toujours, vous êtes bons pour recommencer.
+ +Accessoirement, avec un upload moyen de 70Kb/s, vous allez encore moins vite qu'un lecteur CD 1x. Croyez moi, s'pas gagné.
+ +## Et en plus... + +Et en plus, comme votre hébergeur est toujours un gros extremiste sécurise son réseau, pendant que vous configuriez votre petite machine virtuelle (avant de vous rendre compte que ça servait à rien, j'entends) vous avez commencé par la lancer avec une IP privée, comme ça à l'arrache.
Sauf que, ni une, ni deux, elle a envoyé quelques paquets innocent avec son adresse privée et sa MAC bidon sur le réseau de votre hébergeur (bah oui, pas eu le temps de configurer un NAT, ou même d'y penser). Celui-ci, malin, va bloquer ces paquets rapidement.
+ +Mais aussi, parce que ça ne mange pas de pain, il va également bloquer tout accès à votre serveur ! Plus de SSH, plus d'interface web, même plus de console en ligne ! (Sans parler d'ILO ou de DRAC)
+ +Pendant un temps plus ou moins variable, vous ne pouvez plus rien faire. Sans même savoir pourquoi d'ailleurs, puisque vous avez juste droit à un gros message rouge vous disant que "c'est con hein, mais c'est bloqué. C'est votre faute z'aviez qu'à pas <Insert blank here>".
+ +Pour peu que à peine le réseau revenu vous refassiez la même erreur 2, 3, 4 fois avant de comprendre ?
+ +Pour peu que vous ayiez lancé un ping sur votre VM pour tester la connexion, et qu'au fur et à mesure que le réseau soit débloqué, la VM continue son ping et vous rebloque de nouveau...
+ +Vous avez perdu encore une petite heure, au bas mot. (Soyons large, on est des pros ici, on comprends vite d'où ça peut venir ces petites erreurs là.)
+ ++ +## Mais au final + +
Au final, vous avez déjà perdu 7h, vous êtes plus à ça près, s'pas ?
+ +Et puis, ça vous laisse plein de temps pour chercher avec votre connexion surchargée le nom d'un autre hébergeur chez qui migrer au plus vite... Pour vous rendre compte qu'en fait, ils sont tous hors de prix tout en étant pire dans leur gestion réseau.
+ ++ +
Conclusion : L'auto-hébergement, c'est le bien !
+ +[MODE GROGNE : OFF]
+ +Nota : bien sûr, personne ne doit se sentir insulté ou calomnié par ce texte, résultat de mon cerveau brouillon et sans prétention devant tant de capacités techniques employées pour faire le bien.
diff --git a/content/Discussions/virtualisation-bienfait-du-cloud.md b/content/Discussions/virtualisation-bienfait-du-cloud.md new file mode 100644 index 0000000..c17d8dc --- /dev/null +++ b/content/Discussions/virtualisation-bienfait-du-cloud.md @@ -0,0 +1,132 @@ +Title: La virtualisation, ou l'un des (seul ?) bienfait du cloud +Date: 2012-08-15 17:51 +Modified: 2012-08-15 17:51 +Tags: linux, debian, virtualisation +keywords: linux, debian, virtualisation +Slug: virtualisation-bienfait-du-cloud +Authors: Victor +Status: published + +[TOC] + +## La virtualisation, qu'est ce que c'est ? + +La virtualisation de serveur, ça consiste à se servir d'une machine physique pour émuler plusieurs machines dites 'virtuelles'. La machine physique, autrement nommée Hyperviseur, va permettre de gérer de A à Z les machines virtuelles hébergées.
+ +Gestion processeur, RAM, espace disque, réseau, extinction, ... l'hyperviseur à la main sur tout ce qui à trait à ses machines virtuelles (VM pour Virtual Machine)
+ +Chaque machine virtuelle par contre, vu de l'intérieur, est autonome. On la démarre, et le système à l'intérieur fonctionne tout seul, sans intervention extérieure. De son point de vue, elle est une machine physique. Elle dispose d'une configuration propre (définie par l'hyperviseur, vous suivez ?), et elle n'a pas "conscience" d'être en fait un sous ensemble d'une plus grosse machine physique.
+ +Bien sûr, chaque hyperviseur a ses limites, il n'est pas possible d'installer trop de machines sur un serveur physique. La RAM que vous allouez par exemple à vos VM ne peut pas dépasser la RAM totale de l'hyperviseur, etc.
+ ++ +
Bref, ça a l'air super sexy, mais enfin bon, quelle utilité ?
+ ++ +## De l'utilité de la virtualisation + +
D'abord, une constatation évidente. De nos jours, le moindre serveur dédié que vous pouvez louer est surdimensionné (à moins que vous ne souhaitiez vraiment faire tourner 70 sites web à vous tout seul, associé à 10000 adresses courriels et une 30aine de serveurs Counter Strike©
+ +Tout ça tournant bien sûr en vrac sur le serveur. Et si tout plante, et ben c'est con, mais y'a plus rien dis donc.
+ +Sinon, vous avez une machine énorme pour faire tourner votre site web, et si vous voulez partager un peu vos services, ben vous achetez une deuxième machine énorme pour faire tourner votre serveur Teamspeak et votre Counter Strike©
+ +### Séparons les services ! Tous les oeufs ne vont pas dans le même panier + +Le premier avantage à virtualiser, c'est que vous pouvez créer autant de machine virtuelle que de services que vous souhaitez faire tourner, par exemple.
+ +Ainsi, une machine pour vos sites web, une machine pour votre serveur courriel, une machine pour les serveurs de jeu, etc. De cette façon, vous capitalisez un seul serveur physique pour tous vos services, sans que ceux-ci ne se marchent dessus !
+ +Et en plus, ça vous permet de répartir exactement quelle ressource physique (processeur, RAM, ...) vous voulez allouer à vos services.
+ +Un pirate attaque votre serveur web en saturant la RAM ? Pas grave, seul les petits 512Mo que vous lui aviez alloué vont se remplir. La VM va planter, les sites web devenir inaccessibles, mais pendant ce temps tout le reste continuera à tourner.
+ +D'ailleurs, parlons sécurité.
+ +### Séparons les services ! bis. Le panier, il fuit pas + +Et oui, l'un des autres gros avantages, c'est que si la machine qui contient votre serveur web (imaginons une faille dans apache par exemple), est compromise par un pirate, et bien, seule cette machine est compromise.
+ +Comme de son point de vue elle est une machine physique à part entière, elle n'a pas de moyen "physique" de joindre les autres machines virtuelles, sauf par le réseau classique.
+ +Du coup, le pirate peut effectivement s'amuser avec les sites web (ça, on ne peut malheureusement rien y faire), mais même s'il sature la mémoire, remplit le disque dur, surcharge le processeur, attaque la base mysql ou que sais-je d'autre, ça restera confiné à cette machine. Et les limitations mises en place par l'hyperviseur feront que ces dommages resteront minimes du point de vue des autres machines.
+ +De plus, dans l'idéal le pirate n'a aucun moyen de savoir que cette machine est en réalité une machine virtuelle, il n'est donc pas tenté d'attaquer le reste des services. (Enfin, à la limitation que ces services ne soient pas visibles sur Internet. Sinon à moins d'être débile, notre pirate aura au moins des doutes.)
+ ++ +### Limitons les services : moins y'a de portes, plus c'est dur d'entrer + +
Bien sûr, l'hyperviseur lui-même est le gros maillon faible de l'infrastructure. Si lui se trouvait être compromis, alors toutes les machines virtuelles seraient potentiellement en danger. Mais en y réfléchissant, ça serait pareil si tout tournait sur le serveur physique. S'il était compromis, tout serait compromis. Et en plus, il y aurait plus de porte pour y entrer.
+ +En effet, chaque service (courriel, web, serveur de jeu) ouvert sur Internet est une porte potentielle pour un pirate, qui peut essayer de la forcer pour entrer sur votre serveur et mettre la pagaille.
+ +Là, comme en théorie l'hyperviseur ne fait tourner aucun service dit sensible, il peut très bien être complètement invisible depuis Internet ! Et moins il y a de portes, plus c'est facile de les surveiller. Chaque machine peut avoir un bon gros pare-feu qui n'autorise que son service, limitant ainsi beaucoup les effets de bord.
+ +Pour que ça soit encore plus cool, la plupart des hyperviseur implémentent un moyen de se connecter sur ses machines virtuelles. En gros, connectez vous sur l'hyperviseur, vous pourrez vous connecter sur toutes les machines. Ca peut sembler evident, mais ça permet du coup de se passer de tout accès SSH, telnet, rdp, ... sur les machines. Donc, d'autant de services offrant des opportunités d'entrer pour un pirate :-)
+ ++ +### Groupons les sauvegardes et migrons les machines + +
Un autre point sympathique de la virtualisation, c'est la gestion des sauvegardes. Tout hyperviseur digne de ce nom vous permet de sauvegarder l'intégralité d'une VM.
+ +Il est ainsi extremement simple de sauvegarder toutes vos machines virtuelles, et de redonder ces sauvegardes pour que même en cas de coupure de courant, de disque qui lâche ou de guerre nucléaire, vous ayez tout ce qu'il faut sous le tapis.
+ +Et en plus, les machines virtuelles ont le bon goût de ne pas trop se soucier de l'hyperviseur qui les fait tourner. C'est à dire que en cas de coupure de courant, de disque qui lâche ou de guerre nucléaire, vous prenez votre petite sauvegarde, un autre serveur avec l'hyperviseur installé, et hop, toutes vos machines redémarrent !
+ +Au prix éventuellement d'une petite reconfiguration d'adresses IP et de serveurs DNS, tous vos services peuvent être disponible de nouveau en un temps très court. Et plus court encore si vous avez prévu le coup et avez déjà une copie de votre hyperviseur prête à l'emploi à tout moment.
+ ++ +## J'y crois pas, y'a forcément un mais + +
Oui bon ok, il y a aussi des points négatifs.
+ +### Accès à l'hyperviseur + +L'un d'eux, c'est que si vous voulez accéder à votre hyperviseur pour ensuite accéder à vos machines (et ainsi vous affranchir de l'accès à vos machines une par une), il faut ouvrir ce service sur l'hyperviseur. Eventuellement depuis Internet.
+ +Bon, dans le cas d'un serveur sous Windows, je ne vous cacherai pas qu'un vieux Remote Desktop Server bien pas sécurisé, bien moche et bien connu du moindre bébé pirate sorti du ventre de sa mère, ça pue. Ca pue vraiment. Laisser votre hyperviseur avec "ça" ouvert sur le net, c'est se tirer une balle dans la tête (non non, même pas dans le pied, dans la tête)
+ +Après, si vous êtes quelqu'un de sérieux (troll inside) et que vous faites vos serveurs sous Linux/Unix, laisser un accès SSH ouvert, c'est acceptable. SSH est bien connu, très régulièrement mis à jour, facile à sécuriser. Je peux d'ailleurs vous conseiller un petit fail2ban à cet effet, simple et très efficace.
+ +Là, on est propre, et on peut se connecter assez sereinement à notre hyperviseur.
+ ++ +### La taille des sauvegarde + +
Malheureusement ça, c'est un fait. Sauvegarder des machines entières, ça prend de la place. Là où avant vous sauvegardiez un dossier avec vos sites, deux ou trois fichier de conf et une base de données, vous devez maintenant sauvegarder plusieurs serveurs. Chacun embarquant son système d'exploitation à lui. Et là, ça peut vite faire mal niveau espace disque nécessaire pour tout sauvegarder.
+ +Mais bon, au moins vos machine sauvegardées peuvent repartir à tout moment. C'est déjà ça, hein ?
+ ++ +### Les mises à jour - Aie ! + +
Mais le vrai gros point noir de la virtualisation d'après moi, c'est la gestion des mises à jour.
+ +En effet, si vos machines sont accessibles depuis le net, elles DOIVENT être à jour. On ne reviendra pas là dessus.
+ +Cependant, avoir 4 machines qui tournent, c'est devoir mettre 4 machines à jour. L'hyperviseur, la VM du serveur web, la VM du serveur courriel et la VM de votre serveur de jeu doivent être mise à jour séparement.
+ +Et ça, ça fait mal. C'est chronophage. C'est redondant. Ca pique. Et ça ennuie...
+ +On peut tenter du script de mise à jour automatique, toutes les nuits. On lance la mise à jour, on répond automatiquement oui à toutes les questions, et c'est finit. Oui, jusqu'à ce qu'un fichier de conf soit changé durant la mise à jour, jusqu'à ce qu'un nouveau paramètre fasse son apparition, jusqu'à ce que... Bref, c'est prendre le risque qu'en vous levant un matin, plus rien ne fonctionne, et que vous deviez restaurer une sauvegarde de la veille faute de trouver qu'est ce qui a exactement été changé...
+ +Donc non, mise à jour à la main, et une par une.
+ +Et ça, malgré mes diverses recherches, je n'ai pas encore réussit à m'en affranchir dans le monde de la virtualisation...
+ ++ +## Mais bon, c'est trop bien quand même ! + +
Oui, parce qu'avec tous les avantages, ça serait quand même dommage de finir sur une note négative !
+ +Pour ma part, je virtualise exclusivement sous debian, et j'utilise un outil nommé proxmox. D'ailleurs, je prévoie un petit article à ce sujet bientôt :-)
+ +EDIT : article rédigé ici.
diff --git a/content/Réseaux/dns-dynamique-ovh-avec-wrt54gl.md b/content/Réseaux/dns-dynamique-ovh-avec-wrt54gl.md new file mode 100644 index 0000000..e335d95 --- /dev/null +++ b/content/Réseaux/dns-dynamique-ovh-avec-wrt54gl.md @@ -0,0 +1,90 @@ +Title: Utiliser un DNS dynamique chez OVH avec un WRT54GL sur tomato +Date: 2012-09-11 21:16 +Modified: 2012-09-11 21:16 +Tags: DynDNS OVH, DNS dynamique, tomato, WRT54GL +keywords: DynDNS OVH, DNS dynamique, tomato, WRT54GL +Slug: dns-dynamique-ovh-avec-wrt54gl +Authors: Victor +Status: published + +[TOC] + +## Oui, le titre est long, et alors ? + +Si on faisait toujours des titres courts, ça serait pas référencés sur Google ! (#oupas)
+ +Bon, cet article est sérieux, attaquons.
+ ++ +
Dernièrement, j'ai vu que OVH, en tant que registrer (chez qui on achète ses noms de domaine), proposait de configurer directement des entrées DNS Dynamique.
+ +Option plutôt sympathique il faut l'avouer, ça permet de gérer facilement ses noms de domaine avec IP dynamique. Quelques limitations sont à prévoir, notamment au niveau de la mise à jour de l'enregistrement. On est là pour en parler :-)
+ ++ +## C'est quoi un DNS Dynamique ? + +
Un DNS dynamique, c'est en fait un DNS classique, mais avec un temps de réplication et de cache (TTL) très court.
+ +Ceci, associé à un logiciel spécifique installé chez le client, permet d'avoir un nom de domaine qui se met à jour très rapidement à l'échelle mondiale. Cela permet notamment de gérer facilement lorsque vous avez besoin de joindre quelque chose chez vous (NAS, PC en VNC, auto-hébergement, ...) et que vous avez un FAI qui ne vous donne qu'une IP dynamique, c'est à dire qui change régulièrement.
+ +En mettant à jour votre nom de domaine en DNS Dynamique dès que votre adresse IP change, cela permet d'avoir un temps d'indisponibilité assez court, à n'importe quel moment. En plus, ça se fait souvent en automatique.
+ +C'est un système un peu batard né de l'utilisation du NAT et des IP privées, et nécessaire à cause des FAI trouvant plus simple de vous changer d'IP plutôt que de vous en filer une fixe. (On se demandera à jamais pourquoi)
+ +## Une bonne idée, mais... + +Bon, les définitions étant posées, parlons maintenant plus particulièrement du service d'OVH.
+ +Proposer des DNS dynamiques, c'est bien, mais comme vu plus haut, ça nécessite une interaction côté client pour mettre à jour en temps réel (idéalement) l'entrée DNS.
+ +Pour cela, OVH propose dans sa documentation divers logiciels à installer chez vous qui se chargent du boulot. Windows et Linux sont au rendez vous, mais malheureusement, la plupart de ces logiciels sont fait pour être installés sur votre PC perso, voir un serveur maison.
+ +De plus, ils sont pour la plupart basés sur le fait que votre PC perso/votre serveur porte l'IP publique dynamique, ce qui est quand même très rare. (BiduleBox powaa !)
+ +On peut s'en sortir avec un vérificateur d'adresse IP externe.
+ +Mais la grosse limitation intervient lorsque l'on veut configurer cette mise à jour directement sur un routeur (accessoirement une BiduleBox). Ce qui est plus logique, puisque ce sont souvent eux qui portent l'IP publique dynamique.
+ +Or, à moins que votre routeur propose directement de profiter du service OVH, vous allez devoir utiliser une URL HTTP pour faire cette mise à jour. Et ça, point de trace sur la documentation OVH, ni sur les forum, malgré quelques post courageux de personnes bien intentionnées.
+ ++ +## L'exemple du WRT54GL Tomato + +
J'utilise pour ma part un routeur Linksys WRT54GL, excellent produit, avec le firmware tomato. Bien qu'assez riche en option pour configurer le DNS dynamique, ce firmware ne propose pas par défaut OVH. (Ni d'ailleurs aucun firmware WRT54GL à ma connaissance)
+ +Ce firmware propose toutefois d'entrer une URL personnalisée pour aller mettre à jour votre enregistrement DNS. Plutôt sympathique, encore faut-il connaitre cette URL. Comme OVH n'en parle pas, il faut chercher.
+ +Pour ma part, j'ai du regrouper plusieurs sites/blog en parlant pour réussir à obtenir une URL utilisable, je vous la fournit donc, après tout c'est l'info que vous cherchiez en venant ici ;-)
+ +Donc, dans le menu Basic -> DDNS -> Dynamic DNS 1 :
+ +Où :
+ +N'oubliez pas de modifier dans le premier menu déroulant l'option que vous souhaitez :
+ +Cochez "Force next update" pour que la mise à jour se fasse tout de suite, puis cliquez sur "Save".
+ +La mise à jour va s'effectuer, et si tout va bien mettre à jour le DNS sans erreurs.
+ +Voila, en espérant que ça serve à quelqu'un dans le meilleur des mondes
diff --git a/content/Système/configurer-reverse-proxy-apache.md b/content/Système/configurer-reverse-proxy-apache.md new file mode 100644 index 0000000..46bcfaa --- /dev/null +++ b/content/Système/configurer-reverse-proxy-apache.md @@ -0,0 +1,303 @@ +Title: Configurer un reverse proxy Apache +subtitle: (HTTP/HTTPS) +Date: 2012-10-16 20:06 +Modified: 2012-10-16 20:06 +Tags: reverse proxy, apache, debian, linux, nom de domaine +keywords: reverse proxy, apache, debian, linux, nom de domaine +Slug: configurer-reverse-proxy-apache +Authors: Victor +Status: published + +[TOC] + +## Ou : routage entre serveurs par nom de domaine + +Et oui, c'est ce dont on va parler ici. Comme ce n'est peut être pas très clair pour tout le monde, je vais me permettre une toute petite digression pour expliquer ce qu'est le routage, et plus précisément ce que j'appelle le routage par noms de domaine.
+ +## Merci pour cette digression. + +Mais de rien.
+ +Qu'est ce que le routage ? Ca consiste à se servir d'une unique machine (comunément appelée "le routeur") pour diriger des flux réseau vers différents autres matériels.
+ +Ca sert le plus simplement du monde sur Internet, pour router les différents sous réseaux. Vous voulez joindre truc.truc.truc.truc, mais vous avez comme IP machin.machin.machin.machin, alors un routeur va pouvoir vous dire :
+ +"Pour aller vers truc, c'est à gauche, mais si c'est pour aller vers bidule, c'est à droite. Quand à toi machin, tu es au milieu".
+ +Ok, c'est résumé très vite pour les puristes, mais l'idée est là :-)
+ +Il existe différents autres types de routage. On utilise ce terme parce que l'idée de donner des routes (ou des chemins) pour diriger des flux reste la même.
+ +Une machine (routeur, PC, serveur, ...) reçoit un flux, et à partir de différents critères choisit de rediriger ce flux vers un autre matériel du réseau, l'objectif final étant bien sûr que ce flux arrive à destination de manière sûre.
+ +## Ca suffit oui ? + +On y arrive. ;-)
+ +EDIT décembre 2015 : j'ai écris un nouvel article pour utiliser haproxy en tant que reverse-proxy, logiciel plus léger et plus adapté qu'apache à cet usage.
+ +Or donc, si vous avez plusieurs serveurs web mais une seule connexion Internet, alors vous avez sans doute déjà eu cette problématique.
+ +Comment joindre plusieurs sites web sur différents serveurs depuis les Internet ?
+ +La solution qui s'impose directement, c'est du routage de port.
+ +Ce routage particulier consiste à router différents flux reçus depuis Internet vers des machines à l'intérieur de votre réseau local en se basant sur les ports réseaux utilisés. Ce n'est pas le lieu pour décrire un port réseau. Voyez ça comme une porte. Vous rentrez dans la même maison, mais selon que vous utilisiez la porte d'entrée ou la véranda, vous êtes "redirigés" vers une pièce différente de la maison.
+ ++ +
Ce type de routage présente un inconvénient certain : chacun de vos utilisateurs doit spécifier la porte qu'il veut utiliser pour joindre le bon serveur.
+ +En général, ça consiste à taper nomdedomaine.tld:port dans votre navigateur, ce qui n'est pas très pratique, et difficile à expliquer à vos clients. (Et oubliez de suite expliquer ça à Google and co)
+ +C'est là qu'intervient ce super outil, le reverse proxy, ou mandataire inverse. Nous allons voir ici comment l'utiliser avec Apache, un serveur web populaire. Il est sans doute possible de le faire également avec NGinX ou lightHTTPD, mais ce n'est pas le sujet :-D
+ +Le mandataire inverse va regarder le site que vous voulez joindre, et vous rediriger vers le bon serveur directement. Il servira ensuite d'intermédiaire sur le réseau entre vous et le serveur.
+ +## On veut du concret ! + +Voila voila !
+ +### Pré-requis matériel + +Pour commencer, il va falloir définir un serveur mandataire. C'est sur ce serveur que nous allons configurer le mandataire inverse.
+ +Il peut héberger lui-même des sites Internet, ou vous pouvez l'utiliser uniquement comme mandataire, ça n'a pas d'importance. Si vous utilisez cette solution à des vues industrielles, mieux vaut prévoir un serveur robuste, puisqu'il supportera toutes les requêtes vers tous vos sites web.
+ +Ensuite, il vous faut configurer votre routeur/machinbox© pour rediriger tout le flux web (port 80) vers le serveur mandataire. Ceci se fait grâce à un routage de port classique. Toutes les requêtes web arriveront maintenant sur ce serveur, qui va décider quoi en faire.
+ +En théorie on devrait pouvoir faire la même chose pour l'HTTPS, mais vu qu'il y a quand même des contraintes de certificats et que je n'ai pas testé, je préfère ne pas dire de bêtises ici.
+ +### Prérequis logiciel + +Là, c'est simple. Il vous faut un serveur Apache installé et fonctionnel sur votre serveur mandataire. C'est tout. Un système de pare-feu ne serait également pas de trop (ce serveur est l'unique point d'entrée d'Internet, rappelons le :-) )
+ +Il vous faut également (bien evidemment ?) une connexion ssh vers votre serveur, ou à défaut un écran-clavier-souris.
+ +## Plongeons dans le cambouis + +### Activation du module proxy Apache + +Connectez vous sur votre serveur (mandataire), puis tapez :
+ ++$ sudo a2enmod proxy + +$ sudo a2enmod proxy_http+ +
+ +
Redémarrez ensuite Apache un petit coup
+ ++$sudo /etc/init.d/apache restart+ +
+ +
Voila, c'est fait !
+ +### Configuration du routage + +Ici, tout va se faire grâce au système d'hôte virtuel Apache.
+ +Editez un fichier dans /etc/apache2/site-available/
+ ++$ sudo nano /etc/apache2/sites-available/monsite+ +
+ +
Puis configurez votre hôte comme suit :
+ ++<VirtualHost *:80> +# +ServerName nomdedomaine.tld # +ProxyPreserveHost On +ProxyRequests off +ProxyPass / http://IPSERVEURWEBINTERNE/ +ProxyPassReverse / http://IPSERVEURWEBINTERNE/ +# +</VirtualHost>+ +
+ +
Cela va permettre de rediriger toutes les requêtes sur nomdedomaine.tld en http vers le serveur IPSERVEURWEBINTERNE
+ ++ +
C'est simple et efficace. Vous pouvez créer toutes vos autres redirections dans ce fichier, ou créer un fichier par redirection (plus propre mais plus contraignant). A vous de voir.
+ +Une fois ces fichier créés, il vous faut activer les hôtes virtuels.
+ +Faites
+ ++$ sudo a2ensite monsite ++ +
pour chaque fichier que vous avez créé.
+ ++ +
Ensuite, rechargez la configuration Apache (pas besoin de redémarrer)
+ ++$ sudo /etc/init.d/apache2 reload+ +
+ +## Tadam ! + +
Il ne vous reste plus qu'à tester. De l'exterieur, essayez de joindre nomdedomaine.tld, tout doit fonctionner :-)
+ +Et voila, vous avez économisé plein d'adresses IP publiques ! Mais pourquoi utiliser plusieurs serveurs Web derrière une seule IP petits coquinous ? Ça, ça vous regarde...
+ +Si jamais j'ai la problématique un jour, je configurerai ça pour de l'HTTPS (mais honnêtement j'espère jamais :-D )
+ ++ +
Et dans ce cas je rajouterai ça sur le blog, promis ! Voir juste au dessous !
Et oui, car finalement j'ai du m'y mettre :)
+ +Tout d'abord, les limitations. Je n'ai réussit jusqu'alors qu'à configurer une connexion HTTPS entre le client et le reverse proxy.
+ +Je n'ai pas réussit à avoir ensuite de l'HTTPS entre le reverse proxy et le vrai serveur web, ce qui veut dire que, au moins sur le réseau local, les données transitent en clair.
+ +De mon point de vue ce n'est qu'un problème conceptuel, étant donné que le "réseau local" est en fait une liaison directe entre machines virtuelles sur le même hyperviseur, donc bon. Mais quand même, ce n'est pas très propre. Si jamais quelqu'un a une suggestion à ce sujet, qu'il me fasse signe :)
+ ++ +
L'idée donc du reverse proxy en HTTPS, c'est que c'est le proxy qui va contenir les certificats https. Celui-ci va alors répondre à la place du serveur web, avec la bonne URL puique c'est un proxy, et transmettre ensuite les requêtes vers le serveur.
+ +On a donc un schéma dans cette idée :
+ +<Client> ====https====<Proxy>----http----<serveur web>
+ +Et en plus, c'est assez simple en fait.
+ +On considérera ici que vous avez déja généré des certificats propres pour votre site (éventuellement auto-signés).
+ +Il vous faudra activer le SSL sur votre reverse proxy :
+ ++$ sudo a2enmod ssl +$ sudo /etc/init.d/apache2 restart ++ +
Ensuite, placez vos certificats (clef publique, clef privée) dans le dossier /etc/apache2/ssl/.
+ ++$ sudo cp moncertificat.* /etc/apache2/ssl/ ++ +
Créez l'hôte virtuel qui servira pour votre redirection :
+ ++sudo nano /etc/apache2/site-available/monproxySSL ++ +
Et remplissez le avec ceci :
+ ++ <VirtualHost *:443> + + # Décommentez cette ligne et indiquez-y l'adresse courriel de l'administrateur du site + #ServerAdmin webmaster@my-domain.com + + # Classique, votre nom de domaine + ServerName monsite.tld + + # Si jamais vous avez d'autres domaines renvoyant sur ce site, utilisez la dircetive ServerAlias + # Vous pouvez utiliser le joker * pour prendre en compte tout les sous-domaines + #ServerAlias www2.my-domain.com www.my-other-domain.com *.yet-another-domain.com + + # L'emplacement des logs. + ErrorLog /var/log/apache2/monsite.tld-error.log + LogLevel warn + CustomLog /var/log/apache2/monsite.tld-access.log combined + + # SSL magic + # + # Il est nécessaire d'activer SSL, sinon c'est http qui sera utilisé + SSLEngine On + + # On autorise uniquement les clefs de cryptage longue (high) et moyenne (medium) + # SSLCipherSuite HIGH:MEDIUM + + # On autorise SSLV3 et TLSv1, on rejette le vieux SSLv2 + # SSLProtocol all -SSLv2 + + # La clef publique du serveur : + SSLCertificateFile /etc/apache2/ssl/moncertificat-cert.pem + + # La clef privée du serveur: + # SSLCertificateKeyFile /etc/apache2/ssl/moncertificat-key.pem + + # Theses lines only apply of the rewrite module is enabled. + # This is a security enhancement recommanded by the nessus tool. + <IfModule mod_rewrite.c> + RewriteEngine on + RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) + RewriteRule .* - [F] + </IfModule> + <IfModule mod_rewrite.c> + <IfModule mod_proxy.c> + + #Ne commentez jamais cette ligne, elle évite que votre serveur soit utilisé comme proxy par des gens mal-intentionnés. + ProxyRequests Off + + # Cetet option passe les nom d'hôte au serveur, ce qui vous permet d'utiliser également des hôtes virtuels sur le serveur principal. + ProxyPreserveHost On + + # Les lignes classiques de proxy. Comme dit au dessus, on passe le flux en http. + ProxyPassReverse / http://IPSERVEURWEB/ + RewriteRule ^/(.*) http://IPSERVERUWEB/$1 [P,L] + + </IfModule> + </IfModule> + + # Autoriser l'accès au contenu à travers le proxy. + #Ne l'enlevez pas si vous voulez que le site fonctionne ! + <Location /> + Order deny,allow + Allow from all + </Location> + + </VirtualHost> + + + <VirtualHost *:80> + # Cette partie va permettre de rediriger d'éventuelles requêtes en HTTP vers l'HTTPS + # Vous pouvez également configurer le proxy à la place de la règle de réécriture si vous voulez autoriser l'accès en HTTP + ServerName monsite.tld + + #ServerAlias www2.my-domain.com www.my-other-domain.com *.yet-another-domain.com + + # Theses lines only apply of the rewrite module is enabled. + # This is a security enhancement recommanded by the nessus tool. + <IfModule mod_rewrite.c> + RewriteEngine on + RewriteCond %{REQUEST_METHOD} ^{TRACE|TRACK} + RewriteRule .* - [F] + </IfModule> + + # On renvoit toutes les requêtes HTTP vers l'HTTPS. + Redirect permanent / https://monsite.tld/ + + </VirtualHost> ++ +
N'oubliez pas bien sûr d'activer votre nouvel hôte virtuel :
+ ++$ sudo a2ensite monproxyssl +$ sudo /etc/init.d/apache2 reload ++ +
Et voila, votre reverse proxy doit fonctionner en HTTPS :)
+ +diff --git a/content/Système/virtualisation-opensource-qui-roxx-proxmox.md b/content/Système/virtualisation-opensource-qui-roxx-proxmox.md new file mode 100644 index 0000000..f69457c --- /dev/null +++ b/content/Système/virtualisation-opensource-qui-roxx-proxmox.md @@ -0,0 +1,167 @@ +Title: La virtualisation open source qui roxx +subtitle: ; Proxmox +Date: 2012-09-04 20:00 +Modified: 2012-09-04 20:00 +Tags: debian, proxmox, linux, virtualisation +keywords: debian, proxmox, linux, virtualisation +Slug: virtualisation-opensource-qui-roxx-proxmox +Authors: Victor +Status: published + +[TOC] + +## Proxmox, kesaco ? + +
Comme je l'ai dit dans un précédent article sur la virtualisation, je trouve cette manière de fonctionner sur un serveur particulièrement intéressante.
+ +Comme je l'ai également dit à la fin de cet article, j'utilise pour ma part un outil de virtualisation open source nommé proxmox.
+ + + ++ +
Proxmox est un packaging disponibles pour de nombreuses versions de linux/unix, mais il existe une distribution basée sur debian et maintenue par Proxmox, que j'utilise pour sa simplicité et sa compatibilité. (Au moins, pas besoin de se demander si tel ou tel module noyau fonctionnera ou pas une fois installé le package proxmox...)
+ +Donc, la distribution debian Proxmox vous permet, une fois installée, de virtualiser via 2 techniques, OpenVZ et KVM, et de gérer toutes vos machines simplement via une interface web, de les sauvegarder en masse de manière programmée, tout en ayant un panel d'outils en ligne de commande sympathiques pour faire tout et n'importe quoi.
+ +Il est également possible de mettre en place un cluster entre plusieurs Proxmox, d'accéder aux VM via l'interface web avec une applet Java, etc etc.
+ ++ +
Je vais donc détailler dans cet articles les fonctionnalités de Proxmox, parce que j'ai bien envie d'en parler :)
+ +## Proxmox, réseau bridgé + +Avec proxmox, vous êtes automatiquement lié à différentes interfaces "bridgées". Ou plutôt, des interfaces de pont en français. En gros, un switch virtuel dans le serveur.
+ +C'est assez classique des hyperviseur, mais ça vaut le coup de le rappeller. Ca permet de lier les interfaces réseau des VM aux interfaces réseau physiques de l'hyperviseur, pour par exemple leur donner accès à Internet.
+ +Ca permet également de créer des interfaces bridgés pour créer un réseau interne dans le serveur, permettant de joindre en interne toutes les VM. Totalement étanche à l'extérieur, ça ouvre des possibilités intéressantes en matière de service sécurisés :-)
+ +L'utilisation de ce service permet vraiment de configurer tout et n'importe quoi de manière très simple. En effet vous pouvez ajouter de nombreuses interfaces à un bridge, par exemple des tap/tun pour openVPN, des interfaces dummy ou même d'autre bridges !
+ +De plus, vous pouvez grâce à iptables créer des règles spécifique sur cette interface, pour la rendre totalement étanche, comme un vrai switch physique.
+ +C'est sur ce principe qu'est basé le système réseau de proxmox, et il est vraiment très simple à utiliser et à exploiter.
+ ++ +## Containeurs OpenVZ, ou chroot en force + + + +### Quoique c'est ? + +
Bon, soit vous êtes admin système et vous avez compris le titre, soit non. Dans mon métier, on aime les trucs binaires !
+ +La virtualisation Open VZ va en fait consister à se servir du noyau système de l'hyperviseur pour faire fonctionner les machines virtuelles.
+ +Cela a plusieurs effets, positifs comme négatifs.
+ +En fait, vos machines virtuelles vont tourner en utilisant les ressources de base de l'hyperviseur. Contrairement à d'autres type de virtualisation, un OpenVZ va ainsi partager ses ressources directement avec l'hyperviseur.
+ +Concrètement, si cela permet d'utiliser différentes distributions linux dans vos machines virtuelles, vous ne pourrez pas utiliser de Windows. Toutes vos distributions seront basées sur le noyau de l'hyperviseur, c'est à dire un noyau linux.
+ +Installer un système Open VZ revient à choisir un "template", sorte d'image d'un véritable système d'exploitation, qui va être utilisé pour simuler ce système à destination de la machine virtuelle. De cette façon, du point de vue de la machine, le système sera correct et normal.
+ +Ensuite, en se basant sur ce template, l'hyperviseur va réaliser un gros "Chroot". Pour les néophytes ayant la flemme de lire wikipédia, l'hyperviseur va créer un dossier ayant une arborescence linux classique, puis va lancer la VM comme un processus classique en lui disant que son dossier racine / va être l'arborescence précedemment créée.
+ +En conséquence, tout les processus lancées dans la VM seront vus depuis l'hyperviseur, alors que la VM sera une machine à part entière.
+ +### osef non ? + +Ben non, ça amène pas mal d'avantages intéressants.
+ +Il y a surement plein d'autres choses, mais globalement c'est déjà des points très intéressants, selon les usages qu'on en a.
+ +Par contre, comme d'habitude, il y a aussi quelques inconvénients. Le noyaux étant émulé, il y a des choses qui ne fonctionnent pas dans le CT.
+ ++ +
Bref, il y a du pour et du contre. Perso, sauf pour certains usages très précis (IPSec ou tomcat avec Java...), je n'utilise que des CT sous OpenVZ. Optimisées et ultra rapides, ça serait vraiment dommage de s'en passer.
+ ++ +## KVM, le mode de secours + + + +
Bon, si vous tenez vraiment à faire tourner tomcat, à utiliser IPSec, voir à installer un client NTP. Ou pire, que vous n'aimez pas OpenVZ ou que vous tenez à utiliser Windows (ouh ! Haro !), proxmox n'a pas mis tous les oeufs dans le même panier et propose un deuxième système de virtualisation open source, j'ai nommé KVM.
+ +Une machine KVM est cette fois une véritable machine virtuelle, complètement indépendante de l'hyperviseur. Elle possède son propre noyau, ses propres interfaces réseaux et sa carte graphique, un disque dur bien défini, etc.
+ +Vous pouvez donc tout à fait l'utiliser pour faire tourner un système Windows si vous le souhaitez.
+ +Cette technique de virtualisation est robuste, mais aucun des avantages d'OpenVZ ne peut être appliqué à elle. En contrepartie, la plupart des inconvénients d'OpenVZ n'a pas de prise sur une KVM :-)
+ +Etant une "vraie" machine, une KVM va pouvoir utiliser ses propres modules noyaux (bonjour, IPSec), ainsi qu'une machine virtuelle java. On l'installe depuis une image iso classique, comme n'importe quel système d'exploitation.
+ +Pour ma part, je ne m'éteindrai pas trop dessus, car je n'utilise les KVM que si mon besoin ne peut vraiment pas se poser sur OpenVZ.
+ +KVM est certes plus complet, mais par rapport à OpenVZ, le fait d'avoir une vraie machine à émuler est aussi beaucoup plus lourd. Ca demande plus de ressource à l'hyperviseur, c'est bien plus long à éteindre et démarrer qu'un containeur, on est obligé d'y accéder via SSH ou avec les outils proxmox, ...
+ +Bref :-)
+ ++ +## Interface web, le bonus qui en jette + +
Bon, je ne vous ferait pas plein de screens super bô de l'interface web de gestion proxmox.
+ +Accessible nativement en https (c'est le bien), elle permet de quasiment tout gérer pour vos tâches quotidienne.
+ +GLobalement, avec simplement l'interface web, vous faites tourner tout un tas de machines virtuelles seulement en cliquant 2 ou 3 fois, depuis une interface web sécurisée.
+ +En rajoutant un peu de ssh et de ligne de commande, vous avez un service pro, redondé, sécurisé, permettant de lancer votre propre service de VPS dans votre salon si vous avez envie ! Après bien sûr, à vous de négocier votre bande passante avec votre FAI (ainsi qu'avec ses Conditions Générales de Vente)
+ ++ +
A plus petite échelle (la mienne par exemple) vous pouvez simplement sauvegarder et redémarrer votre serveur web que vous avez pris 3 jours de temps libre à configurer aux petits oignons. (Enfin, surtout le serveur courriel en fait...), et ce même si votre serveur maison claque brusquement.
+ ++ +## Moi, je suis convaincu (sinon j'en ferai pas la pub) + +
Auneffet, ce en quoi je crois, j'en parle. Simple et efficace :-)
+ +Maintenant, ce long article servant d'introduction à d'autres prévus sur la configuration de proxmox, j'espère que vous l'aurez apprécié.
+ +Désolé, c'est long. Mais c'est bon aussi ;-)
+ +diff --git a/content/comments/configurer-reverse-proxy-apache/0.md b/content/comments/configurer-reverse-proxy-apache/0.md new file mode 100644 index 0000000..d06ff93 --- /dev/null +++ b/content/comments/configurer-reverse-proxy-apache/0.md @@ -0,0 +1,41 @@ +email: sebastienfct@gmail.com +date: 2014-11-06T20:00+01:00 +author: SebFCT +website: + +Bonjour, + +J'ai suivi ton tutoriel (très clair au passage) afin de tenter de gérer les problème que je rencontre en ce moment, mais sans résultat.. + +Pour faire court, j'utilise un serveur proxmox qui contient plus conteneurs (dont ceux qui m'intéressent: CT101 et CT102). + +CT101 et CT102 sont tous deux des conteneur debian avec l'installation de base d'un site web (apache, php, ...).. Ils sont affichés respectivement lorsque je tape X.Y.Z.W:80 et X.Y.Z.W:8765 (X.Y.Z.W étant l'adresse de mon serveur). + +J'ai loué deux nom de domaine, j'aimerai les liés à chacun des conteneurs. J'ai donc rajoutés + + +