walk-hoary

Archives pour la catégorie Réseau

Communiquer entre l’hôte et les containers LXC

Aujourd’hui j’utilise un Raspberrry Pi comme routeur chez moi. Il me permet de me passer de la box internet et d’isoler les équipements de mon réseau avec des VLAN.

J’ai dans l’optique de rassembler différents services sur un seul hôte afin de réduire le nombre d’appareils, en commençant par Home-assistant et le système de routage/DHCP. Plus tard, ce sera d’autres service comme tvheadend qui permet de broadcaster la TNT reçue à mon domicile par une clé USB vers un serveur multimédia Jellyfin dans le cloud.

Quel hyperviseur sous Raspberry Pi ?

Pour cela, je me suis penché sur docker, mais cela ne me satisfait pas entièrement à cause des contraintes au niveau réseau qui sont souvent mal documenté ou géré par les mainteneurs des images. Proxmox était pour moi le candidat idéal, mais non supporté sur ARM64. Je me suis donc tourné vers LXC qui est la couche de conteneurisation utilisé par Proxmox. A noter que LXD convient également, il s’agit d’une implémentation plus évoluée de LXC, mais la direction de l’éditeur LXD me semble floue et incertaine et ne l’ai donc pas utilisé.

Un réseau simple

Un point important dans l’architecture est que je veux avoir accès aux différentes couches et d’une façon la plus naturelle possible, c’est à dire se rapprochant d’une architecture matérielle. Je trouve cela beaucoup plus facile à se le représenter et à l’exploiter, surtout si je dois y intervenir rarement.

Je veux par exemple, me connecter en SSH sur le RaspberryPi et rebondir en SSH sur différents containers. Et bien sachez que ce n’est pas possible naturellement sous docker ou LXC, il vous faudra créer une interface macvlan pour chaque container sur vôtre hôtes. Ça me parait beaucoup et ajoute une complexité à l’architecture que je ne veux pas.

Solution

La solution que j’ai trouvé est de se baser sur des interfaces bridges. Ainsi, les containers sont capables de communiquer avec l’extérieur mais surtout avec l’hôte.

Voici la configuration réseau du Raspberry Pi. Avec ceci, vous pourrez utiliser les liens habituels VETH avec LXC.

# /etc/network/interfaces.d/eth0
auto eth0
iface eth0 inet static
        address 192.168.0.1/24

# /etc/network/interfaces.d/br7
auto eth0.7
iface eth0.7 inet manual

auto br7
iface br7 inet static
        bridge_ports eth0.7
        bridge_fd 0
        bridge_maxwait 120
        address 10.35.7.1/24

Note : eth0.7 est une syntaxe qui vous permet d’avoir une interface qui ne communiquera qu’avec le traffic tagué VLAN 7. (Au même titre que eth0:1 vous permet d’avoir une nouvelle interface alias de eth0)

Tags: ,

Certificats pour serveurs

Cet article vous montre comment créer un certificat willcard signé par un tiers

Pourquoi un certificat ?

Parfois il m’arrive de ne pas pouvoir consulter mes emails car le réseau que j’utilise n’est pas sécurisé. J’entends par là que je ne sais pas qui est derrière et pourrait écouter mon trafic et capturer aisément mes identifiants.

J’ai donc décidé d’installer un certificat sur qth.fr. Comme la plupart de mes services sont en *.qth.fr j’ai choisis de faire un certificat willcard que j’ai fait signé par cacert. Le faire signer par autre que soit a l’avantage de pouvoir vérifier auprès de cacert que le certificat est valide. Il faut savoir que cacert est une autorité non reconnue par les navigateurs par défaut car son modele de confiance se base sur ses utilisateurs. (C’est les utilisateurs vérifient entre eux leur identité, cherchez « Key signing party » sur un moteur de recherche).

Ce serveur utilise donc les certificats de cacert ; pour installez le certificat root de cacert, rendez vous sur la page http://www.cacert.org/index.php?id=3 et cliquez simplment sur http://www.cacert.org/certs/root.crt . Attention, cela veux dire que vous acceptez tout les certificats signés par cacert !

Comment ça marche ? (grossièrement)

Pour sécuriser un site en SSL, le serveur doit obligatoirement connaitre un clée privée et un certificat publique signé. Il arrive qu’un ou plusieurs certificats intermédiaires soient nécessaires, j’en parlerais plus loin. Notez que les extensions varient d’un système à l’autre, mais on retrouve globalement KEY, CRT, CSR et PEM (ce dernier désigne en fait jusque c’est un fichier pour le chiffrement, j’utiliserais donc cette extension pour tous mes fichiers).

  • Le certificat privé « KEY » est un fichier généré que vous devez conserver et ne jamais le divulguer ! Il sera utilisé par votre serveur pour chiffrer votre trafic. Il peut être protégé par un mot de passe, libre à vous, personnellement je n’en met pas.
  • La demande de signature certificat « CSR » est un fichier généré à partir de la clé privée. ici je la crée en même temps. Elle peut être divulgué à votre tier de confiance. Elle contient diverses informations comme quels domaines il concerne, la durée de validité…
  • Le certificat « CRT » est le fichier généré par votre autorité de certification tiers.

Lorsque votre navigateur demande une page à votre serveur en SSL, ce dernier vous renvoie la réponse chiffrée avec le certificat publique signé par votre tiers. Votre navigateur peut donc vérifier que le certificat est valide auprès de l’autorité et déchiffrer la réponse du serveur.

Le certificat intermédiaire est parfois nécessaire lorsque l’autorité de certificat est inconnue de votre navigateur mais qui a pourtant été approuvé par une autre autorité, qui elle est connue de votre navigateur. Ce fichier doit donc être envoyé par le serveur en même temps que votre certificat signé. (Il peut y avoir plusieurs certificats intermédiaires).

Notez qu’il existe les certificats normaux et les certificats EV (Extended validate). Ces derniers permettent juste une vérification plus poussée de votre identification et provoque l’apparition de la barre d’adresse verte. (Sinon elle reste de la couleur normal)

Gérer un KEY et un CSR

Créer le fichier /usr/share/ssl-cert/ssleay-MONDOMAINE.cnf (un exemple se nome ssleay.cnf) et insérez ce texte que vous adapterez.

# -------------- BEGIN custom openssl.cnf -----
HOME                    = /etc/ssl/qth/
RANDFILE                = /dev/urandom
oid_section             = new_oids
[ new_oids ]
[ req ]
default_days            = 730            # how long to certify for (2yr)
default_keyfile         = /etc/ssl/qth/wildcard.qth.fr_key.pem
distinguished_name      = req_distinguished_name
encrypt_key             = no
string_mask = nombstr
req_extensions          = v3_req # Extensions to add to certificate request
[ req_distinguished_name ]
commonName              = Common Name (eg, YOUR name)
commonName_default      = qth.fr
commonName_max          = 64
countryName             = Country Name (2 letter code)
countryName_default             = FR
countryName_min                = 2
countryName_max                = 2
organizationName        = Organization Name (company)
organizationName_default        = QTH

localityName            = Locality Name (city, district)
localityName_default    = Paris

stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = IDF
emailAddress            = ca-admin@localhost.com
emailAddress_max        = 40
[ v3_req ]
subjectAltName=DNS:qth.fr,DNS:*.qth.fr
# -------------- END custom openssl.cnf -----

Lancez la génération :

openssl req -batch -config /usr/share/ssl-cert/ssleay-wildcard.qth.fr.cnf -newkey rsa:2048 -out /etc/ssl/qth/wildcard.qth.fr_csr.pem

Faites signez votre CSR chez une autorité de confiance

Pour ma part j’utilise startssl qui permet de signer des certificat entre 1 et 3 ans en wildcard. Pour cela il est nécessaire d’être identifié en class 2, cela coute 59$ ce qui vous permet de signer des certificats pendant 1 an.

Donc si vous  vous démerdez bien, vous n’avez qu’a vous aqcuiter des 59$ une fois tous les 3 ans. Moi je suis partit pour 2 ans car je me suis trompé dans la génération du CSR car c’est là qu’est précisé la durée de validité. La révocation coûte 24$.

Configurez apache/nginx

Créez un virtualhost qui écoutera sur le port 443 et insérez la configuration suivante :

SSLEngine on
SSLCertificateFile /etc/ssl/qth/wildcard.qth.fr_crt.pem
SSLCertificateKeyFile /etc/ssl/wildcard.qth.fr_key.pem

Et si besoin les certificats intermédiaires (Ajoutez les si votre autorité en a car d’autres navigateurs peuvent se comporter différemment que le votre au moment de vos tests) :
SSLCertificateChainFile /etc/ssl/qth/wildcard.qth.fr_intermediate1.pem

Cisco

J’ai du récemment dans mon travail à administrer des équipements CISCO, j’y ai passé pas mal de temps que ce soit pro ou perso car je n’ai jamais travaillé avec. Outre le petit routeur qui nous a servit de passerelle PPPoE remplacé par un FreeBSD, j’avoue ne pas être à l’aise avec cette syntaxe. Je vous donne ici les premiers élement qui m’on manqué pour commencer. Il ne s’agit là que de quelques mémos que je juge utile avant d’essayer de comprendre leur syntaxe. Après cela, la documentation est très abondante et surtout fournie par CISCO.

  • Lorsque vous êtes logué sur un cisco, vous pouvez être dans un mode normal qui ne vous autorise pas à le configurer. Vous devez alors taper enable pour y entrer et acceder à la config, aux propriétés…
  • La configuration se trouve dans un format linéaire, vous pouvez la voir en tapant show run (pour running-config)
  • Pour modifier la configuration, cela se fait ligne par ligne, entrez dans l’édition en tapant « conf t », terminez par CTRL+Z. Vos modifications sont appliquées immédiatement.
  • Vous vous déplacez par bloc dans la configuration, ainsi pour acceder au bloc Bloc_A.SousBloc_1, vous devez tapper Bloc_A, puis taper SousBloc_1. Vous pouvez à tout moment accéder aux autres blocs tant qu’ils sont enfant directs ou plus haut hiérarchiquement. (Bloc_E est accessible à tout moment par exemple)
  • Lorsque vous êtes en mode édition vous pouvez ajouter des ligne en les entrant directement, ou en enlever en tapant « no  » suivie de la ligne exacte.

Booter en PXE via USB ou CD-ROM

Certaines cartes mère ne permettent pas le boot PXE. Une solution existe : GPXE.

GPXE est bootable sur de mutiples supports : USB, CD-ROM… et permet d’éffectuer un boot réseau.

  • Rendez vous sur la page http://rom-o-matic.net/gpxe/gpxe-1.0.1/contrib/rom-o-matic/build.php
  • Choisissez le type d’image souhaité (usb pour les clés, iso pour les cdrom)
  • Ajoutez les commandes suivantes (Adapatez l’ip à celui de votre serveur tftp)
dhcp net0
set next-server 10.9.0.1
set filename pxelinux.0
autoboot

Tags: , , ,

Une netinstall sans internet, pourquoi des mises à jour non plus ?

Il est temps que je vous présente un script que j’utilise dans le GUL auquel je participe : un script pour squid.

Le but final ? C’est de réaliser des installs, de boots par le réseau et faire les dernières mises à jours lorsque la connexion internet est médiocre voir même innexistante.

Pour ça, on utilise déjà squid qui permet de « cacher » les fichiers téléchargés, mais nous utilisons aussi des dépots locaux sur un poste que nous gardons le plus à jour possible lors de l’install-party. Le script ne fait que traduire à squid les emplacement équivalents locaux pour des url normalement sur internet.

Ainsi, http://archive.ubuntu.com/dists/ devient http://10.9.0.72/ubuntu/dists/ pour squid. C’est donc transparent pour les utilisateurs.

Vous êtes intéressés, rendez vous sur la page du projet :

http://projects.qth.fr/projects/squidrepository

Tags: , , ,

Partage de connexion sous GNU/Linux

Voici un memo pour partager votre connexion internet sur votre PC.

Ici eth0 est l’interface accedant à internet, eth1 est l’interface du réseau local qui doit acceder à internet via eth0. On va utiliser l’ip forwarding, très simple…

Prérequis : Vous avez un serveur DHCP sur eth1 ou êtes déjà en ip statiques.

Activer l’ip forwarding

Prise en compte instantannée :

echo 1 > /proc/sys/net/ipv4/ip_forward

Pour que cela soit actif à chaque boot :

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

Activez le partage

Prise en compte instantannée:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Pour que cela soit permanant :

echo "iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE" >> /etc/network/if-up.d/ip-forward
chmod 755 /etc/network/if-up.d/ip-forward

Voilà 😉

Tags: , ,

Plusieurs ip sur une interface réseau

J’ai déjà eu besoin de faire communiquer quelques pc et un serveur sur un réseau déjà existant, et sans que les nouvelles machines ne puissent communiquer avec les pc déjà en place. Pour  cela je les ai confiné dans un adressage réseau différent. Il a donc fallut que le serveur communique avec les machines déjà en place et aussi les nouvelles.

Le serveur a déjà une ip 192.168.0.1/24, nous souhaitons lui ajouter l’ip 192.168.100.1/24.

L’idée est juste de créer une nouvelle interface virtuelle sur eth0, il suffit de l’appeller eth0:0 (ou :0 peut être remplacer si vous souhaitez d’autres interfaces virtuelles par :1 etc).

Il suffit donc d’ajouter les lignes suivantes dans /etc/network/interface si vous êtes dans une debian like.

auto eth0:0
iface eth0:0 inet static
address 192.168.100.1
netmask 255.255.255.0

Et voilà, activez votre nouvelle interface, le tour est joué :

ifup eth0:0

Tags: ,

Synthèse d’information IPV4

Voici une synthèse d’informations sur l’adressage réseau qui peut être parfois utile lorsque l’on ne manipule pas assez. Cela concerne l’IPV4.

On associe sur une machine, une ip au masque qui sert à déterminer dans quelle plage cette dernière est placée. Exemple : ip 192.168.0.1 masque 255.255.255.0 (ou 192.168.0.1/24).

C’est dans le réseau 192.168.0.0 à 192.168.0.255 (où 192.168.0.0 est l’adresse réseau et 192.168.0.255 est l’adresse broadcast).

Pour comprendre les masques, vous pouvez vous des opérations logiques de façon plus visuel !

IP Décimale 192.168.0.1 = binaire 1100000.10101000.00000000.00000001

MASQUE décimale 255.255.255.0 = binaire 11111111.11111111.11111111.00000000 = /24 bits de poids forts à 1

Ici le masque autorise donc à communiquer en changeant les 8 derniers bits de l’IP. (8bits = 255 IP possibles)

Le masque détermine quels bits de l’IP peut changer, si vous ne laissiez seulement un 0 qu’à la fin du masque en binaire, cela vous ferait seulement 2 adresses possibles. ( Mais unitilisables puisques la premiere et la dernière seraient réservées au réseau et au broadcast).

Les classes de réseau

Les classes réseau sont des plages d’ip séparrant toute les adresses possibles en 5 parties, de la classe A à E.

Les classes A, B et C ont chacun dans leur plage d’ip, un plage d’ip privées qui ne sont jamais routées sur internet, et donc utilisables sur des réseaux locaux. Pour cela je vous renvoie à la page wikipedia.

Il faut juste retenir la plupart du temps les plages suivantes :

Plage privée de la classe A : 10.0.0.0 à 10.255.255.255

Plage privée de la classe B : 172.16.255.0 à 172.31.255.255

Plage privée de la classe C : 192.168.0.0 à 192.168.255.255

Plage de multicast de la classe D 224.0.0.0 à 239.255.255.255

Plage interne : 127.0.0.0 à 127.255.255.255 (Souvent utilisé pour locahost ou 127.0.0.1)

Tags: , , , ,

Je n'aime pas les boîtes noires.