Configurer le réseau

Connection en tant que client

Paramétrer le poste OpenBSD comme client le temps de mettre à jour le système.

• vr1 : interface interne (IP 192.168.10.2) ;
• IP de la passerelle : 192.168.10.1.

ifconfig vr1 192.168.10.2 netmask 255.255.255.0"
route add default 192.168.10.1

ou créer /etc/hostname.vr1 :

inet 192.168.10.2 255.255.255.0 NONE

Connection PPPOE

fichiers de conf ppp

Le fichier ppp.conf contient l'essentiel des paramètres de connection et notamment les login/pass du FAI. Le fichier de conf ci-dessous s'applique à la version 2.3 de pppd, sinon d'assurer que toutes les options sont bien reconnues (man ppp en contient la liste exhaustive). mssfixup en particulier, n'est apparu que dans les dernières versions (il évite notamment d'avoir à définir le MRU.

Les fichiers de conf /etc/ppp/ppp.conf et /etc/ppp.ppp.linkup ci-dessous sont extraits de l'excellent document http://real.ath.cx/BSDinstall.html, ce sont ceux que j'utilise et qui en tout cas fonctionnent :

# ppp.conf

default:
 set log Phase Chat LCP IPCP CCP tun command
 set redial 15 28800
 set reconnect 15 28800

pppoe:
 set device "!/usr/sbin/pppoe -i vr0"
 disable acfcomp protocomp
 deny acfcomp
 set mtu max 1492
 set speed sync
# enable lqr
# set lqrperiod 5
 set cd 5
 set dial
 set login
 set timeout 0
 set authname xxxxxxxx
 set authkey xxxxxxxxx
 enable sroutes
 add default HISADDR
 enable mssfixup
#enable dns

Précisions importantes :

• option enable dns : Personnellement j'ai supprimé ``enable dns'', car j'utilise un DNS local et mon resolv.conf est statique (127.0.0.1). Cette option permet juste à ppp d'interroger le provider et de mettre automatiquement à jour le resolv.conf ;
• options lqr et lqrperiod : apparemment, mieux vaut les virer à partir de la version 3.2. Auparavant ça marchait, et là maintenant celà nous crée une sorte de connection alternative (un coup ça passe, un coup ça passe pas :), merci fcob.

# ppp.linkup 

MYADDR:
#! sh -c "/sbin/pfctl -e -l tun0 -F all -O agressive -R /etc/pf.conf -N \
/etc/nat.conf"                                             # versions < 3.2
! sh -c "/sbin/pfctl -e -l tun0 -F all -f /etc/pf.conf"    # versions >= 3.2

Le fichier ppp.linkup n'a me semble-t-il d'intérêt que si l'on change d'IP à la reconnection. J'ai une IP fixe et ne l'utilise pas, les règles n'ont pas besoin d'être rechargées.

Pour les options ppp, persist est bien entendu facultatif, mais extrêmement utile lorsqu'on ne dispose pas d'une IP fixe, pour éviter de perdre sa connection en cas de changement d'IP.

#/etc/ppp/options
lock
# persist
noauth
debug

lancement de la connection au démarrage : méthode goret Vs méthode ``propre''

# /etc/rc.local (méthode = lancement goret bien sûr :)
ifconfig vr0 up
ppp -ddial pppoe

Sinon, j'ai trouvé une méthode beaucoup plus propre ici : http://www.drones.com/obsd-fw, une excellente doc !

Cette méthode consiste à coller ces quelques lignes de shell tout à la fin de /etc/netstart :

echo -n ' ADSL... '; ; ppp -ddial pppoe 
for i in 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0; do
    sleep 5
    echo -n ``.$i''
    if /usr/local/sbin/adsl-status>/dev/null; then
        break
    fi
done
echo
/usr/local/sbin/adsl-status

Puis on crée le script correspondant /usr/local/sbin/adsl-status :

#!/bin/sh
 
IP=$(/sbin/ifconfig tun0 | awk '/netmask/{print $2}')
 
if [ -z "$IP" ]; then
   echo "ADSL link is down."
   exit 1
else
   echo "ADSL is up, IP address $IP"
   exit 0
fi

L'intérêt de la méthode est de démarrer proprement la connection ADSL au démarrage de la machine en évitant les 50 messages d'erreurs, NAT en particulier (tun0 n'étant pas encore monté), et de s'assurer que Bind se lancera correctement.

Mise à jour dyndns avec ipcheck

[ attention, uniquement testé en 2.8, du temps ou j'avais une IP dynamique, merci de m'informer si ça ne marche plus !]

Si vous disposez d'un IP fixe, vous pouvez biensûr sauter cette section.

Avertissement : il existe une multitude de clients dyndns (dont ddup) mais attention, je me suis deja fait killée par dyndns pour "update abuse" :) Dyndns refuse en effet des update intempestifs alors sur une IP intacte, il faut donc absolument un script qui teste l'IP _avant_ d'updater *abusivement*. C'est notamment le cas d'ipcheck : http://ipcheck.sourceforge.net/

Détails pratiques :

• installer python ;
• télécharger le script : http://ipcheck.sourceforge.net/ipcheck.py ;
• le mettre dans /usr/local/sbin/ipcheck.py ;
• remplacer le path python dans le script : #!/usr/local/bin/python ;
• créer un rep vide /etc/ipcheck/ ;
• créer un fichier exécutable /usr/local/sbin/do_ipcheck :

#!/bin/sh
/usr/local/sbin/ipcheck.py -q -d /etc/ipcheck -i tun0  -w \
login pass host1.dyndns.org,host2.dyndns.org

Avant toute chose, lors de la 1ere utilisation, créer le fichier dat en ligne de commande (option makedat) :

/usr/local/sbin/ipcheck.py -q -d /etc/ipcheck -i tun0 --makedat  -w \
login pass host1.dyndns.org,host2.dyndns.org

Pour automatiser l'ensemble lors de l'initialisation de la connection ppp, ajouter dans /etc/ppp/ppp.linkup :

# ppp.linkup 

MYADDR:
! sh -c "/sbin/ifconfig pflog0 up"
! sh -c "/sbin/pfctl -e -l tun0 -F all -O agressive -R /etc/pf.conf -N \
/etc/nat.conf"
! bg sh -c "/usr/local/sbin/do_ipcheck"

et vu qu'on a mis ppp en mode persist ça ne suffit pas (ppp.linkup ne sera lu que lors de la premiere connection, au démarrage de la machine, enfin si j'ai bien compris...), donc on le colle dans la crontab:

*/10     *       *       *       *      /usr/local/sbin/do_ipcheck