import d'article depuis pluxml

7 years ago · 9d9438fa2d
--- a/content/Réseaux/proxmox-lan-au-sein-d-une-dedibox-online.md
+++ b/content/Réseaux/proxmox-lan-au-sein-d-une-dedibox-online.md
@ -0,0 +1,137 @@
 Title: Lan au sein d'une dedibox Online
 subtitle: ; Proxmox
 Date: 2012-09-12 20:30
 Modified: 2012-09-12 20:30
 Tags: proxmox, debian, iptables, linux, dedibox online
 keywords: proxmox, debian, iptables, linux, dedibox online
 Slug: proxmox-lan-au-sein-d-une-dedibox-online
 Authors: Victor
 Status: published

 [TOC]

 ## Problématique : faut qu'ça cause
 <p>
 	Ce tutoriel a été rédigé sur le modèle d'un serveur dédié "dedibox" loué par <a href="http://www.online.net">Online.net</a>.</p>
 <p>
 	<em>Nota : cet article est la transcription un peu plus détaillée et technique d'un post de moi-même sur le forum d'Online. Il n'y a donc pas de probème de droits :)</em></p>
 <p>
 	Cependant, il peut s'adapter à n'importe quel serveur ayant une distribution proxmox d'installée, au prix du changement de nom de quelques interfaces.</p>
 <p>
 	Globalement le problème se résume ainsi :</p>
 <ul>
 	<li>
 		Votre proxmox est installé sur un serveur dédié</li>
 	<li>
 		Vous avez plusieurs machines virtuelles, qui ont besoin de causer entre elles, ou mieux avec l'extérieur (mises à jour, tout ça...)</li>
 	<li>
 		Votre herbergeur<a href="http://blog.héry.com/article12/on-rale-marre-du-filtrage-securite-des-hebergeurs"> <strike>est un gros extrémiste</strike> sécurise son réseau</a> et il coupe tout accès à votre serveur si vous avez le malheur de sortir sur le réseau avec une adresse IP/MAC privée</li>
 </ul>
 <p>
 	&nbsp;</p>
 <p>
 	Il va donc falloir mettre en place un réseau virtuel interne à votre proxmox, et le cas échéant un système de NAT efficace pour permettre à vos VM avec adresses IP privées de sortir sur Internet.</p>
 <p>
 	<strong>Que ce soit clair, ces règles de pare-feu ne sécurisent en rien votre serveur, elles se contentent uniquement de permettre à vos machines virtuelles de causer entre elles.</strong></p>
 ## Posons les termes : de quoi on parle
 <p>
 	Pour rendre plus simples les explications suivantes, je vais poser dès maintenant la configuration que l'on va utiliser.</p>
 <p>
 	Le tutoriel se base sur proxmox V2, configuré juste après installation.</p>
 <p>
 	Dans ce cadre :</p>
 <ol>
 	<li>
 		On utilise une distribution Proxmox, donc basée sur Debian</li>
 	<li>
 		vmbr0 est l'interface bridge créée par proxmox, normalement liée à eth0</li>
 	<li>
 		vmbr1 est une interface bridge supplémentaire créé par nos soins, sans nécessité d'être liée à une interface physique (éventuellement créée depuis l'interface web proxmox)</li>
 	<li>
 		Le pare-feu que nous utiliserons sera iptables</li>
 	<li>
 		Nous configurerons des containeurs OpenVZ (mais la configuration fonctionne avec des KVM en réseau bridgé)</li>
 	<li>
 		Une machine VMID OpenVZ existe déjà, et elle dispose d'une interface publique avec une adresse MAC générée via l'interface web Online. (hors cadre de ce tuto)</li>
 	<li>
 		Vos VM utilisent la plage d'adresse IP privées 192.168.0.0/16</li>
 	<li>
 		Vous possédez déjà quelques connaissances en ligne de commande/iptables</li>
 </ol>
 ## Les mains dans le cambouis
 <p>
 	Première chose à faire, se connecter en SSH sur votre hyperviseur proxmox.</p>
 <p>
 	Utilisez Putty si vous êtes sous Windows, ou le shell via une applet java dans l'interface Proxmox en alternative.</p>
 <p>
 	Dans tous les cas, continuez une fois que vous avez un shell d'ouvert sur votre hyperviseur&nbsp; :-)</p>
 ### Evitons les blocages intempestifs
 <p>
 	La première manip va être de mettre en place un NAT sur l'interface physique qui sert à l'hyperviseur pour joindre Internet. Ceci permettra tout de suite d'éviter la moindre fuite d'un paquet venant d'une VM vers l'extérieur.</p>
 <p>
 	En effet, cette fuite pourrait entrainer la coupure de l'accès à votre serveur pour une durée indéterminée, évitons donc tout de suite ce cas là.</p>
 <p>
 	Un effet de bord intéressant est que vos futures VM pourront accéder à Internet à l'aide de ce NAT à l'aide d'un peu de routage ! Pratique pour les mises à jour.</p>
 <p>
 	Pour mettre en place ce NAT, utilisez les lignes suivantes (à utiliser en root, ou alternativement avec sudo) :</p>
 <p>

 <pre class="brush:bash;">
 $ iptables -t nat -A POSTROUTING -o vmbr0 -s 192.168.0.0/16 ! -d 192.168.0.0/16 -j MASQUERADE
 $ echo 1 &gt; /proc/sys/net/ipv4/ip_forward
 </pre>

 <p>
 	Cela va permettre d'activer l'ip forwarding sur votre interface, et va faire en sorte que toutes vos VM en 192.168.0.0/16 seront nattées lorsqu'elles essaieront de joindre une machine qui n'est pas en 192.168.0.0/16.</p>
 <p>
 	<strong>Attention, changez les adresses IP selon votre configuration.</strong></p>
 <p>
 	Cette configuration est temporaire, elle n'aura plus d'effet au prochain redémarrage. Nous verrons dans la <a href="#Modifications permanentes">dernière partie</a> comment les rendre permanentes, mais vérifiez que tout fonctionne avant de faire ça.</p>
 <p>
 	(Si vous vous plantez et que vous bloquez l'accès à votre système, au moins un redémarrage règle le problème. Une fois les règles permanentes, vous êtes obligés de tout formater...)</p>
 ### Configuration OpenVZ
 <p>
 	Nous allons rajouter à la VM une interface réseau qui va bien. C'est également possible de le faire via l'interface web, mais comme on est en SSH on va pas s'embêter à ouvrir un navigateur !</p>
 <p>
 <pre class="brush:bash;">
 vzctl set VMID --netif_add eth1,,,,vmbr1 --save
 </pre>
 <p>
 	Ceci va permettre de rajouter à la machine VMID une interface eth1, branchée sur vmbr1. L'adresse MAC sera générée automatiquement. Le --save rend la modification permanente même après redémarrage de la VM.</p>
 <p>
 	Pour faire plus simple, vous pouvez mettre à vmbr1 une adresse IP dans la même plage que les VM (ici 192.168.0.0/16), histoire que l'hyperviseur puisse leur causer aussi. Ce n'est pas obligatoire ceci dit.</p>
 <p>
 	Pour faire ça, il suffit de modifier le fichier /etc/network/interfaces -&gt; Voir dans la section "<a href="#Modifications permanentes">Modification permamentes</a>"</p>
 <p>
 	Ensuite, il vous suffit de créer autant de VM que vous le souhaitez en réseau local. La seule contrainte est de leur mettre une interface réseau branchée sur vmbr1 à la création, puis une adresse IP dans la plage qui va bien.</p>
 <p>
 	De cette façon vous êtes parés.</p>
 ## <a name="Modifications permanentes">Modifications permanentes</a>
 <p>
 	Bon aller, pour que tout cela soit permanent même après redémarrage, voici les choses à rajouter.</p>
 <p>
 	Les modifications sont à faire sur l'hyperviseur.</p>
 <p>
 	Dans /etc/network/interfaces, rajoutez sous la section vmbr0 les lignes suivantes :</p>
 <p>
 <pre class="brush:bash;">
 echo 1 &gt; /proc/sys/net/ipv4/ip_forward
 post-up iptables -t nat -A POSTROUTING -o vmbr0 -s 192.168.0.0/16 ! -d 192.168.0.0/16 -j MASQUERADE
 post-down iptables -t nat -D POSTROUTING -o vmbr0 -s 192.168.0.0/16 ! -d 192.168.0.0/16 -j MASQUERADE
 </pre>
 <p>
 	De cette façon, le NAT sera configuré au démarrage sur vmbr0.</p>
 <p>
 	Pour avoir une adresse IP privée sur vmbr1, soit vous passez par l'interface web, soit vous retournez dans /etc/network/interfaces et vous rajouter dans vmbr1 les lignes qui vont bien (en vous basant sur vmbr0 par exemple)</p>
 <p>
 <pre class="brush:bash;">
 addresse 192.168.0.1
 netmask 255.255.0.0
 broadcast 192.168.0.255
 </pre>
 <p>
 	&nbsp;</p>
 <p>
 	Voila, j'espère que ce petit tuto vous aura été utile. Si vous avez des questions particulières, n'hésitez pas&nbsp; :-)</p>
 <p>
 	&nbsp;</p>
--- a/content/Système/connexion-ssh-par-cle.md
+++ b/content/Système/connexion-ssh-par-cle.md
@ -0,0 +1,151 @@
 Title: Connexion SSH par clé
 subtitle: (Debian/Ubuntu)
 Date: 2012-08-15 10:20
 Modified: 2012-08-15 19:30
 Tags: linux,ssh automatique,debian,ubuntu, sécurité
 keywords: linux,ssh automatique,debian,ubuntu, sécurité
 Slug: connexion-ssh-par-cle
 Authors: Victor
 Status: published

 [TOC]


 ## Pourquoi se connecter par clé ?
 <p>
 	Si vous êtes comme moi et que vous faites des scripts sous linux, notamment de backup, vous avez sans doute le problème d'exécuter des commandes à distance automatiquement.</p>
 <p>
 	Pour cela, le ssh est l'idéal; sécurisé, crypté, facilement configurable et utilisable.</p>
 <p></p>
 <p>
 	Cependant, l'un des gros problèmes d'un script automatique, c'est qu'un mot de passe, il a un peu de mal à le taper. Alors, on peut bidouiller me direz-vous :</p>
 <pre class="brush:bash;">
 echo "motdepasse" ssh root@serveurIP</pre>
 <p>
 	Pourquoi pas. Mais bon, ça oblige à mettre le mot de passe en clair, ça ne marche pas toujours selon la configuration de votre serveur ssh, et la connexion en root, c'est mal.</p>
 <p></p>
 <p>
 	C'est là qu'intervient un système sympa de ssh :&nbsp;<strong>la connexion par clé...</strong></p>
 ## Le principe : rapidement
 <p>
 	Pour ceux qui ne sont pas trop au fait de quoi que c'est que ça, je vais rapidement rappeller le principe de se connecter à l'aide d'une clé.</p>
 <p>
 	En ssh, la connexion se fait en trois temps :</p>
 <ul>
 	<li>
 		On fait une demande de connexion, le serveur renvoie une clé unique lié à sa configuration, qui va permettre de l'identifier et de chiffrer le flux (Cette demande n'est faite qu'à la première connexion)</li>
 	<li>
 		On accepte (ou non) cette clé. Elle permet notamment de voir si le serveur a été changé depuis la dernière connexion (si oui, attention ! potentielle attaque d'homme dans le milieu :-) )</li>
 	<li>
 		Ensuite, on rentre son mot de passe et la connexion s'établit</li>
 </ul>
 <p>
 	En fait, il y a l'identification du serveur (clé du serveur), puis notre identification (via le mot de passe)</p>
 <p>
 	Avec une connexion par clé, c'est quasi la même chose, sauf qu'on va nous aussi utiliser une clé pour s'identifier ! De cette façon, une fois la clé installée sur le serveur, elle ne sera plus demandée et il n'y aura plus besoin de mot de passe. (trop la classe)</p>
 <p>
 	<em>Notez qu'on peut assortir la connexion &nbsp;par clé d'une phrase de sécurité, à rentrer lors de la connexion et qui sécurise encore le processus. Cependant, ce n'est pas intéressant pour une connexion auto donc on ne s'en servira pas ici</em></p>
 <p></p>
 ## Génération de la clé : les choses sérieuses commencent
 <p>
 	Sur votre machine cliente, il va d'abord falloir générer la fameuse clé. Ou plutôt, le couple de clé, la clé publique et la clé privée.&nbsp;<a href="http://fr.wikipedia.org/wiki/Cryptographie_asymétrique">(Voir la cryptographie asymétrique)</a></p>
 <p>
 	Si ce n'est pas déjà fait, installez donc le client openssh :</p>
 <pre class="brush:bash;">
 $ sudo aptitude update &amp;&amp; sudo aptitude install openssh-client</pre>
 <p>
 	(Bien sûr, openssh serveur est installé sur votre machine distante)</p>
 <p>
 	Ensuite, générez la clé pour votre client :</p>
 <pre class="brush:php;">
 $ ssh-keygen -t rsa -b 4096
 Generating public/private rsa key pair.</pre>
 <p>
 	Il vous faut ensuite répondre à plusieurs questions. La valeur par défaut est correcte, il suffit donc d'appuyer sur Entrée à chaque fois. Pour la passphrase, laissez vide pour qu'elle ne soit pas utilisée (c'est ce que l'on veut pour la connexion automatique)</p>
 <p>
 	Une fois la clé générée, un petit resumé est affiché :</p>
 <pre class="brush:bash;">
 Your identification has been saved in /home/utilisateur/.ssh/id_rsa.
 Your public key has been saved in /home/utilisateur/.ssh/id_rsa.pub.
 The key fingerprint is:
 XX:8a:XX:91:XX:ae:XX:23:XX:2e:XX:ed:XX:4e:XX:b8 utilisateur@machinecliente</pre>
 <p>
 	Les deux clés (publique et privée) sont donc stockées directement dans votre dossier home, dans un dossier caché nommé .ssh/</p>
 ## Envoi de la clé au serveur : tuyau crypté
 <p>
 	Le moment délicat est arrivé. Il vous faut transmettre votre clé au serveur, de préférence via un moyen crypté. (Bah oui, envoyer la clé en clair via ftp par exemple vous expose à vous la faire piquer, et donc potentiellement pirater...)</p>
 <p>
 	Pour ça, le meilleur moyen reste encore ssh ! Il va vous falloir une dernière fois votre mot de passe pour vous connecter au serveur. Grâce aux outils ssh, il suffit de faire :</p>
 <pre class="brush:bash;">
 $ ssh-copy-id -i /home/login/.ssh/id_rsa.pub login@machineserveur
 Password :</pre>
 <p>
 	Entrez votre mot de passe, et la clé sera directement copiée dans le dossier .ssh/authorized_keys de votre serveur. Ce dossier est dans le home de l'utilisateur du serveur (pas root hein ??)</p>
 <pre class="brush:bash;">
 Now try logging into the machine, with "ssh 'login@machineserveur'", and check in:
  .ssh/authorized_keys
 to make sure we haven't added extra keys that you weren't expecting.</pre>
 <p>
 	Une fois celà fait, vous pouvez maintenant vous connecter à votre serveur sans avoir besoin d'aucun mot de passe.</p>
 <p>
 	Pour testez, faites donc un petit :</p>
 <pre class="brush:bash;">
 ssh login@machineserveur</pre>
 <p>
 	La connexion doit s'effectuer sans mot de passe ! Vous pouvez maintenant utiliser à loisir ssh, scp, rsync, ... dans vos scripts !</p>
 ## Problèmes éventuels : il peut arriver que...
 <p>
 	Jusqu'ici, je n'ai quasiment jamais rencontré de problèmes avec l'authentification par clé.</p>
 <p>
 	Cependant, si ça devait vous arriver, l'une des premières choses à vérifier est que les droits Unix sur le serveur sont corrects.</p>
 ### ... Le serveur continue à me demander mon mot de passe !
 <p>
 	C'est balot. Logguez vous sur votre serveur avec le mot de passe, et vérifiez que :</p>
 <ol>
 	<li>
 		Les droits du dossier personnel de votre utilisateur sont corrects :&nbsp;
 		<pre class="brush:bash;">
 $ ls -l /home
 drwxr-xr-x 5 login login 4096  3 jui.   2012 login</pre>
 			Les droits doivent être identiques à l'exemple, c'est à dire en 755. Pour eventuellement corriger ça, faites&nbsp;
 		<pre class="brush:bash;">
 $ chmod 755 /home/login</pre>
 		<p></p>
 	</li>
 	<li>
 		Les droits du dossier .ssh sont corrects :
 		<pre class="brush:bash;">
 $ ls -l /home/login
 drwx------ 2 login login    4096  9 sept.  2011 .ssh</pre>
 			De même que précedemment, si les droits ne sont pas corrects, faites&nbsp;
 		<pre class="brush:bash;">
 $ chmod 700 /home/login/.ssh</pre>
 		<p></p>
 	</li>
 	<li>
 		Les droits du fichier authorized_keys sont corrects :
 		<pre class="brush:bash;">
 $ ls -l /home/login/.ssh/authorized_keys
 -rw------- 2 login login    4096  9 sept.  2011 authorized_keys</pre>
 			Si ce n'est pas correct, un petit :
 		<pre class="brush:bash;">
 $ chmod 600 /home/login/.ssh/authorized_keys</pre>
 			devrait faire l'affaire
 	</li>
 </ol>
 ### ... Je dois utiliser un autre port que le port 22 !
 <p>
 	Il peut arriver que vous deviez utiliser la commande ssh-copy-id et que votre serveur utilise un port différent du port 22.</p>
 <p>
 	Dans ce cas, vous remarquerez que ssh-copy-id ne prend pas l'option "-p" habituellement utilisé avec ssh.</p>
 <p>
 	La solution est assez simple, il faut lui passer en tant qu'option ssh, de la manière suivante :&nbsp;</p>
 <p></p>
 <pre class="brush:bash;">
 $ ssh-copy-id -i /home/login/.ssh/id_dsa.pub '-pPORT login@machineserveur'</pre>
 <p>
 	En fait vous pouvez même passer toutes les options propres à ssh en mettant ça entre ''. (Par exemple l'algorithme de chiffrement, ...)</p>
 <p></p>
 ### Et si c'est pas ça ?
 <p>
 	C'est jusqu'ici les seuls problèmes que j'ai eu en utilisant correctement tous les outils ssh. Posez la question dans les commentaires :)</p>
--- a/content/comments/connexion-ssh-par-cle/0.md
+++ b/content/comments/connexion-ssh-par-cle/0.md
@ -0,0 +1,16 @@
 email: bloguebinome@thibaud.info
 date: 2012-08-18T19:56+01:00
 author: Thibaud
 website:

 Article intéressant. Je salue l'iniative cher binôme. :-)

 Quelques petites remarques/questions :

 Dans un souci de sécurité accrue, tu peux ajouter la ligne  "PasswordAuthentication no" dans /etc/ssh/sshd_config pour n'autoriser que l'authentification par clefs asymétriques (tu peux en profiter aussi pour mettre "PermitRootLogin no").

 Sinon, si tu te fais piquer ta clef publique lors du transfert vers ton serveur, ça n'est pas très grave puisqu'elle est… publique. ^^ Tu peux même utiliser la même sur plusieurs serveurs différents. Ce qui est important, c'est qu'elle ne soit pas été altérée lors du transfert.

 Petite question, entre ssh-copy-id et un simple scp, il y a quoi comme différence? Le "-i" c'est pour rajouter à la suite du fichier?

 Sinon pourquoi chmoder en 600 et pas en 644 le contenu de ton dossier .ssh (ce qui est le cas par défaut)? Je suis d'accord pour le faire sur id_rsa (ou id_dsa) qui est la clef privée mais sur le reste, je ne vois pas bien l'intérêt.
--- a/content/comments/connexion-ssh-par-cle/1.md
+++ b/content/comments/connexion-ssh-par-cle/1.md
@ -0,0 +1,15 @@
 email: courriel@victor-hery.com
 date: 2012-08-18T20:13+01:00
 author: Victor
 replyto: 0md
 website: http://blog.xn--hry-bma.com/

 Iniative intéréssée je l'avoue, j'en avais marre de toujours chercher les commandes quand j'ai cette manip à faire, alors j'ai rédigé un tuto propre selon mes critères :)

 Effectivement on peut rajouter les options dont tu parles. Cependant, ce n'est pas obligatoire pour l'accès par clé, donc je ne l'ai pas mis (l'article est déjà bien assez conséquent)
 Je ferai peut être un article sur la sécurisation de ssh un de ces jours !

 Du côté de ssh-copy-id, l'avantage pou moi est que cela rajoute directement à la fin du fichier authorized_keys du serveur la clé du client. En scp, il faut envoyer la clé, puis faire un cat à la main pour le recopier la clé à la fin du fichier. Moyennement pratique je trouve.
 Le -i (man ssh-copy-id) permet de spécifier le fichier clé à envoyer (qui est déjà par défaut ~./ssh/id_dsa.pub). Il n'est donc pas forcément nécessaire de le mettre, mais ça ne mange pas de pain :)

 Par contre avec ma commande, je n'ai chmodé que le fichier authorized_keys, pas le contenu de tout le dossier ssh/. Je l'ai fait parce que ce sont les droits par défaut du fichier sur mes serveurs, et que j'ai eu un souci de connexion un jour à cause de ça ("Uncorrect rights set on authorized_keys" dans les logs de mémoire)
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/0.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/0.md
@ -0,0 +1,10 @@
 email: julien@bio-teckna.fr
 date: 2013-04-14T12:36+01:00
 author: Bio Teckna
 website: bio-teckna.fr

 Bonjour,

 Ton article est parfait ! J'ai eu exactement le même soucis que toi. Je me suis dis que je ne devais pas être le seul et qu'il y avait surement un gentil blogueur qui avait mis comment éviter le super blocage.

 Merci beaucoup, je vais pouvoir virtualiser ma vie et regrouper tout sur une même machine.
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/1.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/1.md
@ -0,0 +1,11 @@
 email: courriel@victor-hery.com
 date: 2013-04-14T12:38+01:00
 author: Victor
 website: http://blog.xn--hry-bma.com/
 replyto: 0md

 Hello,

 Pas de soucis, heureux d'avoir pu t'aider ! Ca m'étonnait aussi d'être le seul à être tombé sur ce problème ;)

 A plush'
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/10.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/10.md
@ -0,0 +1,10 @@
 email: ibasaw@gmail.com
 date: 2014-01-16T09:33+01:00
 author: ibasaw
 website:

 Bonjour,

 Je suis bloqué pour faire communiquer mes toutes mes vm/ct entre elles, voir le descriptif ici: http://forum.ovh.com/showthread.php?96960-proxmox-communication-entre-vm-ct

 Merci pour votre aide
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/11.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/11.md
@ -0,0 +1,10 @@
 email: courriel@victor-hery.com
 date: 2014-01-27T23:19+01:00
 author: Victor
 website: http://blog.xn--hry-bma.com/
 replyto: 10md

 Hello ibasaw
 Mieux vaut tard que jamais, j'ai regardé ton poste et répondu, en espérant que ça t'aidera :)

 Bon courage !
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/12.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/12.md
@ -0,0 +1,12 @@
 email: thetataz@xataz.net
 date: 2014-10-30T09:33+01:00
 author: xataz
 website:

 Bonjour,

 Je suis tomber sur ton sujet après de très longue recherche, mais il ne correspond pas encore a ce que je cherche, peut etre pourra tu m'aider.  
 J'ai un serveur dédier, avec deux IP publique, mon but étant t'utilisé la 1ere pour acceder a proxmox uniquement, et la 2eme a mon sous réseau, donc je veux un container openvz qui fait office de passerelle.   
 COnfigurer l'IP Failover, aucun soucis. Mais c'est derière, impossible de rattaché une interface virtuel a mon container.  
 Aurait tu une idée ?  
 Merci par avance
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/13.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/13.md
@ -0,0 +1,20 @@
 email: courriel@victor-hery.com
 date: 2014-11-07T11:41+01:00
 author: Victor
 website: http://blog.xn--hry-bma.com/
 replyto: 12md

 Hello xataz,

 A première vue, je dirais que tu dois utiliser l'interface réseau venet, et pas veth pour ton container ?

 Avec veth, tu peux gérer les paramètres réseaux depuis l'intérieur du CT, ce que je trouve plus pratique personnellement pour les serveurs passerelles.

 Sinon, depuis l'interface proxmox elle-même, tu peux rajouter une interface, en indiquant sur quel bridge la "brancher". Dans ton cas, ça devrait sans doute être vmbr0, le bridge portant l'IP publique de l'hyperviseur.

 Une fois cette interface ajoutée, aucun souci pour configurer l'IP publique dessus.

 Ce que je te conseilel ensuite, c'est de créer une deuxième interface à ton CT, de a même façon via l'interface proxmox, mais branchée elle sur un 2eme bridge, type vmbr1 (quitte à ce qu'il ne soit lié à aucune interface physique). Ca permettra de brancher tes autres VM sur ce bridge, et donc d'avoir un genre de swith virtuel dédié à ton réseau privé.

 J'espère que ça pourra t'aider :)
 Sinon, n'hésite pas à détailler ton souci.
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/14.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/14.md
@ -0,0 +1,13 @@
 email: endiaye@live.fr
 date: 2015-01-06T12:08+01:00
 author: Boubacar
 website:

 Bonjour
 Je vies vous demander de l'aide mon soucis:
 possedant un serveur Kimsufi KS-3 avec Ipv4E iPV6 sans Ip failover,
 1er hypothese
 j'aimerai le virualiser en y installant Proxmox v3.3 des vm  mais en plus d'une vm pfsense en frontal pour la sécurité et permetre l'accès  internet aux Vms et appliquer des regles d'iptables sur le serveur vue qu'il y une seule adresse ip publique
 2eme hypothese
 installer vmware esxi  avec pfsense  en frontal et libérer l'adresse ipv4 pour pfsense et attribuer l'ipv6 au vmware esxi
 merci de votre aide
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/2.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/2.md
@ -0,0 +1,22 @@
 email: julien@bio-teckna.fr
 date: 2013-04-14T17:19+01:00
 author: Bio Teckna
 website: bio-teckna.fr
 replyto: 0md

 C'est encore moi,

 Je galère depuis ce matin pour configurer le NAT comme il faut.  
 Hôte :  
 eth0 et vmbr0 en mode bridge sur eth0 afin d'avoir l'IP de mon hebergeur (ça c'est fait tout seul)  
 J'ai rajouté une autre interface vmbr1 avec l'ip 10.0.1.254 qui représentera la passerelle par defaut des VM.
 Ensuite j'ai une VM Ubuntu server 12.04 avec un eth0 en 10.0.1.1.  
 J'ai mis en place du NAT comme dans votre explication avec les bonnes IP (10.0.1.0 pour le réseau privé). J'ai activé le routage mais c'est cette ligne que je ne comprends pas :    

 vzctl set VMID --netif_add eth1,,,,vmbr1 --save  

 Je fais cette ligne sur la VM ? sur l'Hôte proxmox ? à quoi sert-elle précisement ? D'après ce que j'ai compris c'est pour relier virtuellement une interface eth1 d'une VM avec l'id VMID à l'interface vmbr1 de l'hôte proxmox. Cependant, sur mon ubuntu serveur "vzctl" n'est pas installé du coup je ne vois pas comment faire vu que je n'ai pas encore internet.

 Est-ce que vous pourriez m'aider s'il vous plait :)

 Merci d'avance
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/3.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/3.md
@ -0,0 +1,24 @@
 email: courriel@victor-hery.com
 date: 2013-04-14T19:35+01:00
 author: Victor
 website: http://blog.xn--hry-bma.com/
 replyto: 0md

 Hello,

 Alors voyons :)
 Je pars du principe que vous êtes partis sur une OpenVZ pour l'Ubuntu Serveur.
 Si c'est bien le cas, la commande vzctl est disponible sur l'hyperviseur Proxmox. C'est une commande pour gérer openVZ en ligne de commande.
 Avec ces options, elle permet effectivement de rajouter une interface à une VM, nommée eth1 et liée à vmbr1.

 Du coup, dans votre cas, pour coller au tuto :
 - Vous ne dites pas sur quel vmbr est bridgé l'interface eth0 de votre VM, donc le mieux est de le bridger sur vmbr1, avec son IP en 10.0.1.1.
 - Du coup, pas besoin de recréer une autre interface pour la VM, eth0 devrait suffire.
 (En fait, ajouter une deuxième interface permet à des VM de parler sur leur réseau interne, dans le cas où l'on se sert d'une VM comme passerelle. Ici, on va se servir de l'hyperviseur, donc pas forcément utile de créer une deuxième interface)
 - Une fois le bridge fait sur vmbr1, il faut configurer dans la VM le 10.0.1.254 comme passerelle, ainsi elle se servira de vmbr1 comme liaison vers Internet.
 - Avec l'IP forward activé et le NAT, normalement tous ce qui passe par vmbr1 et essaye de joindre Internet va être redirigé vers vmbr0 et nattée avant de sortir sur Internet. En théorie, ça devrait marcher si je n'ai rien loupé :)

 Fais moi signe si ce n'est pas au point.
 Bon courage !

 A plush'
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/4.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/4.md
@ -0,0 +1,51 @@
 email: badmaniak@maniakteam.fr
 date: 2013-05-17T10:12+01:00
 author: badmaniak
 website:

 Hello Victor,
 J'ai essayé de suivre ton tuto à la lettre, mais je n'ai pas forcément le résultat escompté ( en même temps je débute sur proxmox j'utilisais avant plus tôt ESXi):

 Contexte : serveur dédié chez ONline, j'utilise que des kvms (pour le moment), elle sont configurer en NAT sur l'hôte.

 Je souhaite avoir un  réseau privé pour l'utilisation de mes VM 192.168.0.0/24 et quelle puissent discuter entre elles, j'ai donc mis en place une configuration sur ma machine Hôte dans /etc/network/interfaces :  



    # The loopback network interface
    auto lo
    iface lo inet loopback

    # The primary network interface
    auto vmbr0
    iface vmbr0 inet static
            address 88.x.x.x
            netmask 255.255.255.0
            network 88.x.x.0
            broadcast 88.x.x.255
            gateway 88.x.x.1
            bridge_ports eth0
            bridge_stp off
            bridge_fd 0
    echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up iptables -t nat -A POSTROUTING -o vmbr0 -s 192.168.0.0/24 ! -d 192.168.0.0/24 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -o vmbr0 -s 192.168.0.0/24 ! -d 192.168.0.0/24 -j MASQUERADE

    auto vmbr1
    iface vmbr1 inet static
     address  192.168.0.1
     netmask  255.255.255.0
     bridge_ports none
     bridge_stp off
     bridge_fd 0




 Merci de me dire si c'est déjà correcte!!


 Sur  les VM kvm, j'ai configuré eth0 pour qu'il soit dans le réseau 192.168.0.0/24. Par défaut si j'utilise le DHCP les VM se retrouvent avec une adresse 10.0.2.15 ( c'est d'ailleurs la même pour toutes les vm). Avec l'adresse fournit par le DHCP les VM communiquent avec l’extérieur sans problème ( à part l'icmp) mais dès que je configure l'adresse en statique  sur le réseau 192.168.0.0/24, la plus rien.  
 Je tourne un peu en rond depuis quelque temps  j'ai certainement raté une étape, mais je ne vois pas laquelle....

 Merci d'avance pour ta réponse.
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/5.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/5.md
@ -0,0 +1,7 @@
 email: badmaniak@maniakteam.fr
 date: 2013-05-17T10:12+01:00
 author: badmaniak
 website:
 replyto: 4md

 Salut, avec Openvz ça fonctionne, par contre toujours pas avec KVM .
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/6.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/6.md
@ -0,0 +1,23 @@
 email: courriel@victor-hery.com
 date: 2013-06-17T11:56+01:00
 author: Victor
 website: http://blog.xn--hry-bma.com/
 replyto: 4md

 Hello,

 Navré pour le temps de réponse, j'ai été un peu absent ces derniers temps. Mea culpa !

 Ta configuration hyperviseur me semble correcte déjà :)

 Tu dis que le système fonctionne avec OpenVZ, c'est à dire avec des OpenVZ montée en bridge sur vmbr1 ?  
 Pour tes KVM, as tu utilisé un réseau bridgé directement sur vmbr1 ? Le premire truc qui me vient à l'esprit, c'est que la route par défaut ou le DNS n'est pas configuré sur les KVM, ce qui fait que en static, ça ne fonctionne pas, alors qu'en DHCP si. Est ce que tu as bien mis la directive gateway dans le /etc/network/interfaces de tes KVM ? Et configuré le DNS dans /etc/resolv.conf ? (ou la directive dns-nameserver dans /etc/network/interfaces)  

 En OpenVZ, ça fonctionne peut être si tu es resté en venet et pas en veth.

 Tu as peut être sinon un pare-feu qui tourne sur l'hyperviseur et qui laisserait passer le 10.0 et pas le 192.168 ?

 J'espère pouvoir t'aider même un mois après :)  
 Tiens moi au courant si ces quelques suggestions donnent un résultat.

 A plush'
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/7.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/7.md
@ -0,0 +1,13 @@
 email: yogui.spam@gmail.com
 date: 2013-08-26T16:22+01:00
 author: Yogz
 website:

 Hello,

 Merci pour le tuto ! J'ai essayé d'appliquer la config sur une dedibox sous centos/KVM.  
 J'ai bien un reseau local sur le range d'ip 192.168...  
 J'ai ajouté un bridge sur mon hypersiveur sur lequel sont connectées mes interfaces privées de mes VMs.  
 Depuis une VM possédant uniquement une interface privée je peux pinger l'ensemble des Ips de mon serveurs (mes deux ip publiques notamment) mais je n'ai aucun accès à internet... Quelle serait la configuration à appliquée pour pouvoir avoir accès au net depuis ma VM ?  

 Merci de ton aide
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/8.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/8.md
@ -0,0 +1,16 @@
 email: courriel@victor-hery.com
 date: 2013-08-26T17:00+01:00
 author: Victor
 website: http://blog.xn--hry-bma.com/
 replyto: 7md

 Hello,

 Je verrai 3 choses à tester pour commencer :  
  -  Est ce que tu as bien un NAT de configuré (la partie de configuration avec Masquerade) sur ton interface publique ?  
  -  Est ce que tu as bien configuré l'IP forward sur tes interfaces (echo 1 > /proc/sys/net/ipv4/ip_forward), ce qui pourrait bloquer le transfert des paquets entre les interfaces, mais ça m'étonnerait si tu arrives à pinguer tes IP publiques  
  -  Enfin, peut être tout simplement un problème de DNS sur tes machines privées ? Que donne un "ping 8.8.8.8" (l'adresse du DNS de google) ? S'il marche, alors c'est que ta VM n'a pas de DNS correct de configuré.

 Jusqu'ici cette configuration a plutôt bien fonctionné, alors n'hésite pas à revenir vers moi si tu as besoin d'aide ou si tu trouves la solution, je pourrai mettre à jour le tuto :)

 A plush'
--- a/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/9.md
+++ b/content/comments/proxmox-lan-au-sein-d-une-dedibox-online/9.md
@ -0,0 +1,11 @@
 email: badmaniak@maniakteam.fr
 date: 2013-09-24T23:10+01:00
 author: badmaniak
 website:
 replyto: 4md

 Salut Victor,

 Désolé pour ma réponse tardive, en fait le configuration à grandement évolué, tout fonctionne, j'ai crée un script iptables pour faire communiquer mes vm entre elles OPENVZ et KVM mais surtout pour sécuriser mon serveur, le tout "Naté " sur l'interface publique vbmr0. Bref merci pour l’article et tes conseils qui m'ont bien orientés vers ma solution.

@+