Mayo 23

Installer djbdns

De nos jours, l’utilisation des DNS est indispensable, c’est grâce à ces serveurs de noms
que nous pouvons par exemple taper « google.fr » dans la barre d’adresse au lieu de « 216.239.57.104« .
Le rôle d’un serveur de nom est donc de faire de la résolution d’adresses et de la résolution de noms,
pour obtenir respectivement des noms, et des adresses.

Je vous invite à vous rendre sur l’adresse suivante pour en apprendre plus sur les DNS :
http://www.commentcamarche.net/internet/dns.php3

N’hésitez donc pas à nous communiquer toute erreur, remarque, suggestion, complément via la page
contact, merci.

Si vous désirez faire appel à nos services pour installer djbdns, et ses composants nécessaires
sur votre serveur, merci de nous contacter.

Sommaire

Objectif de ce guide

  • Savoir que Bind n’est pas le seul moyen de mettre en place un serveur de noms.
  • Savoir installer djbdns.
  • Savoir mettre en place un cache DNS grâce à djbdns.
  • Savoir mettre en place un serveur de noms grâce à djbdns.
  • Savoir mettre en place un serveur pour les transferts de zones grâce à axfrdns.

Pourquoi choisir djbdns

  • Sécurité : Son développeur D.J. Bernstein a
    développé djbdns en ayant en tête la question de sécurité ; depuis des années, alors que
    Bind a été sujet à des failles de sécurité, djbdns, lui, n’a eu aucun
    problème. Notez aussi que D.J. Bernstein offre 500$ à la première personne qui prouvera que la dernière version
    de djbdns contient une faille de sécurité, voir (US) :
    http://cr.yp.to/djbdns/guarantee.html
  • Performances : djbdns consomme bien moins de ressources (cpu/ram) que
    Bind. Notez aussi que vous pouvez faire des changements dans les zones DNS sans avoir à redémarrer
    tinydns, celui-ci s’aperçoit automatiquement que data.cdb a été modifié et recharge donc l’ensemble
    des zones.
  • Distinction entre cache DNS et serveur DNS : Pour plus d’infos, lisez la
    page ci-dessous (US) : http://cr.yp.to/djbdns/separation.html

Pré-requis

Vous devez avoir au préalable installé les éléments suivants pour que djbdns puisse fonctionner.
Et vous devez évidement avoir un accès root sur le serveur concerné.

Installation de djbdns

Notez que si vous utilisez actuellement Bind, cette étape ne modifie en rien votre configuration actuelleaucun risque
concernant le bon fonctionnement de votre serveur de noms actuel, vous pouvez donc laisser Bind en marche (conseillé).
Ce n’est qu’à partir des étapes de mises en place que vous devrez changer certaines configurations pour que bind
ne soit plus le cache/serveur de noms.

Entrez sur un compte non privilégié (non root) de votre serveur, et tapez les commandes suivantes,
dans le répertoire de votre choix (les fichiers qui vont êtres téléchargés sont temporaires et
seront supprimés à la fin de l’installation, vous pouvez par exemple vous rendre dans /tmp :

cd /tmp
wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz -O djbdns-1.05.tar.gz
tar xzvf djbdns-1.05.tar.gz
cd djbdns-1.05
echo gcc -O2 -include /usr/include/errno.h > conf-cc
make

Maintenant, en root, tapez la commande suivante :

make setup check

Enfin, revenez sur le compte non privilégié et tapez la ligne suivante pour informer le créateur de
djbdns que vous avez réussi à installer son programme, en remplaçant bien sûr
First M. Last par vos nom et prénom :

( echo 'First M. Last'; cat `cat SYSDEPS` ) \
| mail djb-sysdeps@cr.yp.to

Enfin, si vous souhaitez supprimer les fichiers d’installation, utilisez les commandes suivantes :

cd ..
rm -rf djbdns-1.05
rm -f djbdns-1.05.tar.gz

Option de « convivialité », si vous souhaitez avoir accès aux logs dans /var/log (Merci Toorop) :

mkdir /var/log/djbdns

Mise en place du cache (dnscache)

Logiquement le module dnscache va écouter en local : 127.0.0.1 sur TCP/53 et UDP/53.
Tant que ce n’est pas indiqué, dnscache n’aura pas besoin que ces ports soient libres, donc inutile d’arrêter bind avant.

Pour commencer, on va créer les comptes unix nécessaires à dnscache, il faut être root (su) :

useradd -s /bin/false dnscache
useradd -s /bin/false dnslog

Ensuite on va configurer dnscache pour qu’il utilise ces comptes, il faut être root (su) :

dnscache-conf dnscache dnslog /etc/dnscache

La commande précédente a crée le répertoire /etc/dnscache qui contient les éléments de configuration et de fonctionnement de dnscache.

A cet instant, dnscache est prêt à être utilisé, pour l’activer, commencez par désactiver bind :
(cf. Annexe plus bas concernant l’arrêt de bind).

Notez que vous pouvez aussi entrer les commandes ci-dessous plus tard, après avoir configuré vos zones
pour tinydns et vos règles pour axfrdns afin que Bind continue de jouer le rôle de cache DNS
le plus longtemps possible.

ln -s /etc/dnscache /service

Après cinq secondes minimum, vous pouvez vérifier le fonctionnement de dnscache en utilisant la commande suivante :

svstat /service/dnscache

Vous devriez avoir quelque chose du genre : /service/dnscache: up (pid XXXX) 3 seconds

Désormais, dnscache écoute TCP et UDP 53 en local, pour répondre aux requêtes DNS.
Votre système peut donc interroger dnscache pour résoudre des noms et des adresses.
Assurez-vous que votre système utilise dnscache en éditant le fichier /etc/resolv.conf,
qui doit contenir une ligne du type :

nameserver 127.0.0.1

Cette ligne doit être la première ligne commençant par nameserver si vous souhaitez que votre système
utilise dnscache.

Enfin pour vérifier que votre système sait résoudre les noms, tapez les commandes suivantes :

dnsip www.cnn.com
dnsip www.fsf.org

Si vous voyez apparaître une ou plusieurs adresses IP (xxx.xxx.xxx.xxx), et aucun message d’erreur c’est que tout roule !

Option de « convivialité », si vous souhaitez avoir accès aux logs dans /var/log (Merci Toorop) :

ln -sf /etc/dnscache/log/main /var/log/djbdns/dnscache

Vous avez terminé si votre serveur ne doit pas jouer le rôle de serveur DNS.

Vous trouverez plus d’informations sur les pages suivantes :

Page de djbdns (US) : http://cr.yp.to/djbdns.html

Comment faire fonctionner un cache DNS (US) : http://cr.yp.to/djbdns/run-cache.html

Le programme dnscache-conf (US) : http://cr.yp.to/djbdns/dnscache-conf.html

Le programme dnscache (US) : http://cr.yp.to/djbdns/dnscache.html

Mise en place du serveur de noms (tinydns)

Logiquement le module tinydns va écouter sur votre adresse ip publique en UDP/53.
Tant que ce n’est pas indiqué, tinydns n’aura pas besoin que ce port soit libre, donc inutile d’arrêter bind avant.

Pour commencer, on va créer les comptes unix nécessaires à tinydns, il faut être root (su) :
Ne tappez pas la seconde commande si vous avez déjà crée le compte dnslog dans l’étape 5 / dnscache

useradd -s /bin/false tinydns
useradd -s /bin/false dnslog

Ensuite on va configurer tinydns pour qu’il utilise ces comptes, il faut être root (su) :
Evidement, remplacez XXX.XXX.XXX.XXX par votre adresse IP publique, celle qui écoutera le réseau.

tinydns-conf tinydns dnslog /etc/tinydns XXX.XXX.XXX.XXX

La commande précédente a créé le répertoire /etc/tinydns
qui contient les éléments de configuration et de fonctionnement de tinydns.

A cet instant, tinydns est prêt à être utilisé, pour l’activer,
commencez par désactiver bind :
(cf. Annexe plus bas concernant l’arrêt de bind).

Notez que vous pouvez aussi entrer les commandes ci-dessous plus tard, après avoir configuré vos
règles pour axfrdns afin que Bind continue de jouer le rôle de
serveur de noms le plus longtemps possible.

ln -s /etc/tinydns /service

Après cinq secondes minimum, vous pouvez vérifier le fonctionnement de tinydns en utilisant
la commande suivante :

svstat /service/tinydns

Vous devriez avoir quelque chose du genre : /service/tinydns: up (pid XXXX) 3 seconds

Désormais, tinydns écoute UDP 53 sur votre adresse ip publique, pour répondre aux requêtes
DNS. tinydns peut donc répondre aux requêtes DNS liées aux zones que vous allez configurer.

Nous avons mis en ligne un guide pour la configuration des zones dans tinydns,

Option de « convivialité« , si vous souhaitez avoir accès aux logs dans /var/log (Merci Toorop) :

ln -sf /etc/tinydns/log/main /var/log/djbdns/tinydns

Attention, dans certains cas, il peut être nécessaire que votre serveur réponde aux requêtes DNS sur TCP/53, dans ce cas,
lisez l’étape 7 / axfrdns.

Vous trouverez plus d’informations sur les pages suivantes :

Page de djbdns (US) : http://cr.yp.to/djbdns.html

Comment faire fonctionner un serveur DNS (US) : http://cr.yp.to/djbdns/run-server.html

Le programme tinydns-conf (US) : http://cr.yp.to/djbdns/tinydns-conf.html

Le programme tinydns (US) : http://cr.yp.to/djbdns/tinydns.html

Mise en place du serveur pour les transferts de zones (axfrdns)

Dans quels cas avez-vous besoin d’écouter le port TCP/53 ?

  • Votre serveur doit pouvoir faire du transfert de zones vers d’autres serveurs (AXFR)
  • Un serveur parent refuse de vous déléguer une zone tant que vous n’écoutez par sur TCP/53 (ex .fr)

Vous devez avoir mis en place tinydns sur votre serveur pour pouvoir mettre en place axfrdns !

Comment mettre en place axfrdns ?

Pour commencer, on va créer les comptes unix nécessaires à axfrdns, il faut être root (su) :

useradd -s /bin/false axfrdns

Ensuite on va configurer axfrdns pour qu’il utilise ce compte, il faut être root (su) :
Evidement, remplacez XXX.XXX.XXX.XXX par votre adresse IP publique, celle qui écoutera le réseau.

axfrdns-conf axfrdns dnslog /etc/axfrdns /etc/tinydns XXX.XXX.XXX.XXX

La commande précédente à créé le répertoire /etc/axfrdns qui contient
les éléments de configuration et de fonctionnement de axfrdns.

Vous remarquerez que nous avons précisé à axfrdns-conf le répertoire de
configuration de tinydns dont il a besoin.

Pour terminer la configuration d’axfrdns, nous allons lui dire d’autoriser toutes les
connexions entrantes, de répondre aux requêtes DNS, mais de refuser tout transfert de zones (nous verrons
plus bas comment autoriser le transfert de zones vers d’autres serveurs), vous devez être root (su) :

echo ':allow,AXFR=""' > /etc/axfrdns/tcp

A cet instant, axfrdns est prêt à être utilisé.

Notez que vous pouvez aussi entrer les commandes ci-dessous plus tard, après avoir configuré
vos règles pour les transferts de zones.

ln -s /etc/axfrdns /service

Après cinq secondes minimum, vous pouvez vérifier le fonctionnement de axfrdns
en utilisant la commande suivante :

svstat /service/axfrdns

Vous devriez avoir quelque chose du genre : /service/axfrdns: up (pid XXXX) 3 seconds

Désormais, axfrdns écoute TCP 53 sur votre adresse ip publique.

Option de « convivialité« , si vous souhaitez avoir accès aux logs dans /var/log (Merci Toorop) :

ln -sf /etc/axfrdns/log/main /var/log/djbdns/axfrdns

A cet instant axfrdns joue le même rôle que tinydns sur le port TCP/53.
Pour autoriser le transfert de zones (axfr), suivez les étapes ci-dessous.

Comment autoriser le transfert de zones vers d’autres serveurs ?

Si vous désirez autoriser le transfert d’une seule zone vers un autre serveur,

  • xxx.xxx.xxx.xxx étant l’adresse IP du serveur qui sera autorisée à transférer la zone
  • zone.com étant la zone autorisée à être transféré par xxx.xxx.xxx.xxx

Tapez les commandes suivantes en root,
et pensez à valider les changement de /etc/axfrdns/tcp (voir plus bas) :

echo 'xxx.xxx.xxx.xxx:allow,AXFR="zone.com"' >> /etc/axfrdns/tcp

Si vous désirez autoriser le transfert de plusieurs zones vers un autre serveur,

  • xxx.xxx.xxx.xxx étant l’adresse IP du serveur qui sera autorisée à transférer les zones
  • zone.com et autrezone.net étant les zones autorisées à être transférées par xxx.xxx.xxx.xxx

Tapez les commandes suivantes en root,
Remarquez qu’il suffit de séparer les zones par des slashs « / »
et pensez à valider les changements de /etc/axfrdns/tcp (voir plus bas) :

echo 'xxx.xxx.xxx.xxx:allow,AXFR="zone.com/autrezone.net"' >> /etc/axfrdns/tcp

Si vous désirez autoriser le transfert de toutes vos zones vers un autre serveur,

  • xxx.xxx.xxx.xxx étant l’adresse IP du serveur qui sera autorisée à transférer vos zones

Tapez les commandes suivantes en root,
Remarquez qu’il suffit de retirer ,AXFR= »… »
et pensez à valider les changements de /etc/axfrdns/tcp (voir plus bas) :

echo 'xxx.xxx.xxx.xxx:allow' >> /etc/axfrdns/tcp

Comment valider les changements faits dans /etc/axfrdns/tcp ?

Utilisez simplement les commandes suivantes, en root, pour valider les changements faits dans vos règles, notez aussi qu’il est
inutile de redémarrer axfrdns, le programme tcpserver prend automatiquement en compte les
changements faits dans tcp.cdb :

cd /etc/axfrdns
make

Vous trouverez plus d’informations sur les pages suivantes :

Page de djbdns (US) : http://cr.yp.to/djbdns.html

Comment faire pour répondre aux requêtes TCP/53 (US) : http://cr.yp.to/djbdns/tcp.html

Le programme axfrdns-conf (US) : http://cr.yp.to/djbdns/axfrdns-conf.html

Le programme axfrdns (US) : http://cr.yp.to/djbdns/axfrdns.html

Category: DNS | Los comentarios están deshabilitados en Installer djbdns
Mayo 15

MultiPath TCP

Manual configuration

With multiple addresses defined on several interfaces, you want to be able to tell your kernel “If I select such source address, please use that specific interface+gateway, not the default ones”. You achieve this by configuring one routing table per outgoing interface, each routing table being identified by a number. The route selection process then happens in two phases. First the kernel does a lookup in the policy table (that you need to configure with ip rules). The policies, in our case, will be For such source prefix, go to routing table number x. Then the corresponding routing table is examined to select the gateway based on the destination address.
You need to configure several routing tables in the following manner: Imagine you have two interfaces eth0 and eth1 with the following properties:
eth0

IP-Address: 10.1.1.2
 Subnet-Mask: 255.255.255.0
 Gateway: 10.1.1.1
eth1
 IP-Address: 10.1.2.2
 Subnet-Mask: 255.255.255.0
 Gateway: 10.1.2.1

Thus, you need to configure the routing rules so that packets with source-IP 10.1.1.2 will get routed over eth0 and those with 10.1.2.2 will get routed over eth1.
The necessary commands are:

# This creates two different routing tables, that we use based on the source-address.
 ip rule add from 10.1.1.2 table 1
 ip rule add from 10.1.2.2 table 2
# Configure the two different routing tables
 ip route add 10.1.1.0/24 dev eth0 scope link table 1
 ip route add default via 10.1.1.1 dev eth0 table 1
ip route add 10.1.2.0/24 dev eth1 scope link table 2
 ip route add default via 10.1.2.1 dev eth1 table 2

# default route for the selection process of normal internet-traffic
ip route add default scope global nexthop via 10.1.1.1 dev eth0
With this, your routing table should look like the following:

mptcp-kernel:~# ip rule show
 0: from all lookup local
 32764: from 10.1.2.2 lookup 2
 32765: from 10.1.1.2 lookup 1
 32766: from all lookup main
 32767: from all lookup default
mptcp-kernel:~# ip route
 10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.2
 10.1.2.0/24 dev eth1 proto kernel scope link src 10.1.2.2
 default via 10.1.1.1 dev eth0
mptcp-kernel:~# ip route show table 1
 10.1.1.0/24 dev eth0 scope link
 default via 10.1.1.1 dev eth0
mptcp-kernel:~# ip route show table 2
 10.1.2.0/24 dev eth1 scope link
 default via 10.1.2.1 dev eth1

 

Automatic Configuration
Doing the above each time by hand is very cumbersome. Some alternative automatic solutions are available:
Using the configuration scripts (Ubuntu/Debian-based systems)
In /etc/network/if-up.d/ you can place scripts that will be executed each time a new interface comes up. We created two scripts:

* mptcp_up – Place it inside /etc/network/if-up.d/ and make it executable.
* mptcp_down – Place it inside /etc/network/if-post-down.d/ and make it executable.

#!/bin/sh
# A script for setting up routing tables for MPTCP in the N950.
# Copy this script into /etc/network/if-up.d/
set -e
env > /etc/network/if_up_env
if [ "$IFACE" = lo -o "$MODE" != start ]; then
 exit 0
fi
if [ -z $DEVICE_IFACE ]; then
 exit 0
fi
# FIRST, make a table-alias
if [ `grep $DEVICE_IFACE /etc/iproute2/rt_tables | wc -l` -eq 0 ]; then
 NUM=`cat /etc/iproute2/rt_tables | wc -l`
 echo "$NUM $DEVICE_IFACE" >> /etc/iproute2/rt_tables
fi
if [ $DHCP4_IP_ADDRESS ]; then
 SUBNET=`echo $IP4_ADDRESS_0 | cut -d \ -f 1 | cut -d / -f 2`
 ip route add table $DEVICE_IFACE to $DHCP4_NETWORK_NUMBER/$SUBNET dev $DEVICE_IFACE scope link
 ip route add table $DEVICE_IFACE default via $DHCP4_ROUTERS dev $DEVICE_IFACE
 ip rule add from $DHCP4_IP_ADDRESS table $DEVICE_IFACE
else
 # PPP-interface
 IPADDR=`echo $IP4_ADDRESS_0 | cut -d \ -f 1 | cut -d / -f 1`
 ip route add table $DEVICE_IFACE default dev $DEVICE_IP_IFACE scope link
 ip rule add from $IPADDR table $DEVICE_IFACE
fi

 

#!/bin/sh
# A script for setting up routing tables for MPTCP in the N950.
# Copy this script into /etc/network/if-post-down.d/
set -e
env > /etc/network/if_down_env
if [ "$IFACE" = lo -o "$MODE" != stop ]; then
 exit 0
fi
ip rule del table $DEVICE_IFACE
ip route flush table $DEVICE_IFACE

 

Category: Uncategorized | Los comentarios están deshabilitados en MultiPath TCP
Mayo 15

HAPROXY ssl bridging

global
 log /dev/log local0
 log /dev/log local1 debug
 chroot /var/lib/haproxy
# user haproxy
# group haproxy
 daemon
 maxconn 20000
 pidfile /var/run/haproxy.pid
 stats socket /var/run/haproxy.stat level admin
listen stats
 bind :8880
 mode http
 stats enable
 stats hide-version
 stats uri /
 stats show-legends
 stats refresh 10s
 stats realm HAProxy\ Statistics
 stats auth admin:admin
 timeout client 30s

defaults
 option dontlognull
 option redispatch
 option contstats
 retries 3
 timeout client 5s
 timeout connect 5s
 timeout server 150s
 timeout http-keep-alive 1s
 # Slowloris protection
 timeout http-request 15s
 timeout queue 30s
 timeout tarpit 1m # tarpit hold tim
 backlog 10000
 errorfile 403 /etc/haproxy/errors/403.http
frontend https-in
 option httplog
 log global
 mode http
 bind *:80 name http
 bind *:443 name https ssl crt /etc/haproxy/certs/webmail.pem transparent
# option http-server-close
 option forwardfor
 reqadd X-Forwarded-Proto:\ https
# by HMU
 http-request add-header X-Proto https if { ssl_fc }
##
 http-request redirect scheme https code 302 if !{ ssl_fc }
 http-request redirect location /owa/ code 302 if { hdr(Host) webmail.xxx-services.com} { path / }
log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\ %CC\ %CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ {%sslv/%sslc/%[ssl_fc_sni]/%[ssl_fc_session_id]}\ %{+Q}r
#Definitions des ACL pour le routage par domaine
 acl host_site_sharepoint hdr(host) -i extranet.xxx-service.com
 acl host_site_exchange hdr(host) -i webmail.xxx-services.com
#Regles de routage si une ACL est respectee
 use_backend site_sharepoint if host_site_sharepoint
 use_backend site_exchange if host_site_exchange
#Routage par defaut si erreur
 default_backend site_exchange
backend site_sharepoint
 mode http
 balance leastconn
# option http-server-close
 option redispatch
 cookie SERVERID insert nocache
 option forwardfor
# server sharepoint 192.168.93.4:80
 server sharepoint 192.168.93.4:443 check ssl verify required ca-file /etc/haproxy/certs/webmail.pem
backend site_exchange
 mode http
 balance leastconn
 #option http-server-close <= Plante l'authentification NTLM
# option http-server-close
 option forwardfor
 server exfe 192.168.93.2:443 check ssl verify required ca-file /etc/haproxy/certs/webmail.pem
Category: HAPROXY | Los comentarios están deshabilitados en HAPROXY ssl bridging
Mayo 15

Converting pfx to pem using openssl for HAPROXY

openssl pkcs12 -in file.pfx -out file.nokey.pem -nokeys
openssl pkcs12 -in file.pfx -out file.withkey.pem
openssl rsa -in file.withkey.pem -out file.key
cat file.nokey.pem file.key &gt; file.combo.pem
Category: SSL | Los comentarios están deshabilitados en Converting pfx to pem using openssl for HAPROXY