Auteur Sujet: Le guide complet : Internet, TV et Téléphone sans Livebox (et bien plus encore)  (Lu 217884 fois)

0 Membres et 1 Invité sur ce sujet

seb59

  • Expert
  • Abonné Orange Fibre
  • *
  • Messages: 60
  • Wasquehal (59)
Annexe : installer et configurer un serveur Asterisk (part 1)
« Réponse #12 le: 13 janvier 2017 à 16:55:30 »
Annexe : installer et configurer un serveur Asterisk pour la famille et la domotique (partie 1)

Pour ma part j’ai souvent utilisé le serveur Lync de Microsoft (maintenant renommé Skype for Business) mais ici j’ai décidé de découvrir Asterisk.

Vous avez beaucoup de solution basée sur Asterisk et apportant un lot de fonctionnalités supplèmentaires comme une interface Web d’administration, etc… Parmi eux on retrouve pour les plus connus : FreePBX, Incredible PBX, XiVO, PIAF, Trixbox, Elastix, AsteriskNow, etc..

Mes besoins sont simples : èmettre des appels puis les mobiles ou PC (pratique pour l’étranger), recevoir les appels sur le mobile ou PC en fonction de là où je suis connecté, pouvoir transférer les appels entrants à ma femme, un répondeur, enregistrement des conversations à la demande, interconnexion avec la domotique soit pour m’appeler en cas de problème (alarme, fuite d’eau ou autre) ou soit pouvoir appeler la maison pour piloter des équipements (chauffage, alarme, mise mode « vacance », etc..). Pour cela le plus simple est d’utiliser Asterisk seul sans surcouche.

Installation d’Asterisk
Pour installation, on commence par les prérequis :

sudo apt-get install build-essential
sudo apt-get install linux-headers-$(uname -r)
sudo apt-get install libxml2-dev libncurses5-dev libsqlite3-dev
sudo apt-get install uuid-dev libjansson-dev libssl-dev

Puis on télécharge la dernière version d’Asterisk 13 :
 
wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-13-current.tar.gz
tar zxvf asterisk-13-current.tar.gz
cd asterisk-13.X.0
./configure
make menuselect

Dans le menu, on sélectionne :
  • Dans «  Core Sound Package
    • CORE-SOUNDS-FR-ULAW1
    • CORE-SOUNDS-FR-ALAW1
  • Dans « Music On Hold File Packages »
    • MOHOPSOUND-ULAW
    • MOH-OPSOUND-ALAW (décocher celui en WAV)
  • Dans « Extras Sound Packages »
    • EXTRA-SOUNDS-FR-ULAW1
    • EXTRA-SOUNDS-FRALAW1

Ne reste plus qu’à compiler et installer le service :

make
sudo make install
sudo make samples
sudo make config

On peut maintenant lancer Asterisk :
 
/etc/init.d/asterisk start
Pour accéder à la console (plus il y a de « v » plus le niveau de log est important) :

asterisk -cvvvvvvvvvvr
Configuration de l’envoi de mail
Avant de continuer, nous allons installer le nécessaire pour l’envoi de mail que nous utiliserons pour l’envoi des messages vocaux laissés sur la messagerie ou encore l’envoi des conversations enregistrées.
Pour cela installer « ssmpt » :

sudo apt-get install ssmtp mailutils
Ensuite éditer le fichier « /etc/ssmtp/ssmpt.conf » :

# L’adresse email de « root »
root=sebastien@mondomaine.fr

# Le Serveur SMTP d’envoi (ici en TLS port 587 – Attention, port 25 bloqué par Orange)
mailhub=mail.mondomaine.net:587

# Si authentification :
AuthUser=monuser
AuthPass=monpassword
# Dans mon cas, mon serveur support le STARTTLS (crypté)
UseSTARTTLS=YES

# Where will the mail seem to come from?
rewriteDomain=monserveur.net

# Nom DNS du serveur
hostname=voip.monserveur.net

# On désactive l’override du « From » (on se basera exclusivement sur les alias, voir ci-dessous)
FromLineOverride=NO

Ensuite on configurer les « alias » (correspondance entre les utilisateurs du système et les adresses) pour l’envoi de mail.

root:monuser@mondomaine.net:mail.mondomaine.net:587
Ici je défini que l’utilisateur « root » envoie des mails depuis l’adresse « monuser@mondomaine.net » en utilisateur le serveur STMP mail.mondomaine.net sur le port 587.

Pour tester :

sebastien@voip-server:~$ sudo ssmtp sebastien@mondomaine.net
Subject : Demo

Ceci est un test

Pour envoyer le mail « Ctrl + D » ou pour annuler « Ctrl + Z ». Pour les logs, voir « /var/log/mail.log ».

Configuration de base d’Asterisk avec la ligne Orange
Passons maintenant à l’enregistrement de votre ligne Orange accessible via le proxy SIP local sur Asterisk.

Sauvegardez le fichier original et repartons d’un fichier vide :

sudo mv /etc/asterisk/sip.conf /etc/asterisk/sip.conf.original
sudo nano /etc/asterisk/sip.conf

Le contenu du fichier sera :

[general]
context=default
language=fr
allowoverlap=no
bindport=5060
bindaddr=0.0.0.0
srvlookup=no
qualify=yes
defaultexpiry=1800
maxexpiry=1800
keepalive=120
alwaysauthreject=yes
allowguest=no
disallow=all
allow=gsm,ulaw,alaw,adpcm,speex,g729,g723
domain=voip.mondomaine.net
canreinvite=no

useragent=PBX
sdpsession=Talk
sdpowner=+33xxxxxxxxx

register => +33xxxxxxxxx @trunk_orange/+33xxxxxxxxx

[trunk_orange]
type=peer
nat=force_rport,comedia
context=incoming_orange
defaultuser=+33xxxxxxxxx
fromuser=+33xxxxxxxxx
remotesecret=orange
host=orange-multimedia.fr
port=5070
insecure=port,invite
fromdomain=orange-multimedia.fr
outboundproxy=localhost:5070,force
canreinvite=no
sendrpid=no
dtmfmode=auto
call-limit=1
allowguest=yes

On a ici un serveur SIP qui écoute sur le port standard 5060. Mon serveur SIP est exposé sur Internet pour permettre de se connecter depuis son mobile via la 3G/4G. Il faut donc le sécuriser un maximum le serveur, notamment en spécifiant le « alwaysauthreject » et le « allowguest ».

J’enregistre le lien « peer » avec Orange en spécifiant l’adresse de notre proxy SIP local sur le port 5070. Notez que le mot de passe n’a pas d’importance puisque le plugin Orange sur « siproxd » ne prend pas en compte l’authentification derrière le proxy.

Le domaine « orange-multimedia.fr » doit être résolu localement. Pour cela éditer le fichier « /etc/hosts » et ajoutez la ligne :

127.0.0.1       orange-multimedia.fr
On va également modifier le fichier « /etc/asterisk/rtp.conf » pour reconfigurer la plage des ports RTP :

rtpstart=12100
rtpend=12120

Côté routeur, je vais rediriger le trafic du port 5060 (SIP) et des ports RTP d’Asterisk vers mon serveur local (10.2.4.25).

J’ajoute également cette règle en « Hairpin NAT », de ce fait sur chaque client SIP je configurerai mon serveur via son DNS externe (ex. voip.mondomain.net) et cela doit marcher aussi depuis l’extérieur (NAT classique) qu’à l’intérieur (Harpin NAT) :

/ip firewall nat
add action=dst-nat chain=dstnat comment="NAT to SIP/RTP (Asterisk)" dst-port=\
    5060,12100-12120 in-interface=vlan832-internet protocol=udp to-addresses=\
    10.2.4.25
add action=dst-nat chain=dstnat comment="Hairpin NAT SIP/RTP" \
    dst-address-type=local dst-port=5060,12100-12120 protocol=udp \
    src-addresses=10.2.4.0/24 to-addresses=10.2.4.25

Côté firewall, on autorise ces ports en « forward » (voir l’explication ci-dessus).

/ip firewall filter
add action=accept chain=services comment="Allow SIP (VoIP)" dst-port=\
    5060,12100-12120 protocol=udp

On peut également ajouter une protection sur la tentative de connexion un peu trop rapprochée (même si la plupart des bots laissent la connexion ouverte pour tester différents credentials) :

add action=drop chain=protection comment="Drop SIP hackers" in-interface=\
    vlan832-internet src-address-list=SIP_Hackers
add action=add-src-to-address-list address-list=SIP_Hackers \
    address-list-timeout=1d chain=protection comment=\
    "Add to SIP Hackers list for 1 day" connection-state=new dst-port=5060 \
    in-interface=vlan832-internet log=yes log-prefix="SIP Hacker:" protocol=\
    udp src-address-list=SIP_Attempt
add action=add-src-to-address-list address-list=SIP_Attempt \
    address-list-timeout=15s chain=protection comment=\
    "SIP Attempt (15 seconds)" connection-state=new dst-port=5060 \
    in-interface=vlan832-internet protocol=udp

Pour plus de sécurité, je vous invite à mettre en place « fail2ban », ou encore le TLS.

Configuration des utilisateurs
 
Passons à la configuration de nos utilisateurs. Pour cela sauvegardez le fichier original « /etc/asterisk/users.conf » et partez d’un fichier vide avec le contenu :

[general]
hasvoicemail = yes
hassip = yes
hasiax = yes
callwaiting = yes
threewaycalling = yes
callwaitingcallerid = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes
callgroup = 1
pickupgroup = 1
nat = auto_force_rport,auto_comedia

Comme vous le constatez dans la section général je déclare que chaque utilisateur aura une messagerie vocale, une adresse SIP et pourront entre autre « parker » les appels ou les transférer.
Chaque utilisateur sera dernière un NAT (même ceux en interne via l’Hairpin NAT).

Ensuite on va déclarer un template que j’ai nommé « Chikawa » pour spécifier des paramètres communs dont le nom du contexte local nommé la aussi « chikawa » :

; Template
[chikawa](!)
type = friend
host = dynamic
disallow = all
allow = alaw
context = chikawa
Pour finir je déclare 5 utilisateurs (trois pour moi, un pour ma femme et un pour la maison/domotique).

A l’inverse des configurations qu’on trouve souvent, j’identifie mes utilisateurs avec un nom et non un chiffre. Je trouve cela plus simple et c’est en plus sécurisé car les bots tenteront de s’identifier avec des noms d’utilisateur numérique.
De ce fait je spécifie via l’option « cid_option », son n° (local Caller ID). Je spécifie également le n° de la boite vocal associée à l’utilisateur.

Enfin, n’étant pas adepte des mots de passe en clair, j’utilise l’option « md5secret » et non « secret » pour spécifier le mot de passe de l’utilisateur.
La valeur de ce paramètre est le hash MD5 de « user:asterisk:password ». Ainsi pour l’utilisateur « sebastien » avec le mot de passe « demo », la valeur de « md5secret » sera « af96d5785e002afcc870ae692d7426d3 » (soit le hash de « sebastien:asterisk:demo »).

[sebastien](chikawa)
fullname = Sebastien Warin
mailbox = 100
cid_number = 100
md5secret= af96d5785e002afcc870ae692d7426d3

[sebastien_po](chikawa)
fullname = Sebastien Warin (Portable)
mailbox = 101
cid_number = 101
md5secret= f2804f41da51fa6f6aa81d06ef64e269

[sebastien_pc](chikawa)
fullname = Sebastien Warin (PC)
mailbox = 102
md5secret= bb4fd1d16ad61e9f13cb6c8a7a3a7bef
cid_number = 102

[lili](chikawa)
fullname = Olivia
md5secret = 1644d2fdb71b7a830563bdbc51df1169
mailbox = 110
cid_number = 110

[constellation](chikawa)
fullname = Constellation
md5secret = d59df7a52c07fac0f73fcee775b3b18a
mailbox = 120
cid_number = 120

J’utilise Zoiper sur Android et Xlite sur Windows. On peut donc maintenant configurer chaque compte avec le login/password de l’utilisateur et l’adresse DNS/IP de votre connexion externe. Chaque client doit pouvoir s’enregistrer que l’on soit sur le réseau interne ou non.

N’oubliez pas d’activer le service STUN (Simple Traversal of UDP through NATs, service permettant de connaitre son IP externe) sur vos clients dans les paramètres réseau des clients SIP.
 


Maintenant que toutes nos machines ou smartphones sont connectés que l’on soit en interne ou non, il ne reste plus qu’à définir un « plan d ‘appel », le dial plan.

Configuration un Dial Plan
Une fois n’est pas coutume, sauvegarder le fichier original « /etc/asterisk/extensions.conf » et partez d’un fichier vide !

Dans la section « general » on garde les options suivantes :

[general]
static=yes
writeprotect=no
clearglobalvars=yes

Ensuite dans le contexte « local » que j’ai nommé « chikawa » on configure les plans d’appel pour chaque utilisateur :

[chikawa]

; Dial 1xx = Poste intérieur
exten => 100,1,GoSub(call-user,s,1(SIP/sebastien,${EXTEN}))
exten => 101,1,GoSub(call-user,s,1(SIP/sebastien_po,${EXTEN}))
exten => 102,1,GoSub(call-user,s,1(SIP/sebastien_pc,${EXTEN}))
exten => 110,1,GoSub(call-user,s,1(SIP/lili,${EXTEN}))
exten => 120,1,GoSub(call-user,s,1(SIP/constellation,${EXTEN}))

Comme vous le voyez pour chaque n°, 100, 101,… on appelle l’utilisateur par son nom avec la routine « call-user » défini en bas de fichier de la façon suivante :

[call-user]
exten => s,1,Verbose("Calling ${ARG1}")
    same => n,Dial(${ARG1},15,tTxXkK)
    same => n,VoiceMail(${ARG2}@chikawa)
    same => n,Hangup()

On appelle l’utilisateur (argument 1) pendant 15 secondes max avec les options t/T (transfert), x/X (enregistrement) et k/K (park). Si l’utilisateur n’a pas répondu, on renvoie l’appel sur la messagerie (n° spécifié par le deuxième argument).

Vous pouvez recharger votre dial plan (dialplan reload) sur la console Asterisk et désormais vos utilisateurs peuvent s’appeler entre eux.

Pour sortir en utilisant la ligne Orange, voici le plan :

; Réécriture des appels au format int.
exten => _00.,1,Goto(+${EXTEN:2},1)
exten => _0XXXXXXXXX,1,Goto(+33${EXTEN:1},1)

; Appel vers la france (fixe et mobile)
exten => _+33[1-79]XXXXXXXX,1,Macro(outgoing-call,${EXTEN})

; N° sépciaux (gratuit seulement)
exten => _1X,1,Macro(outgoing-call,${EXTEN})
exten => _11X,1,Macro(outgoing-call,${EXTEN})
exten => _116XXX,1,Macro(outgoing-call,${EXTEN})
exten => _+3380[0-5]XXXXXX,1,Macro(outgoing-call,${EXTEN})

; Refus des autres numéros
exten => _.,1,Playback(pbx-invalid)
   same => n,Hangup()

Les numéros commençant par 0 sont d’abord réécrits au format international. Ensuite sont autorisées à sortir, les numéros de fixes et mobiles français ainsi que les numéros spéciaux gratuits.

Pour le reste on indique à l’utilisateur que le n° n’est pas valide (son « pbc-invalid ») et on raccroche l’appel.

La macro « outgoing-call » de zoc permet de passer l’appel sur le « trunk orange » et gère le cas d’une erreur de type « channel unavailable » en rechargement les peers SIP avant de rejouer l’appel.

[macro-outgoing-call];
exten => s,1,Log(NOTICE, Outgoing call to ${ARG1})
exten => s,n,Set(NUMBER=${ARG1})
exten => s,n,Dial(SIP/${NUMBER}@trunk_orange,,KXT)
exten => s,n,Log(NOTICE, Outgoing failed with error ${DIALSTATUS})
exten => s,n,Goto(s-${DIALSTATUS},1)
exten => s-NOANSWER,1,Hangup()
exten => s-CONGESTION,1,Congestion()
exten => s-CANCEL,1,Hangup()
exten => s-BUSY,1,Busy()
exten => s-CHANUNAVAIL,1,Log(NOTICE, Outgoing trunk unavailable - restarting)
exten => s-CHANUNAVAIL,n,Wait(1)
exten => s-CHANUNAVAIL,n,System(sudo asterisk -rx "sip reload")
exten => s-CHANUNAVAIL,n,Wait(1)
exten => s-CHANUNAVAIL,n,Log(NOTICE, Second attempt at calling ${NUMBER})
exten => s-CHANUNAVAIL,n,Dial(SIP/${NUMBER}@trunk_orange,,TXK)
exten => s-CHANUNAVAIL,n,Hangup()

Dans la mesure du possible utilisez les routines et non les macros désormais dépréciées.

Pour la réception des appels, voici une première version :

[incoming_orange]
exten => +33xxxxxxxxx,1,Log(NOTICE, Incoming call from ${CALLERID(num)})
   same => n,Dial(SIP/sebastien, 15, txk)
   same => n,Dial(SIP/lili, 15, txk)
   same => n,Voicemail(120@chikawa)
   same => n,Hangup()

On fait sonner l’utilisateur « sebastien » 15 secondes, puis « lili » et si personne n’a répondu, on envoie l’appel sur la messagerie « 120 » puis on raccroche.

Configuration de la messagerie
Tout d’abord on va installer un petit programme pour gérer l’envoi des messages vocaux en MP3 :

cd /usr/sbin
sudo wget http://pbxinaflash.com/sendmailmp3.tar.gz
sudo tar zxvf sendmailmp3.tar.gz
sudo rm sendmailmp3.tar.gz
sudo chmod 0755 sendmailmp3

sudo apt-get -y install lam
sudo apt-get -y install lame
sudo apt-get -y install dos2unix
sudo apt-get -y install unix2dos
sudo sed -i -e 's/echo -e/echo/g' sendmailmp3

Ensuite on édite le fichier « /etc/asterisk/voicemail.conf » pour configurer chaque boite et l’envoi automatique des messages par mail :

[general]
format=wav
serveremail=voip@mondomain.net
attach=yes
maxsilence=10
silencethreshold=128
maxlogins=3
sendvoicemail=yes

; En MP3 :
mailcmd=/usr/sbin/sendmailmp3

;Corps du mail
emaildateformat=%A, %d %B %Y a %H:%M:%S
emailsubject=[Telephone] Nouveau message dans la boite ${VM_MAILBOX}
emailbody=Bonjour ${VM_NAME},\n\n\tLe numero ${VM_CALLERID} a tente de vous joindre sans succes le ${VM_DATE}.\nCette personne vous a laisse un message de ${VM_DUR} se$
pagerfromstring=[Asterix]
pagersubject=Nouveau message vocal
pagerbody=Nouveau message de ${VM_DUR} secondes dans la boite ${VM_MAILBOX} laisse le ${VM_DATE} par ${VM_CALLERID}.

[chikawa]
; extension => modedepasse, designation, mail
100 => 1234, Sebastien, sebastien@mondomain.fr
110 => 5678, Olivia, olivia@mondomain.fr
120 => 7890, Chikawa, sebastien@mondomain.fr

De retour sur le fichier extension on ajoute le numéro « 700 » pour accéder à sa boite perso. Le n° de la boite est identifié avec la variable « ${CALLERID(num)} » qui retourne le CallerID :

; Dial 700 = Numéro de la boite vocale perso
exten => 700,1,Answer
   same => n,Wait(1)
   same => n,VoiceMailMain(${CALLERID(num)}@chikawa,s)
   same => n,Hangup()

Seulement chez nous, les appels entrant sont redirigés (en cas de non réponse) sur la boite commune « 120 ».
De ce fait, j’ajoute le numéro 800 pour accéder à cette boite « commune »:

; Dial  800 = boite vocale commune
exten => 800,1,Answer
   same => n,Wait(1)
   same => n,VoiceMailMain(120@chikawa,s)
   same => n,Hangup()

Remarquez l’option « s » passée à l’application « VoiceMailMain » qui permet de ne pas demander le mot de passe pour accéder à la boite.

On peut également enrichir l’appel entrant en ajoutant dans le contexte « incoming_orange »:

; Acces distant a la messagerie vocale par appui de la touche * lors de l’annonce
exten => a,1,VoiceMailMain(120@chikawa)
   same => n,Hangup()

Ainsi lorsque l’on passe un appel vers notre n° orange, on peut accéder à la messagerie commune (120) en appuyant sur « * ». Par contre dans ce cas on ne met pas l’option « s », autrement dit l’interlocuteur sera invité à taper le code PIN de la messagerie.
« Modifié: 13 janvier 2017 à 17:33:47 par seb59 »

seb59

  • Expert
  • Abonné Orange Fibre
  • *
  • Messages: 60
  • Wasquehal (59)
Annexe : installer et configurer un serveur Asterisk (part 2)
« Réponse #13 le: 13 janvier 2017 à 17:13:19 »
Synthèse vocale
Il y a plusieurs applications permettant de jouer des sons préenregistrés comme « Playback » ou « Background ».

Par exemple, pour faire une « horloge parlante » qui répondra au n° « 500 » :

; Dial 500 = Horloge
exten => 500,1,Answer()
    same => n,Set(CHANNEL(language)=fr)
    same => n,Playback(welcome)
    same => n,SayUnixTime(,Europe/Paris,AdBY kM)
    same => n,Playback(vm-goodbye)
    same => n,Hangup()

On peut également ajouter le script AGI pour faire du TTS avec le service de Google :

sudo apt-get install perl libwww-perl sox mpg123
cd /var/lib/asterisk/agi-bin
sudo wget https://raw.github.com/zaf/asterisk-googletts/master/googletts.agi
sudo chmod 755 googletts.agi

Maintenant pour faire un test, appelez le « 8000 » avec ce code :

exten => 8000,1,Answer()
    same => n,agi(googletts.agi,"Bienvenue sur le serveur vocal Chikawa !",fr)
    same => n,agi(googletts.agi,"Qui souhaitez-vous joindre?",fr,any)
    same => n,agi(googletts.agi,"Pour Sebastien tapez 1",fr,any)
    same => n,agi(googletts.agi,"Pour Olivia tapez 2",fr,any)
    same => n,agi(googletts.agi,"Appuyez sur dièse si vous souhaitez réécouter ce  message",fr,any)
    same => n,Hangup()

Transfert d’appel
Editez le fichier « /etc/asterisk/features.conf » et configurez :

blindxfer => #1
atxfer => #2

Ainsi pendant un appel, appuyez sur « #1 » pour transférer l’appel vers un autre poste en mode aveugle (transfert direct) ou « #2 » en mode supervisé (on appelle la personne avant de transférer l’appel).

Parcage d’appel
Vous décrochez l’appel sur votre PC mais vous devez y aller et vous souhaitez le reprendre sur votre smartphone. Vous pouvez soit faire un transfert vers votre smartphone en gardant l’appel ou soit « parker » l’appel et le reprendre plus tard.

Car si vous devez y aller, vous avez besoin de quelques secondes/minutes pour fermer votre poste, ranger vos affaires, prendre vos clés et mettre votre manteau. Pas pratique avec un appel en cours !

En « parkant » l’appel, vous le rangez dans un parking à une position donnée et votre interlocuteur aura une belle musique d’attente. Quand vous êtes disposé vous appelez cette place de parking (depuis n’importe quel poste) pour reprendre votre appel.

Pour cela éditez le fichier « « /etc/asterisk/res_parking.conf ». Pour ma part le parking est en 6xx, je change donc les deux paramètres suivants dans le fichier :

parkext => 600
parkpos => 601-620

Plutôt que transférer l’appel au « 600 » pour « parker »  l’appel on va configurer la touche directe « #3 ». Editez le fichier « /etc/asterisk/features.conf » et configurez :

parkcall => #3
Enfin adaptons notre dialplan :

; Dial 600 = Parking
include => parkedcalls
exten => 600,1,Park()
exten => _6XX,1,ParkedCall(default,${EXTEN})

Et voilà, lors d’un appel j’appuie sur les touches « #3 » et le serveur Asterisk me donne le numéro de la place de parking de cet appel, un nombre compris entre 601 et 620.

L’appel est mis en attente et des que je souhaite, sur un des postes de mon contexte local « chikawa » je compose le numéro de la place que l’on m’a attribué et je reprends mon appel.

Enregistrement vocal
Pratique après un échange un peu houleux avec un SAV. Pour garder trace de l’échange, j’enregistre l’appel. Pour cela deux touches « *1 » et hop l’appel est enregistré puis envoyé au format MP3 par mail à la fin de la conversation !

Pour configurez cela, éditez le fichier « /etc/asterisk/features.conf » avec :

automixmon => *1
J’utilise le « Mix Monitor » et non « Monitor ».  Le « Mix » monitor enregistre le canal de l’appelé et de l’appelant dans le même fichier WAV alors que le « Monitor » simple entre les deux canaux dans deux fichiers séparés. De ce fait je n’ai pas activé de touches pour le « automon » car cela ne m’intéresse pas !

Les fichiers WAV sont sauvegardés dans « /var/spool/asterisk/monitor/ ». De ce fait j’ai bricolé un petit script pour compresser l’enregistrement en MP3 et l’envoyer par mail.

sudo nano /usr/sbin/sendrecord.sh
Le script se base sur ssmtp déjà installé avec la messagerie vocale :

#!/bin/bash

MAIL_TO="sebastien@mondomaine.fr"

for f in /var/spool/asterisk/monitor/*.wav
do
  [[ -f "$f" ]] || continue
  if [ "${f}" != "${f%.wav}" ];then

    FULLDATE=`date -r $f`
    DATE=`date '+%Y-%m-%d %H-%M-%S' -r $f`
    FROM=`echo ${f##*/} | cut -d'-' -f3`
    TO=`echo ${f##*/} | cut -d'.' -f1  | cut -d'-' -f4`
    DIR=`dirname $f`
    MP3FILE="record-$FROM-$TO-$DATE.mp3"

    echo "Processing $f"

    lame $f "$DIR/$MP3FILE";

    echo "Subject: Enregistrement du $FULLDATE

    Bonjour,

    Veuillez retrouver ci-joint l'enregistrement de votre conversation avec le numero $TO du $FULLDATE

    Cordialement," | (cat - && uuencode "$DIR/$MP3FILE"  "$MP3FILE") | /usr/sbin/ssmtp $MAIL_TO

    rm $f

  fi
done

Ce script est ensuite exécuté toutes les minutes. Pour cela éditer le cron de root :

su
crontab –e

Et ajoutez la ligne :

* * * * * /usr/sbin/sendrecord.sh >/dev/null 2>&1
Idéalement il faudrait pouvoir envoyer l’enregistrement à la personne ayant déclenchée l’appel mais cela supposerait de récupérer l’adresse email pour une extension donnée qu’on a déjà défini dans la configuration de la messagerie (voicemail.conf).

Intégration dans la « domotique » de la maison

L’ensemble de ma maison est domotisée grâce à la plateforme d’interconnexion d’objets connectés, applications et services que je développe nommée Constellation. Vous trouverez différent article sur le sujet sur mon blog : http://sebastien.warin.fr

De ce fait, grâce à Asterisk on peut donner les capacités aux autres objets, applications et services de la maison de passer ou recevoir des appels.

Par exemple, faire clignoter des LED d’un Arduino ou d’un Raspberry en cas d’appel, m’appeler encas d’alarme, de fuite, de fenêtre laissée ouverte en cas de pluie ou même avoir la possibilité d’appeler la maison pour piloter le chauffage Nest, couper ou allumer des machines à distance, ouvrir la porte du garage, ou simplement piloter un Arduino…

Pour cela on peut interagir de deux manières avec Asterisk : via l’AMI et l’AGI.

L’AMI : Asterisk Manager Interface
L’AMI est une interface basée sur TCP permettant de se connecter en tant que « Manager » sur le serveur pour le piloter.

Il suffit de créer un compte Manager avec différents droits dans le fichier « /etc/asterisk/manager.conf » :

[general]
enabled = yes
port = 5038
bindaddr = 0.0.0.0

[sebastien]
secret=demo
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.0
permit=10.2.4.0/255.255.255.0
read = system,call,log,verbose,agent,user,config,dtmf,reporting,cdr,dialplan,cc
write = system,call,agent,user,config,command,reporting,originate,message

Ensuite un programme peut se connecter sur l’AMI avec le compte « sebastien ».

J’ai donc développé un package (= un connecteur dans la terminologie Constellation) permettant d’exposer les fonctionnalités de l’AMI dans Constellation pour qu’une page Web, un programme .NET ou Python, un Arduino, un ESP8266, du nodeJS, un programme Bash ou Powershell, etc.. etc.. Puisse de façon transparente dialoguer avec le serveur Asterisk.

Sur l’AMI on peut par exemple initier un appel (le serveur appelle les deux correspondants et les mets en relation), transférer des appels, suivre tous les évènements (qui appel qui, qui raccroche, etc..).

Par exemple, lors d’une alarme la maison initie un appel sur mon compte utilisateur et celui de ma femme. Sans réponse elle utilise le trunk Orange pour appeler nos proches sur les GSM. Lorsque quelqu’un répond, Asterisk met l’interlocuteur avec une extension qui par exemple vient diffuser un message vocal avec le TTS de Google comme vu plus haut, ou comme dans mon cas, passe l’appel au package « My Brain » où réside l’IA de la maison qui ni plus ni moins qu’un AGI comme nous allons le découvrir ci-après.

L’AGI : Asterisk Gateway Interface
Cette interface permet d’ajouter des fonctionnalités dans Asterisk. Toutes les applications que vous utilisez pour faire du TTS, jouer un son, avoir un service de messagerie sont des AGI.

Ce qui est intéressant c’est qu’on peut exposer des AGI à distance. Par exemple :

exten => 200,1,agi(agi://monserveur/ia)
   same => n,Hangup()

Ici en composant le numéro 200 je suis mis en relation avec un AGI hébergé sur agi://monserveur/ia.

C’est ainsi que l’IA de la maison peut prendre un appel. Elle peut parler en utilisant l’AGI de Google ou les sons prédéfinies d’Asterisk, elle peut également écouter les touches DTMF saisies par l’utilisateur comme input.

On peut donc mettre à jour la gestion des appels entrants avec le plan suivant :

[incoming_orange]

exten => +33xxxxxxx,1,Log(NOTICE, Incoming call from ${CALLERID(num)})
   same => n,GotoIf($["${CALLERID(num)}" = "${GSM_SEB}"]?call_from_seb)
   same => n,Dial(SIP/sebastien, 15, txk)
   same => n,Dial(SIP/lili, 15, txk)
   same => n,Voicemail(${GLOBAL_VOICEMAIL}@chikawa)
   same => n,Hangup()

   same => n(call_from_seb),Answer
   same => n,agi(googletts.agi,"Bienvenue boss, je te mets en relation avec la maison",fr)
   same => n,agi(agi://monserveur/ia)
   same => n,Hangup()

; Acces distant a la messagerie vocale par appui de la touche * lors de l’annonce
exten => a,1,VoiceMailMain(${GLOBAL_VOICEMAIL}@chikawa)
   same => n,Hangup()

Avec en entête du fichier :

[globals]
GSM_SEB = 0612345678

On a juste rajouté un test (GotoIf) qui permet, si je suis l’appelant (mon n° GSM étant configuré dans les variables globales) de me mettre en relation directement avec le package Constellation qui expose l’AGI sur « monserveur » me permettant ensuite de gérer la « domotique » (au sens large).

Je reviendrais sur mon blog sur les interactions entre Constellation et Asterisk car il s’agit en soit d’un sujet à part entière. L’idée ici était juste d’attirer votre attention sur ce qui est possible de mettre en place une fois le serveur Asterisk déployé.
« Modifié: 13 janvier 2017 à 17:37:39 par seb59 »

seb59

  • Expert
  • Abonné Orange Fibre
  • *
  • Messages: 60
  • Wasquehal (59)
Annexe : connecter la LiveBox derrière un routeur
« Réponse #14 le: 13 janvier 2017 à 17:13:26 »
Annexe : connecter la LiveBox derrière un routeur

Pour ceux qui désire tout de même connecter leur Livebox derrière le routeur (un Mikrotik pour ma part) afin d’utiliser soit le Wifi, le proxy IGMP ou encore la base CAT-iq ou encore le port tel, voici la marche à suivre.

J’ai choisi l’interface « ether9 » que j’ai renommé « ether9-LB » pour connecter le port WAN de la LiveBox.

On commence par créer le VLAN « 832 » sur cette interface (car la LiveBox cherchera à se connecter sur internet par ce VLAN):
/interface vlan
add comment="Internet LiveBox" interface=ether9-LB loop-protect-disable-time=\
    0s loop-protect-send-interval=0s name=vlan832-livebox vlan-id=832

On assigne ensuite une IP fixe à votre routeur sur cette interface (192.168.100.254 pour ma part) :

/ip address
add address=192.168.100.254/24 comment="LAN Livebox" interface=\
    vlan832-livebox network=192.168.100.0

Puis on ajoute un serveur DHCP pour délivrer une IP à notre LiveBox avec notre routeur comme passerelle et les serveurs DNS d’Orange:

/ip pool
add name=pool-livebox ranges=192.168.100.1-192.168.100.10

/ip dhcp-server
add address-pool=pool-livebox authoritative=yes disabled=no interface=\
    vlan832-livebox lease-time=1w1d name=Livebox

/ip dhcp-server network
add address=192.168.100.0/24 dhcp-option=authsend,SIP dns-server=\
    81.253.149.1,80.10.246.130 gateway=192.168.100.254 netmask=24

Sans oublier d’ajouter les options DHCP suivantes pour que la LiveBox approuve la connexion :

/ip dhcp-server option
add code=90 name=authsend value=\
    0x0000000000000000000000646863706c697665626f786672323530
add code=120 name=SIP value="0x00067362637433670341554206616363657373116f72616\
    e67652d6d756c74696d65646961036e657400"

Enfin n’oubliez pas d’autoriser le trafic entre la LiveBox et le VLAN Internet :

add action=accept chain=forward comment="Forward Livebox to WAN" \
    in-interface=vlan832-livebox out-interface=vlan832-internet

Ainsi votre LiveBox fonctionnera comme si elle était connectée directement sur l’ONT. Il y aura juste votre routeur en amont pour le VLAN internet (832).

Vous pourrez ensuite connecter un téléphone sur le port « tel » ou en sans fil via CAT-iq, profiter du réseau Wifi de cette Livebox (en double NAT donc) ou encore connecter décodeur TV sur les ports LAN de la Livebox en créant un pont (bridge) pour « renvoyer » les VLANs 838 et 840 à la Livebox.
« Modifié: 13 janvier 2017 à 17:41:19 par seb59 »

JuJuBoSc

  • Abonné Orange Fibre
  • *
  • Messages: 9
  • Magny le Hongre (77)
Chapeau ! Je me suis régaler de tout lire !

Post it post it !

Slothy

  • Abonné Bbox fibre
  • *
  • Messages: 1 169
  • 2x FTTH 1 Gb/s sur Le Plessis-Trévise (94)
Magnifique. J'ai tout lu, on voit que tu sais de quoi tu parles. Je tourne également en partie sur du Mikrotik.

Une petite remarque cependant. Tu indiques la manière de marquer les requêtes en CoS 6 via une règle Mangle, mais il me semble que cela a été testé et ne fonctionne pas car il faut que le paquet soit marqué avant qu'il arrive au routeur. Vu que tu es dans une zone qui n'a pas besoin de la CoS, tu ne peux pas tester, c'est dommage. Il y a eu une discussion à propos de ça par ici : https://lafibre.info/remplacer-livebox/configuration-routeros-mikrotik-pour-livebox/276/

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 076
  • Paris (75)
Avec la fibre : mon nouveau réseau avec Orange/Sosh
« Réponse #17 le: 14 janvier 2017 à 22:37:00 »
oui l'info sur la QoS avec une règle n'est pas bonne et peut induire en erreur quelqu'un qui voudrait répliquer ta config sans trop s'y connaitre et aurait la malchance d’être dans une zone ou la QoS 6 est nécessaire: il risque d'investir et se retrouver bloquer...

Sous Linux (et donc RouterOS) , DHCP en IPv4 utilise des 'raw sockets' qui sortent directement du routeur sans passer par iptables et donc sans passer par la règle indiquée.

Reste la solution d'utiliser son switch (s'il peut faire cela) ou de modifier le client DHCP (chose peu probable sur un Mikrotik a moins qu'on puisse avoir un accès root pour changer des binaires -> a vérifier ?)

Sinon très bon guide merci de ta contribution.

seb59

  • Expert
  • Abonné Orange Fibre
  • *
  • Messages: 60
  • Wasquehal (59)
Bonjour à tous,

Tout d’abord merci pour vos retours positifs, ça fait toujours plaisir à lire :)

Slothy ta remarque ça m’a donné l’occasion de creuser un peu plus en détail cette histoire de CoS et j’ai une bonne nouvelle pour les processeurs d’un Mikrotik / RouterOS, pas besoin de bidouiller des binaires ou d’installer un switch en amont, vous pouvez bien changer la CoS de vos requêtes DHCP directement depuis RouterOS.

Comme à mon habitude, explication :)

Protocole de test
Tu indiques la manière de marquer les requêtes en CoS 6 via une règle Mangle, mais il me semble que cela a été testé et ne fonctionne pas car il faut que le paquet soit marqué avant qu'il arrive au routeur. Vu que tu es dans une zone qui n'a pas besoin de la CoS, tu ne peux pas tester, c'est dommage

En effet de chez moi, pas besoin de définir une CoS spécifique sur les requêtes DHCP pour obtenir une IP. Je ne peux donc « tester » directement.

La « CoS » pour « Class of service » va définir la priorité d’une trame Ethernet (couche 2). Cette notion a été introduite par ce que l’on appelle le « 802.1p » bien que ce ne soit pas un standard à part entière, cette notion est incorporée dans le standard 802.1D. L’idée du « 802.1p » étant d’implèmenter un mécanisme de « QoS » au niveau de la couche 2 (MAC).

Cependant la « CoS » bien que définie par le « 802.D » ne peut pas fonctionner sans les « VLAN » définis eux par un autre standard, le « 802.1Q », car cette information est stockée dans un champ nommé « PCP » (Priority code point) contenu dans l’entête d’une trame Ethernet au format 802.1Q au côté du « VID » (Vlan identifier).

En effet, une trame « taguée » (802.1Q) contient un surplus de 32 bits dans l’entête de la trame Ethernet pour contenir entre autre le numéro du VLAN (VID) mais aussi la priorité de la trame (PCP).
C’est donc seulement les trames Ethernet 802.1Q « taguées » qui peuvent contenir cette information, une trame Ethernet classique (802.3) ne peut pas contenir d’information quant à la priorité (on utilisera alors le ToS/DSCP au niveau 3, pour ajouter l’indice de priorité dans l’entête d’un paquet IP).

Le champ PCP occupe 3 bits (soit 8 valeurs possibles) ce qui permet de définir la priorité de la trame avec une valeur comprise entre 0 (priorité minimale) et 7 (priorité maximale).

Dans notre cas, les requêtes DHCP envoyées à Orange sont contenues dans des trames 802.1Q étant donné que l’on discute avec Orange en utilisant différents VLANs, celui qui nous intéresse ici étant le VLAN 832 pour Internet et doivent être marquées avec un CoS à « 6 » (classe Internetwork Control) soit une priorité très haute.

De ce fait même si je ne peux pas réellement tester le fonctionnement, on peut vérifier en analysant le trafic entre le routeur et Orange au moyen d’un « sniffer réseau » que les requêtes DHCP sont envoyées avec la bonne priorité.

Le but du jeu étant de voir partir nos requêtes DHCP avec le champ « PCP » (CoS) à 6.

Aussi pour votre information, j’ai réalisé toutes mes tests (et les captures d’écran ci-dessous) sur le VLAN 838 (celui de la VoD) dans lequel on s’identifie également en DHCP car je ne pouvais pas tester directement sur 832 afin d’éviter la pagaille sur mon réseau (pas mal de connexions actives vers Internet, je ne voulais pas tout chambouler lors de mes tests alors que des coupures du réseau VOD ne dérangera personne ;)).

Quoi qu’il en soit, le principe est le même, que l’on soit sur le VLAN 832 ou 838, l’idée étant de rajouter la CoS dans la trame Ethernet pour les requêtes DHCP.

Ne soyez donc pas surpris de voir le VLAN 838 dans les captures. Et aussi pour éviter la confusion, ce VLAN n’a absolument pas besoin d’une « CoS » particulière, je l’ai utilisé à des fins de test uniquement.

Sniffer le trafic réseau
Beaucoup d’entre vous ont l’habitude de ces opérations mais pour mettre tout le monde d’accord, notamment sur les possibilités propres à Mikrotik/RouterOS, voici quelques mots à ce sujet ….

Sniffer et streamer le trafic réseau depuis RouterOS
Dans mon post sur la partie TV, je vous parlais de « Torch » un outil intégré à RouterOS ultra-light permettant d’afficher le trafic réseau de façon macro (adresses dst/src, port, protocole, n° du vlan, …) avec la possibilité de mettre quelques filtres.
Pratique mais assez limité car on n’a pas possible d’analyser le contenu des paquets !

Un autre outil intégré à RouterOS que j’aime beaucoup est « Packet Sniffer. Il est plus complet avec la possibilité de visualiser les hosts, les connections, les paquets, etc... Mais ce qui est génial c’est le « Streaming » TZSP (TaZmen Sniffer Protocol).

En clair, le trafic capturé sur RouterOS peut être « streamé » sur une machine de votre choix :

/tool sniffer set streaming-enabled=yes streaming-server=<mon_ip>
/tool sniffer start

Sur votre machine, vous démarrez une capture Wireshark en filtrant tout ce qui arrive sur le port UDP 37008.
Vous obtiendrez alors les trames Ethernet du routeur à votre machine of course, et dans les paquets IP vous trouverez des enveloppes TZSP qui elles, contiennent le trafic de couche 2 capturé par le routeur (trames Ethernet, paquets IP, etc..).

Bon attention, dans les lignes ci-dessus il n’y a aucun filtre, donc vous allez capturer et streamer sur votre machine tout le trafic de votre routeur ! Il sera préférable de mettre en place des filtres pour le capturer et donc streamer que les trames qui vous intéresse (déjà définir la ou les interfaces à capturées, le protocole, port(s), etc…).

Par exemple ici on capture le trafic du VLAN838 attaché à l’ONT (vlan838-vod) pour les paquets UDP sur les ports 67 et 68 (DHCP) et on stream ce trafic vers « 10.2.4.114 » (mon IP) :


 
Sur mon PC j’ai lancé la capture Wireshark sur le port UDP 37008 et je vois bien apparaitre les requêtes DHCP sur le VLAN 838 de mon routeur (en rose, la trame Ethernet entre mon routeur et ma machine contenant l’enveloppe TZSP qui renferme la trame Ethernet de la requête DHCP capturée sur le VLAN 838 du routeur).


 
La trame ci-dessus est reçue quand je sniffe l’interface du VLAN directement or ce qui nous intéresse c’est de contrôler la « CoS » c’est-à-dire la priorité de la trame, information contenue dans les headers VLAN 802.1Q.
Autrement dit pour analyser l’entête 802.1Q liée au VLAN pour pouvoir connaitre la priorité associée et donc la CoS, il faut sniffer le trafic au niveau de l’interface Ethernet (« ether2-WAN » dans mon cas).

Seulement si je change les filtres sur « Packet Sniffer » en prenant tout le trafic sur « ether2 » (comme on le voit dans la capture ci-dessus), impossible de lire correctement les entêtes des trames Ethernet dans Wireshark :


 
De ce fait, impossible de lire l’entête 802.1Q et donc de connaitre la priorité (CoS) de la trame.

Je n’ai pas plus creusé que cela ! En résumé on arrive bien à récupérer via streaming TZSP les trames Ethernet classique (803.2) mais jamais celle au format VLAN (802.1Q).

Ainsi cette feature est parfaite pour une analyse rapide sans avoir besoin de se brancher en filaire (pratique sur un laptop en Wifi), mais sera réservée sur de petit volume de trafic car le streaming crée des pertes et de la latence, et pour des analyses au-dessus de la couche 2 (couche IP ou protocoles TCP/UDP). Autrement j’utilise le bon vieux « port mirroring » !

Sniffer le trafic réseau depuis un switch avec le « port mirroring »
En principe tous les switches manageable proposent cette fonctionnalité même sur l’entrée de gamme comme par exemple sur mon petit switch du salon, un SG108E (Easy Smart) de chez TP-Link (environ 30 euros).

Le principe est simple on indique au switch quels sont les ports pour lesquels on souhaite dupliquer le trafic reçu et/ou émis et quel est le port du switch sur lequel on va envoyer cette copie de trafic.

Dans mon cas, j’ai connecté mon laptop au réseau filaire avec une carte réseau USB, (Realtek USB Giga ethernet) et j’active le mirroring du trafic entrant et sortant du port « g1 » (celui où est connecté l’ONT Orange) sur le port où j’ai connecté mon laptop (ici en « g13 »).


 
Encore une fois nous ce que l’on veut, ce sont les informations propres aux VLANs ce qui est pas toujours possible en fonction de la carte réseau utilisée. Par chance, pas de soucis avec les Realteks d’après différentes sources d’information.

Il faudra cependant  « Désactiver » la propriété « Propriété & VLAN dans les options avancées de la carte réseau USB (car le driver Windows supprime les entête 802.1Q).


 
Maintenant nous pouvons lancer une capture avec Wireshark sur la carte réseau USB branchée sur le switch en « g13 » sur lequel nous avons une copie du trafic vers/de l’ONT Orange branché en « g1 ».

Vu mais pas pris : les règles « Mangle » sur le client DHCP
Quand j’ai écrit mon post où j’indiquais la règle Mangle pour marquer la CoS des requêtes DHCP, je n’ai pu réellement la valider car je n’ai pas besoin de cela pour avoir une réponse d’Orange.

Ceci dit pour moi elle marchait car le compteur de la règle s’incrèmentait bien !

Je fus donc étonné de lire la remarque de Slothy et surtout la réponse kgersen :

oui l'info sur la QoS avec une règle n'est pas bonne et peut induire en erreur quelqu'un qui voudrait répliquer ta config sans trop s'y connaitre et aurait la malchance d’être dans une zone ou la QoS 6 est nécessaire: il risque d'investir et se retrouver bloquer...
Sous Linux (et donc RouterOS) , DHCP en IPv4 utilise des 'raw sockets' qui sortent directement du routeur sans passer par iptables et donc sans passer par la règle indiquée.

C'est ce qui m’a donné envie de pousser l’analyser pour réellement comprendre car même si il est vrai que RouterOS est basé sur le noyau Linux, on n’a pas vraiment d’information sur ce qui a était réutilisé, réécrit ou modifié par Mikrotik. On ne sait pas vraiment si le code du client dhcp se base sur celui de linux ou même si le firewall se base sur iptable. On sait juste que ça tourne sur une base Linux après pour le reste, pas d’idée et ça ne m’étonnerai pas qu’ils aient réécrit tout à un tas de chose à leur sauce. Bon je sais que certain, pour ces raisons, prôneront l’open-source, mais là n’est pas le débat ;)

Pour en revenir aux faits, si on utilise cette fameuse règle comme indiqué dans mon  post :

add action=set-priority chain=output comment="CoS 6 for DHCP packets" \
    dst-port=67 src-port=68 new-priority=6 out-interface=vlan832-internet \
    passthrough=no protocol=udp

On peut constater qu'elle est bien exécutée sur chaque requête DHCP. J’ai ajouté l’option « Log » à cette règle et comme le montre la capture ci-dessous, on voit bien le compteur de la règle s’incrèmenter à chaque requête DHCP accompagné de logs :


 
Donc contrairement à l’explication généralement admise que l’on retrouve sur les forums et autres sites consistant à dire que n’ayant pas d’IP, le client DHCP ne peut invoquer la stack réseau du kernel, l’obligeant à ré-implèmenter le protocole UDP pour èmettre des requêtes DHCP avec utilisant ce que l’on appelle des « raw sockets » qui bypass complétement le firewall et autre règle mangle, n’est pas tout à fait vrai dans le cas du Mikrotik car force de constater que les règles sont bien invoquées.

Ceci dit dans l’analyseur réseau :


 
Cette règle est sensée changer la CoS (set-priority) de la trame or le champ reste à « 0 ». Elle n’a pas l’air de fonctionner bien qu’elle soit correctement exécutée à en croire le compteur et les logs produits.

J’ai fait plusieurs tests, c’est assez étrange mais en résumé tout ce qui ne modifie pas le paquet marche parfaitement, le compteur s’incrèmente, on peut loger, on peut « jumper » vers d’autres règles qui elles même s’incrèmentent, etc…

On peut même créer un règle « firewall » (et non Mangle) pour « dropper » le paquet par exemple. Le firewall fonctionne également très bien sur les paquets émis par le client DHCP. Dans ce cas aucune trace sur l’analyseur réseau et bien évidement pas de réponse d’Orange, le client DHCP restant en « Searching … » car notre firewall aura bloqué la trame en question.

Par contre, si je teste des actions qui modifient la requête, tel le « set priority », le « change TTL » ou encore le « Change DSCP » rien à faire, la trame reste tel qu’elle bien que le compteur s’incrèmente.

Donc en résumé les règles firewall/mangle fonctionnent bien même pour les requêtes DHCP produit par le client DHCP du routeur mais impossible de modifier les trames (priorité, DSCP ou TTL). En gros, ça marche en « read only » seulement : « Vu mais pas pris » :)

Modifier les trames avec un bridge
Ceci dit il y a une deuxième technique, qui elle fonctionne : utiliser un bridge !

Pour cela commencez par créer un bridge qu’on peut par exemple nommer « br-wan » :
/interface bridge
add name=br-wan

Dans ce bridge ajoutons l’interface du VLAN 832 sur lequel nous voulons modifier la CoS des trames DHCP :
/interface bridge port
add bridge=br-wan interface=vlan832-internet

Vous allez ensuite modifier votre client DHCP pour ne plus être directement lié à l’interface du VLAN832 mais au bridge qui lui-même est connecté sur ce VLAN :
/ip dhcp-client
add dhcp-options=authsend,clientid,hostname,userclass \
    disabled=no interface=br-wan

Enfin, le plus important, ajouter une règle de filtrage du bridge pour changer la priorité à « 6 » sur ce qui sort sur le VLAN832 à destination du port UDP 67 (requêtes DHCP) en ajoutant du log :
/interface bridge filter
add action=set-priority chain=output dst-port=67 ip-protocol=udp log=yes \
    log-prefix="Set CoS6 on DHCP request" mac-protocol=ip new-priority=6 \
    out-interface=vlan838-vod passthrough=yes


 
Comme pour la règle « Mangle », ce filtre est bien exécuté à chaque requête DHCP émise par le client DHCP du Mikrotik : le compteur s’incrèmente et des logs sont produits !

Sur l’analyse du trafic vers l’ONT on peut cette fois-ci constater que la priorité de nos trames est modifiée :


 
J’ai fait quelques tests en testant différentes priorités, chaque requête DHCP que l’on èmet part bien avec la priorité que vous lui aurez spécifiée dans votre filtre.

Ainsi vous pourrez bien utiliser votre Mikrotik/RouterOS sans bidouille ni switch supplèmentaire pour modifier la CoS de votre requête DHCP si cela est nécessaire. Du moins c’est ce que prouve l’expérience ci-dessus, à voir avec ceux qui sont dans une zone où ce marquage CoS est obligatoire pour valider cette procédure.

Ps : tests réalisés sous RouterOS 6.38, la dernière version « stable » à ce jour
« Modifié: 16 janvier 2017 à 11:59:52 par seb59 »

Slothy

  • Abonné Bbox fibre
  • *
  • Messages: 1 169
  • 2x FTTH 1 Gb/s sur Le Plessis-Trévise (94)
Tiens, aussi, envisages-tu de trouver comment récupérer l'IPv6 pour finir le bypass à 100% ? :)

djo

  • Abonné Bbox fibre
  • *
  • Messages: 93
  • Strasbourg 67
Super les indications.

Enfin un poste clair pour supprimer la Livebox.

seb59

  • Expert
  • Abonné Orange Fibre
  • *
  • Messages: 60
  • Wasquehal (59)
Tiens, aussi, envisages-tu de trouver comment récupérer l'IPv6 pour finir le bypass à 100% ? :)

Héhé, oui en effet, j'ai nommé ce thread "Guide complet" mais en fait il y a un grand absent : l'IPv6  :P

Malheureusement, il n'est pas encore possible d'utiliser les options DHCP avec le client v6 de RouterOS telles que décrit dans la RFC3315 section 22.
J'ai fais une "Feature Request" sur le forum de Mikrotik, çà arrive bien un jour :)
« Modifié: 16 janvier 2017 à 15:38:49 par seb59 »

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 076
  • Paris (75)
Pour la CoS 6 qui ne sort pas y' a peut-être une explication: le marquage '6' du mangle est interne a la stack tcp/ip du routeur. Il y a en principe un maping quelque part qui permet de "passer" le marquage interne dans le champ CoS d'un VLAN. Sous Linux ca se faisant anciennement avec la commande 'vconfig' et plus récemment avec la commande 'ip' (via 'ip link'). Il doit y avoir l’équivalent dans RouteurOS et c'est peut-être réglé a un 'mapping tout vers 0' dans ton cas, ce qui expliquerait ton "Vu mais pas pris" (la prio est bien mise a 6 en interne mais ne sort a pas a 6 car il n'y a pas de mapping "6 -> 6" mais un mapping "6 -> 0"). C'est a creuser en tout cas.

Pour le bridge ok mais on l’évitait sur l'ERL3 (et d'autres routeurs) car on perd l'accélération matérielle donc le débit max est pourri sur une ligne fibre (1 GBps). Si ton routeur fait tout en CPU et qu'un bridge logiciel tient le débit alors c'est une bonne solution.

Sinon, de ce que j'avais compris mais ca date, les raw sockets sortent directement mais ils sont aussi "clonés" et envoyer a netfilter. Ca expliquera que ton compteur augmente dans les logs mais que les paquets sortent sans CoS. Ce clonage est utile pour le statefull firewall par exemple, ca permet d'avoir une règle qui autorise du trafic en retour d'un paquet emis en raw. Il curieux toutefois que tu arrives a les bloquer dans le firewall. C'est peut-etre propre a l'archi de ton routeur ou de son client dhcp. Mais c'est curieux quand meme car RouterOS est bien basé sur un noyau Linux ils l'indiquent eux-même.

donc 2 explications pour le CoS 6 qui ne sort pas:
 - ca 'mangle' bien mais y'a pas le bon mapping prio interne -> prio externe (équivalent du vconfig)
 - c'est cloné et de toute facon pas marqué en sortie mais ca n'explique pas que tu puisses bloquer avec le fw le DHCP sortant...

« Modifié: 16 janvier 2017 à 21:19:35 par kgersen »

PacOrly

  • Abonné Free fibre
  • *
  • Messages: 1 231
  • FTTH 850/350 Orly (94)
Je vais avoir de la lecture pendant mes longues soirées d'hivers !!!