lid's stuff

Online, RPN-G et machines virtuelles

Contrairement au vRack de son concurrent OVH, qui semble fonctionner sur la couche liaison (L2 modèle OSI), la solution de réseau privé entre serveurs dédiés d'Online fonctionne lui par (grosses) ACLs directement sur la couche L3 des switches dédiés au RPN (RPN-FE, RPN-G pour les "riches"). Si ça ne pose pas trop de problème en utilisation classique, il y a cependant un petit (voire très gros) défaut avec cette solution: seules les machines physiques y ont accès, et pas les machines virtuelles, qui ne se verront pas attribuer d'adresse IP par le DHCP du RPN(-G), probablement à cause d'une sombre histoire d'adresses MAC, toussa. Un peu con quand on a une infra virtualisée sur plusieurs machines physiques et qu'on désire que ces VMs, pour une raison X ou Y, communiquent via le RPN-G directement (ie, sans nat/pat crado).

Cependant, il est possible de pouvoir contourner cette limitation grâce à plusieurs outils, directement sur nos hyperviseurs - je prendrai pour exemple une Debian classique (Jessie) servant d'hyperviseur Xen, et les VMs qui vont bien elles aussi sous Jessie, mais c'est tout à fait adaptable à n'importe quelle distro/hyperviseur:

  • nos copains iproute2, ifconfig (j'aime bien les vieux trucs deprecated) et /etc/network/interfaces
  • notre super pote OpenVPN

Configuration sur les hyperviseurs:

Premièrement, on va partir du principe qu'on utilisera pour notre réseau entre nos VMs le sous réseau 172.16.0.0/24 (10.90.0.0/15 étant utilisé par le RPN, et on peut imaginer à terme 10.0.0.0/8)

Tout d'abord, on va s'ajouter un bridge, nommons le xenbr1 (mais on peut l'appeler chaton0 ou tout autre nom rigolo, hein, c'est pas important), qui pour le moment ne sera bridgé à… rien (et pour une bonne raison: on ne veut pas que nos VMs papotent leur adresse MAC sur le rpn d'Online, c'est pour ça qu'on ne bridge pas avec l'interface connectée au RPN - contrairement à ce qu'on ferait avec le vRack d'OVH). Dans le fichier /etc/network/interfaces, on ajoute:

auto xenbr1
iface xenbr1 inet static
  address 172.16.0.X # pas vraiment nécessaire mais utile pour vérifier qu'on ping bien le bridge depuis les VMs. exemple: hyperviseur 1: 172.16.0.1, hv 2: 172.16.0.2, etc
  netmask 255.255.255.0 # à adapter en fonction du sous réseau choisi
  bridge_ports none # on ne veut bridger sur rien, mais pouvoir ajouter une interface au bridge en question (au hasard, tap0 de notre vpn L2)

on sauvegarde, puis:

sudo ip link add xenbr1 type bridge && sudo ip link set dev xenbr1 up && sudo ip addr add 172.16.0.1/24 dev xenbr1

(On peut aussi juste créer le bridge à la main via ip link et ne pas s'embêter avec /e/n/i, mais bon, ce serait bien qu'il soit toujours là après un reboot, sauf si c'est pour tester rapidement)

Configuration des VMs:

Suivant l'hyperviseur utilisé, ajouter une interface réseau virtuelle à chaque VM, liée au bridge xenbr1. Par exemple sous Xen, dans le fichier de configuration d'une VM:

vif         = [ 'mac=00:16:3E:AA:BB:CC,bridge=xenbr0','mac=00:16:3E:11:22:33,bridge=xenbr1' ]

Sur la(les) VM(s), assigner une IP à l'interface correspondante de votre VM (en général, eth1 ou équivalent), via /etc/network/interfaces, et relancer la VM (par ex un xl restart vm_name). Vérifier qu'on ping bien le bridge, histoire que tout soit propre.

Configuration serveur et client OpenVPN sur les hyperviseurs

On va, ici, configurer un tunnel TAP entre nos machines (un serveur, X clients), qui sera ensuite lié à nos bridges xenbr1 sur nos hyperviseurs, via le script de post-up d'openvpn. Vu qu'on est censés être sur un réseau privé (hum), on désactivera le chiffrement du VPN afin de gagner en perfs. Si par contre il s'agit de données sensibles, qu'on a pas confiance en l'hébergeur, ou tout simplement qu'on est parano^WWaime bien faire les choses proprement, on peut tout à fait chiffrer ce qui transite par le tunnel, soit via une PSK, soit via certificats. Dans mon cas par contre, je cherche le max de performances réseau et le minimum d'overhead CPU, donc pas de chiffrement. Pensez cependant à filtrer le port utilisé dans la configuration de votre pare-feu sur l'interface WAN de vos hyperviseurs, ou sinon utilisez la directive local adresse_ip_rpn pour qu'openVPN ne se "binde" que sur cette IP.

Configuration serveur:

On va éditer le fichier /etc/openvpn/server.conf (nom au choix)

lport 1194 #le port sur lequel openvpn écoutera
local IP_machine_sur_le_rpn
proto udp
dev tap
script-security 2 #pour pouvoir lancer notre script up.sh
up /etc/openvpn/up.sh
persist-key
persist-tun
cipher none
ping 5
ping-restart 60

Et c'est tout pour la conf.
Pour le script up.sh:

#!/bin/bash
# openvpn passe plusieurs paramètres (interface, mtu, etc) en arguments à une commande lancée par la directive "up", ici $1 sera le nom de l'interface tap sur laquelle openvpn dialoguera
ifconfig $1 0.0.0.0 up promisc # souvenirs, souvenirs :)
ip link set dev $1 master xenbr1

On sauvegarde, chmod u+x up.sh.

On dit ensuite à notre copain systemd de lancer openvpn au démarrage avec cette configuration:

systemctl enable openvpn@server
systemctl start openvpn@server #(bin oui, on veut le lancer quand même, sans rebooter l'hyperviseur :))

Et voilà pour le serveur.

Configuration du client

On va appeler notre configuration /etc/openvpn/client.conf (original, hein), qui contiendra:

rport 1194 #remote port sur lequel se connecter
proto udp
dev tap
nobind
script-security 2
remote $adresse_IP_RPN_du_serveur
up /etc/openvpn/up.sh
persist-key
persist-tun
cipher none
ping 5
ping-restart 60

Quant à up.sh, c'est le même contenu. On active et on lance la conf' via systemd:

systemctl enable openvpn@client
systemctl start openvpn@client

On peut ensuite tester de pinger les VMs d'un hyperviseur à l'autre pour vérifier la connectivité.

Et voilà! Après, on peut jouer sur la MTU à l'intérieur du VPN, sachant que le RPN d'Online permet d'utiliser les jumbo frames.


Tagged under: sysadmin, linux, network, Online, Virtualisation, openvpn