dat blaug

yet another barbu's website

Ubuntu 14.04 Et Broadcomm BCM43142

Pour faire fonctionner la carte wifi Broadcomm BCM43142 vendue avec des ordinateurs portables ASUS, il suffit d’installer un paquet qui va installer les bons modules tout seul :

téléchargement et compilation du module
1
sudo apt-get install bcmwl-kernel-source

Lors de votre prochain démarrage tout devrait bien se passer, et si vous ne souhaitez pas redémarrer :

chargement du module si on ne veut pas redémarrer
1
modprobe wl

À partir de là tout devrait bien fonctionner.

LXC Sans Peine

configuration de notre hôte

Histoire de faire du lxc simplement, tout d’abord :

installation des programmes utiles
1
apt-get install bridge-utils lxc debootstrap

Puis on se crée un bridge dans notre eni :

bridge inscrit danslink
1
2
3
4
5
6
7
8
9
10
11
12
13
auto lo
iface lo inet loopback

auto br0
iface br0 inet static
    address 198.18.0.10 # là c'est ton ip locale
    netmask 255.254.0.0 # ton netmask 
    network 198.18.0.0 # je vais pas faire ta conf non plus hein
    gateway 198.18.0.1 # magie, ta gateway
    bridge_ports eth0 # notre vraie interface, mappée à ce bridge
    bridge_stp on
    bridge_maxwait 0
    bridge_fd 0

On peut finir par un ifup br0 ou un reboot, ça dépendra de l’humeur de chacun.

création et configuration de notre premier lxc

Ensuite on a notre bridge qui tourne, on va configurer le réseau de nos machines LXC :

configuration réseau de notre première machine : “test”
1
2
cp /usr/share/doc/lxc/examples/lxc-veth.conf /etc/lxc/test.conf
vim /etc/lxc/test.conf # pour modifier les adresses IP

Maintenant on peut créer à proprement parler notre LXC :

création du lxc “test”
1
lxc-create -n test -f /etc/lxc/test.conf -t debian

Maintenant qu’on a créé notre vm on modifie vite-fait son fichier eni pour y enlever sa demande de DHCP au démarrage :

on vire le dhcp du démarrage
1
vim /var/lib/lxc/test/rootfs/etc/network/interfaces

Ce qui donne (oui, salade est le vrai nom de ma machine) :

root@salade /var/lib/lxc # cat /var/lib/lxc/test/rootfs/etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
#iface eth0 inet dhcp

lancement de notre premier lxc

démarrage et extinction
1
2
lxc-start -n test
lxc-stop  -n test

création d’autres lxc

On reprend tout ce qu’on a dit dans la section de création du premier lxc, sauf qu’on change juste les IP dans le nouveau fichier de configuration de réseau avant de lancer la création de la machine.

Voilà, et avec tout ça je me retrouve avec 3 machines qui tournent avec tout juste un petit giga de disque. Pour en savoir un peu plus et éventuellement les créer direct dans des volumes LVM, suivre ce petit lien.

Des bisous et du datalove. ♥

Ssh SOCKS5 Proxy

Pour monter un petit proxy HTTP à la maison rapidement :

proxy SOCKS5 via ssh
1
2
ssh -D portlocal remotessh
ssh -D 12000 karchnu@chezmoi # exemple

SSH je t’aime.

Installation De Mysql Sur OpenBSD

Pour installer Mysql sur OpenBSD il faut faire :

installation
1
pkg_add -i -r mysql-server

Ensuite nous devons initialiser la base de donnée par défaut :

initialisation de la base de données
1
/usr/local/bin/mysql_install_db

De là on peut changer le mot de passe root :

changement du mot de passe root
1
/usr/local/bin/mysqladmin -u root password 'YOUR-Secret-Password'

Et enfin on peut démarrer l’application :

démarrage et extinction de mysql
1
2
/usr/local/bin/mysqld_safe --user=_mysql # démarrage
mysqladmin -u root -p shutdown # arrêt

Git Clone Avec Erreur De Certificat

Ok c’est sale, mais pour faire vite on peut vouloir laisser tomber la vérification d’un certificat quand on clone un dépôt.

erreur de vérification du certificat
1
2
server certificate verification failed. 
CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
solution rapide et simple
1
2
3
export GIT_SSL_NO_VERIFY=1
ou
git config --global http.sslverify false

Octopress Sur Une Installation Récente

Alors je ne parlerai sans doute pas beaucoup de ruby sur le blog, mais vu que c’est assez chiant à faire fonctionner je suis obligé de faire un post sur… comment bien installer ruby et toutes ses conneries de dépendances pour utiliser Octopress.

Ce sera très court, mais j’ai eu des erreurs différentes entre deux installations. Là j’ai encore souvenir de ce que je viens d’installer, donc autant en profiter pour faire un petit récap.

installation de ruby et ses dépendances pour octopress
1
2
3
4
5
ruby --version # doit être > 1.9.1 (2.X sur Ubuntu v14.10)
sudo gem install bundler
rbenv rehash
sudo apt-get install ruby-dev
bundle install

Et à partir de là j’ai droit… à me passer de l’autocomplétement qui aurait pu être sympa pour l’outil rake ; non là je dois préfixer cet outil par bundle exec pour que tout fonctionne.

rake préfixé de bundle exec
1
bundle exec rake new_post['connerie de ruby']

Voilà. Oui je suis de mauvaise foi, sans doute que ruby c’est génial, mais fallait rendre ça plus simple. Là c’est juste pénible.

EDIT: pour retrouver le complètement automatique des commandes rake, il suffit de modifier le fichier “Gemfile”. Youhou \o/

gem 'rake', '~> 10.1.0'

Grub Vide Après Installation Avec Secure Boot

Grub qui est vide

Nous avons un système d’exploitation tout prêt, l’installation s’est bien déroulée mais il y a un petit problème : au démarrage le grub est complètement vide. On se retrouve avec uniquement un invité de commande, pas de menu.

Quand j’ai boot sur une clé pour réinstallé grub j’ai eu cette erreur :

erreur à l’installation de grub
1
2
3
4
5
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition;
embedding won't be possible.
grub-install: error: embedding is not possible, but this is required for
cross-disk install.

Solution, on démarre sur une clé de secours, puis :

changement de flags du disque
1
parted /dev/sdb set 1 bios_grub on

Ensuite il faut qu’on monte notre nouveau système installé (la partition root avec un /boot complet) et on réinstalle grub :

1
2
mount /dev/sdb1 /mnt/
sudo grub-install --root-directory=/mnt /dev/sdb

Et je suis Charlie.

Audio Hwinfo Et Lshw

Récemment j’ai voulu refaire la manipulation que j’ai décrite dans un précédent article mais le logiciel hwinfo n’est plus disponible pour ma distribution. Heureusement, un petit remplaçant (déjà dans mon système de base lui) qui est lshw.

Ce que je souhaitais faire ici était de voir les périphériques audio pour les inverser et que ma sortie audio par défaut soit changée. J’ai donc exécuté lshw -C sound et j’ai eu les identifiants des périphériques.

Suite de la procédure dans l’ancien article. ;)

Packet Filter

J’ai présenté il y a peu iptables, mais j’ai envie de passer aux systèmes BSD depuis quelques temps. Et sur ces systèmes, le pare-feu se fait via le programme pf (Packet Filter). Rien à voir en terme de syntaxe, et c’est précisément ce qu’on va voir ici.

Cet article sera dédié à la création d’une passerelle utilisant pf. Toute la configuration présentée ici est basique et ne prend pas en compte des techniques avancées (utilisation de tables, gestion de files d’attente, redondance réseau avec CARP et pfsync…).

Cet article ne sera pas mis à jour, cependant la page dédiée à pf sur le site fera l’objet d’une mise à jour régulière, suivant mon propre apprentissage de l’outil.

Préliminaires

éléments de syntaxe

Le fichier pf.conf est plutôt bien documenté (man pf.conf, doc sur openbsd.org, livre The Book of PF ). Je vais reprendre ici quelques éléments présentés sur le site d’openbsd de façon succincte.

Toute la configuration du pare-feu se fait dans le fichier /etc/pf.conf. Le programme pf est actif au démarrage, mais on peut le désactiver en mettant PF=NO dans le fichier /etc/rc.local. Le contrôle du programme se fait via la commande pfctl.

Les éléments manipulés dans ce fichier seront :

  • des macro : adresse ou liste d’adresses ou plages IP, de ports, etc
  • des tables : une structure qui gère des listes d’adresses
  • des options : pour gérer comment fonctionne PF
  • des règles : pour filtrer les paquets, les rediriger, faire du NAT…
exemple de macro suivie d’une règle
1
2
int_if = "vio0"
pass on $int_if

Avec pass une commande pour laisser passer le paquet, et on $int_if ce qui arrive sur l’interface interne définie juste avant. Je n’explique pas plus, on verra par l’exemple.

en-tête du fichier

On va commencer par configurer quelques macros pour rendre le reste de la configuration le plus générique possible. N’oubliez pas que pour connaître les noms des interfaces disponibles on utilise ifconfig sous BSD.

# dépend de votre matériel
ext_if = "tun0" # interface externe (branchée à la box)
int_if = "vio0" # interface interne (branchée au réseau local)

# plage d'IP interne liée à votre interface interne
# (RFC 1918, généralement dans 192.168.0.0/16)
localnet = $int_if:network 

# ICMP autoriser les requêtes et les réponses unreach
icmp_types = "{ echoreq, unreach }"
pass inet proto icmp icmp-type $icmp_types

# tout ce qui sort sur l'interface externe (pour aller sur Internet)
# aura son adresse IP source remplacée par l'adresse IP de l'interface
# ext_if 
# on met des parenthèses autour du nom de l'interface si son adresse IP
# peut changer, auquel cas pf se débrouille pour ne pas perdre les
# connexions déjà établies
match out on $ext_if from $localnet nat-to ($ext_if)

# par défaut, on bloque TOUT
block all

Première phase : une passerelle et des clients

On a une passerelle entre la box de notre FAI et des clients (c’est-à-dire des ordinateurs sans serveur applicatif). On souhaite laisser la possibilité aux clients de sortir du réseau local. Bien entendu, on souhaite garder un certain contrôle sur ce qu’ils peuvent faire, si on a du windows à la maison, on a pas envie de devenir un nid à SPAM.

Autoriser les clients à sortir du réseau

On va se contenter de donner le droit aux clients de se connecter au web (http et https), à des machines distantes (ssh), à leur compte email (pop3, imap, imaps) et quelques autres trucs. Avec pf, nous n’avons pas besoin d’écrire les ports, nous pouvons faire référence à leur nom dans le fichier /etc/services.

client_out = "{ ssh, domain, imap, imaps, pop3, auth, \
              nntp, http, https, 6667 }"

# certains services utilisent aussi l'UDP
udp_services = "{ domain, ntp }"

# on laisse passer les paquets udp/tcp de façon inconditionnelle
pass quick inet proto { tcp, udp } to port $udp_services

# on laisse passer les connexions TCP autorisées
pass proto tcp to port $client_out

Seconde phase : ajout d’un serveur

Pour l’instant, on a notre passerelle et des clients. On va ajouter un serveur web à notre infra.

On va vouloir que notre passerelle redirige les connexions entrantes sur les ports 80 et 443 vers le serveur web interne.

Configuration du serveur web

On laisse passer ce qui arrive sur l’interface externe, et on redirige via le mot clé rdr-to vers l’adresse du serveur en interne. Il faudra laisser passer ensuite ce qui arrive sur l’interface interne vers le serveur web (aux ports associés).

webserver = "192.168.0.190"
webserverports = "{ http, https }"

# WEBSERVER
# redirection vers l'adresse IP local du serveur
pass in on $ext_if inet proto tcp to $ext_if port $webserverports rdr-to $webserver
# on laisse passer le trafic en direction du serveur (IP et port)
pass on $int_if inet proto tcp to $webserver port $webserverports

Cette configuration est suffisante pour un serveur web sans clients à l’intérieur du réseau local. Pour que les clients locaux puissent accéder au serveur web local, il faut détecter qu’on cherche à se connecter à l’IP de notre interface externe à partir d’une adresse locale. On redirige alors directement vers les ip des bons serveurs en local.

# connexion d'un client local à notre IP globale
# on le redirige vers le bon serveur en local
pass in on $int_if inet proto tcp from $localnet to $ext_if port $webserverports rdr-to $webserver

# NAT à l'IP interne pour ne pas que le serveur cherche à discuter 
# directement au client local mais passe par la passerelle
pass out on $int_if proto tcp from $localnet to $webserver port $webserverports nat-to $int_if

Troisième phase : serveur sans passerelle configurée

Cette troisième partie est utile voire nécessaire dans ma situation. L’explication est simple : ma passerelle OpenBSD est actuellement une passerelle entre un tunnel VPN et mon réseau local. Ce n’est pas ma passerelle pour accéder à internet directement. Je souhaite que tout le trafic de mes serveurs passe par le VPN, qui a une adresse IP fixe et qui est neutre, le reste passe par mon opérateur directement.

une histoire d’adresses IP source et destination

Actuellement, lors d’une connexion, on redirige le trafic entrant vers le serveur web, sans changer l’adresse IP source, juste celle de destination (IP publique => IP locale du serveur web). Le serveur web peut alors répondre directement à l’émetteur de la requête, et sa passerelle par défaut est mon serveur BSD (avec pf). Il comprend qu’il faut faire du NAT en sortie (changement de l’IP source de la réponse, celle du serveur web, par l’IP publique, de l’interface externe de la passerelle), tout se passe bien.

Le problème que j’ai actuellement est que sur un même ordinateur, je fais tourner un logiciel de partage en pair-à-pair, qui génère beaucoup de trafic, et un serveur de stockage de données Bacula (pour les sauvegardes). Je ne souhaite pas que mon trafic sur le VPN soit encombré, et donc je ne souhaite pas que le trafic du logiciel pair-à-pair sorte par le VPN.

une solution simple

La solution la plus simple à mettre en œuvre est de configurer la passerelle par défaut comme étant la box de l’opérateur, et de configurer pf pour qu’il fasse du NAT en interne. L’effet voulu est que la passerelle change l’adresse IP source des paquets entrants sur l’interface externe par l’adresse IP de son interface interne (comme fait précédemment pour les connexions « clients à serveur interne ») . Le logiciel serveur dans notre réseau local répondra alors à notre passerelle BSD.

serveur = "192.168.0.101"
serveurports = "{ 9103 }"

# comme pour l'autre serveur
pass in on $ext_if inet proto tcp to $ext_if port $serveurports rdr-to $serveur
pass out on $int_if inet proto tcp to $serveur port $serveurports
pass in on $int_if inet proto tcp from $localnet to $ext_if port  $serveurports rdr-to $serveur
pass out on $int_if proto tcp from $localnet to $serveur port $serveurports nat-to $int_if

# faire du NAT à la réception sur tout ce qui arrive en direction du serveur
pass out on $int_if proto tcp to $serveur port $serveurports received-on $ext_if nat-to $int_if
pass out on $int_if proto tcp to $serveur port $serveurports received-on $int_if nat-to $int_if

Quelques commandes utiles

Pour gérer PF

  • pfctl -e : activer pf
  • pfctl -d : désactiver pf

  • pfctl -f /etc/pf.conf : charger le fichier pf.conf

  • pfctl -nf /etc/pf.conf : vérifier que le fichier n’a pas d’erreur de syntaxe

  • pfctl -sr : montrer les règles courantes

  • pfctl -ss : montrer l’état des tables
  • pfctl -si : montrer les statistiques et compteurs de filtres
  • pfctl -sa : tout montrer

Pour lire les logs des règles

Les règles de pf qui sont historisées (via la règle log) peuvent être lues sur l’interface pflog0 via l’utilitaire tcpdump. Cet outil comprend les règles de BPF ainsi que la possibilité de sélectionner une règle pf à afficher.

exemple de lecture de log
1
2
tcpdump -i pflog0 # lire tous les paquets des règles historisées
tcpdump -i pflog0 port domain # lire les paquets port 53 (résolution DNS)

Chaque règle qui est inscrite dans votre fichier pf.conf est numérotée, ce qui a pour avantage de pouvoir être sélectionnée pour trier les logs.

log avec un numéro de règle pf
1
2
3
4
5
6
7
8
# règle historisée (mot clé : log)
pass log proto tcp to port $client_out

# chercher son numéro de règle
pfctl -vvs rules

# afficher les paquets qui correspondent à cette règle (X = numéro règle)
tcpdump -ttt -i pflog0 rulenum X

Les quelques options suivantes sont intéressantes à connaître pour le debug :

  • -ttt : permet d’afficher les dates de façon compréhensible
  • -n : ne pas faire de reverse dns, afficher les ip pas les noms de domaine
  • rulenum : pour spécifier un numéro de règle pf de votre pf.conf