Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

[Asterisk] Les commandes utiles pour Asterisk

icon 24/06/2015 - 5 commentaires

En cas de problème sur Asterisk, il est pratique de connaître les commandes de base à utiliser pour établir un premier diagnostique.

Nous présentons ici les principales commandes utiles et les explications pour bien les comprendre.



Connexion à la console Asterisk

Nous partons du principe que le service Asterisk tourne en tâche de fond sur nos serveurs.

Pour se connecter à la console Asterisk, la commande est la suivante :
root@asterisk1:~# asterisk -rvvv

Une fois connecté à la console, pour connaître la liste des commandes disponibles il suffit de saisir « ? ».



Lister tous les comptes SIP

Pour lister toutes les entités SIP, c'est-à-dire tous les téléphones et les trunks SIP, la commande est la suivante :
asterisk*CLI> sip show peers

Cette commande précise notamment le username SIP, l'adresse IP associée, l'état de l'entité et le ping SIP.

Le résultat de la commande ressemble à ceci :
Name/username      Host              Dyn   Forcerport        Comedia           ACL         Port        Status            Description
1001/s             Unspecified       D     Yes               Yes                           11475       UNKNOW            
1002/s             192.168.11.1      D     Yes               No                A           1024        OK (29 ms)            
1003/s             192.168.11.2      D     Yes               No                            5060        OK (14 ms)            
3 sip peers [Monitored: 2 online, 1 offline Unmonitored: 0 online, 0 offline]

La lecture du résultat de la commande est la suivante :
  • Le poste « 1001 » n'est pas enregistré sur le serveur Asterisk :
  • Son adresse IP n'est pas connue : elle vaut « Unspecified »
  • Son état est à « UNKNOW »
  • Le poste « 1002 » est bien enregistré sur le serveur Asterisk :
  • Son état est à « OK »
  • Son adresse IP est 192.168.11.1
  • Sa latence SIP est de « 29ms »
  • Le poste « 1003 » est bien enregistré sur le serveur Asterisk :
  • Son état est à « OK »
  • Son adresse IP est 192.168.11.2
  • Sa latence SIP est de « 14ms »

La commande nous renseigne aussi sur le fait qu'il y a 3 comptes SIP de créés sur le serveur Asterisk, dont 2 qui sont connectés et 1 qui ne l'est pas.



Détailler les paramètres d'un compte SIP

La commande suivante permet de lister les paramètres détaillés d'un compte SIP :
asterisk*CLI> sip show peer 1001



Voir les communications en cours

Pour visualiser les communications en cours :
asterisk*CLI> core show channels

Le résultat de la commande ressemble à ceci :
Channel              Location   State   Application(Data)
SIP/1001-00009867  s@user:36  Up      Dial(SIP/1002,15,hHtT)
SIP/1002-00009876  (None)     Up      AppDial((Outgoing Line))
2 active channels
1 active call
4012 calls processed

La lecture du résultat est la suivante :
  • Les postes « 1001 » et « 1002 » sont en communication (l'un avec l'autre)
  • C'est le poste « 1001 » qui appelle l'autre poste (la dernière application lancée étant « Dial(SIP/1002,15,hHtT) » qui se traduit par « appeler le poste SIP 1002, laisser sonner 15 secondes avant de passer à l'étape suivante du dialplan s'il ne décroche pas »).
  • On observe qu'il y a 1 appel en cours (1001 vers 1002) et qu'il y a eu 4012 appels passés depuis que le service Asterisk est démarré.



Connaître le détail d'une communication en cours
Pour connaître le détail d'une communication en cours, la commande est la suivante :
asterisk*CLI> core show channel SIP/1001-00009867

Le résultat de cette commande est très verbeux. Plusieurs parties peuvent nous intéresser.
Les lignes suivantes nous renseigne sur le codec utilisé :
NativeFormats: (alaw)
WriteFormat: alaw
ReadFormat: alaw

Les variables CDR nous renseigne notamment sur la durée de l'appel (peut être très utile pour détecter les appels fantômes, c'est-à-dire mal raccrochés) :
level 1: start=2015-06-09 15:44:26
level 1: answer=2015-06-09 15:44:47
level 1: duration=774
level 1: billsec=753



Observer la perte de paquets sur une communication

La commande suivante est utile pour s'assurer qu'il n'y a pas de pertes de paquets RTP (c'est-à-dire de paquets audios) lors d'une communication :
asterisk*CLI> sip show channelstats

Le résultat est de la forme suivante :
Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
192.168.11.1     4d67bf4946f           0000002619  0000000000 ( 0.00%) 0.0000 0000002626  0000000000 ( 0.00%) 0.0001
192.168.11.2     3560b15a896  00:02:22 0000007095  0000000000 ( 0.00%) 0.0000 0000007096  0000000000 ( 0.00%) 0.0001
192.168.10.1     2f10b98f723  00:43:18 0000000129K 0000000001 ( 0.00%) 0.0000 0000000129K 0000000003 ( 0.00%) 0.0000
3 active SIP channels

La lecture du résultat est la suivante :
  • Il n'y a pas de perte de paquets sur ces appels concernant les peer SIP 1001 et 1002 (que ce soit pour les paquets reçus (Recv Pack Lost) comme pour les paquets émis (Send Pack Lost))
  • Le peer 1003 rencontre très peu de perte de paquets (quantité totalement négligeable)
  • La variation de la latence (Jitter) est faible : cela signifie que la qualité du lien réseau est stable.



Saisir les commandes Asterisk directement depuis le SHELL Linux

Il est à noter que l'ensemble des commandes présentées peuvent être saisies directement depuis un shell Linux de la manière suivante :
root@asterisk1:~# asterisk -rx 'ma commande Asterisk'

Cette possibilité s'avère particulièrement utile pour combiner le résultat d'une commande Asterisk avec d'autres commandes SHELL.
Par exemple, pour lister tous les postes SIP connectés depuis un site dont le sous-réseau est 192.168.11.x :

root@asterisk1:~# asterisk -rx 'sip show peers' | grep 192.168.11.

Exemple de résultat :
1002/s             192.168.11.1      D     Yes               No                A           1024        OK (29 ms)            
1003/s             192.168.11.2      D     Yes               No                            5060        OK (14 ms)  

Seuls les postes 1002 et 1003 ressortent.



Dans un prochain article, nous aborderons les clés de lecture nécessaires à l'analyse des fichiers de log Asterisk.



Pour aller plus loin

[Asterisk] Connaître son nombre d'appels simultanés


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

           

store.provya.fr

icon Tags de l'article :

[Asterisk] Connaître son nombre d'appels simultanés

icon 17/06/2015 - 2 commentaires

Il est utile de connaître le nombre d'appels simultanés transitant sur sa plateforme Asterisk.
Nous présentons dans cet article comment connaître son nombre d'appels simultanés en temps réel, ainsi que le nombre exact d'appels simultanés qu'il y a eu sur une plage de temps donnée.



Nombre d'appels simultanés en temps réel

Connaître son nombre d'appels simultanés en temps réel est très simple : Asterisk fournit directement une commande pour ça :

asterisk*CLI> core show channels

Le résultat de la commande ressemble à ceci :

Channel              Location   State   Application(Data)
SIP/1001-00009867  s@user:36  Up      Dial(SIP/1002,15,hHtT)
SIP/1002-00009876  (None)     Up      AppDial((Outgoing Line))
2 active channels
1 active calls
4012 calls processed

Cette commande permet de lister les appels en cours. Elle précise également le nombre d'appels passés depuis le démarrage du service Asterisk. Dans notre exemple, on y apprend qu'il y a un appel en cours (1 active calls).

Dans notre cas, l'information que nous cherchons à récupérer est simplement la valeur de la ligne "active calls". Pour cela, nous proposons de passer par un script SHELL :

root@asterisk1:~# asterisk -rx 'core show channels' | grep 'active calls' | cut -f 1 -d ' '

Dans le code ci-dessus, si l'on détaille chaque étape (séparée par un pipe), nous avons :

asterisk -rx 'core show channels'
Exécute la commande "core show channels" et retourne le résultat dans le SHELL

grep 'active calls'
Ne récupère que la ligne comportant la mention "active calls" (c'est uniquement elle qui nous intéresse).

cut -f 1 -d ' '
Permet de découper l'affichage en prenant les espaces comme marque de délimitation (option -d ' ') et de n'afficher que le premier segment (option -f 1).

Pour reprendre notre exemple, le résultat de la commande sera alors :

root@asterisk1:~# asterisk -rx 'core show channels' | grep 'active calls' | cut -f 1 -d ' '
1



Nombre d'appels simultanés sur une période donnée

Pour obtenir le nombre d'appels simultanés sur une période de temps donnée, nous proposons d'utiliser la ligne de commande fournie par Jean du forum asterifk-france.org.

La commande est la suivante :

awk 'BEGIN{FS=",\""} /ANSWERED/{split($11, a, "\""); split($12, b, "\"");printf ("%s,1\n%s,-1\n", a[1],b[1]); }' /var/log/asterisk/cdr-csv/Master.csv | sort | awk -F , '{cpt=cpt+$2; printf ("%s %03d\n", $1, cpt);}'

Cette commande filtre le contenu du fichier Master.csv sur chaque changement du nombre d'appels simultanés. Le résultat est affiché dans la console. Il est de la forme suivante :

2015-06-11 08:38:19 004
2015-06-11 08:38:30 005
2015-06-11 08:38:55 004
2015-06-11 08:39:10 003
2015-06-11 08:39:13 004
2015-06-11 08:39:42 003
2015-06-11 08:41:42 002
2015-06-11 08:42:35 001
2015-06-11 08:42:46 002
2015-06-11 08:43:50 001

Le premier champ indique la date, le second l'horaire auquel le changement du nombre d'appels simultanés a eu lieu et le troisième le nombre d'appels simultanés.


Limiter le résultat à un contexte

Si l'on souhaite, nous pouvons également limiter le résultat à un contexte en particulier. Exemple :

awk 'BEGIN{FS=",\""} /monContexte/*/ANSWERED/{split($11, a, "\""); split($12, b, "\"");printf ("%s,1\n%s,-1\n", a[1],b[1]); }' /var/log/asterisk/cdr-csv/Master.csv | sort | awk -F , '{cpt=cpt+$2; printf ("%s;%03d\n", $1, cpt);}'

Le décompte ne se fera alors que sur le nombre d'appels simultanés du contexte "monContexte".


Écrire le résultat dans un fichier pour l'exploiter

Plutôt que d'afficher les résultats à l'écran, nous les écrivons dans un fichier texte :

awk 'BEGIN{FS=",\""} /ANSWERED/{split($11, a, "\""); split($12, b, "\"");printf ("%s,1\n%s,-1\n", a[1],b[1]); }' /var/log/asterisk/cdr-csv/Master.csv | sort | awk -F , '{cpt=cpt+$2; printf ("%s %03d\n", $1, cpt);}' > monFichier.csv

Ce fichier peut ensuite être importé dans un tableur type LibreOffice ou Excel, en précisant que la séparation des champs se fait sur les espaces :

Dans LibreOffice :

Import CSV LibreOffice



Dans Excel :

Import CSV Excel



On peut ensuite faire des tris ou appliquer des filtres sur ces données !



Pour aller plus loin

[Asterisk] Les commandes utiles pour Asterisk


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

           

store.provya.fr

icon Tags de l'article :

[pfSense] Comprendre la priorisation de trafic

icon 05/06/2015 - 16 commentaires

Dans pfSense, il existe 3 principaux mécanismes de priorisation de flux :

- CBQ - Class Based Queueing
- PRIQ - Priority Queueing
- HFSC - Hierarchical Fair-Service Curve

PRIQ est un protocole de priorisation très simple (simpliste ?) mais nécessitant de faire très attention dans sa configuration.

CBQ est sans doute le protocole à utiliser dans la plupart des cas pour une entreprise souhaitant une gestion de la priorisation de trafic simple et efficace.

HFSC est sans conteste le protocole le plus évolué permettant un niveau de souplesse avancé, au prix d'une forte complexité...


Nous nous proposons ici de passer en revue ces différents mécanismes.
Dans un prochain article, nous verrons comment les mettre en œuvre dans pfSense.


CBQ - Class Based Queueing
CBQ est un algorithme permettant de diviser la bande passante d'une connexion en multiples queues ou classes.
Le trafic est assigné à l'une des queues, en fonction du protocole source/destination utilisé, du numéro de port, de l'adresse IP, etc.

Chaque queue se voit attribuer une bande passante et une priorité.

Les queues CBQ sont organisées de manière hiérarchique. Au sommet, nous retrouvons la queue "ROOT" (racine).
Chaque queue fille partage la bande passante de sa queue mère.

Il est également possible d'autoriser une queue à utiliser la bande passante de sa queue parente si celle-ci est sous-utilisée.


Exemple :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
	- Queue 2 (2Mbps)
	- Queue 3 (1Mbps)

La somme de la bande passante attribuée aux queues filles ne peut pas être supérieure à la bande passante totale de la queue mère.
Ainsi, dans notre exemple, la somme des bandes passantes des queues 1, 2 et 3 ne peut être supérieure à la bande passante de la queue Root.

Chaque queue fille peut elle-même avoir des queues filles :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Pour chacune de ces queues, on peut activer l'emprunt ("borrow") de bande passante à sa queue mère :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps - borrow)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Dans l'exemple ci-dessus, la queue VoIP dispose d'une bande passante de 1Mbps. Cependant, elle peut potentiellement utiliser jusqu'à 2Mbps (bande passante allouée à sa queue mère - Queue 1) si la queue SSH n'est pas pleine.

Une priorité est attachée à chaque queue. La priorité la plus forte sera préférée en cas de congestion. Si deux queues ont la même priorité, la distribution s'opère suivant un processus de type round-robin.

Root Queue (5Mbps)
	- Queue 1 (2Mbps, priorité 1)
		Queue VoIP (1Mbps - borrow, priorité 5)
		Queue SSH (1Mbps, priorité 3)
	- Queue 2 (2Mbps, priorité 1)
		Queue HTTP (800Kbps, priorité 1)
		Queue VNC (200Kbps, priorité 2)

Dans notre exemple ci-dessus, la queue 1 et la queue 2 ayant la même priorité, aucune des deux queues ne sera priorisée l'une par rapport à l'autre. Durant le temps où la queue 1 sera traitée, les queues filles seront traitées en même temps. La queue VoIP sera traitée en priorité par rapport à la queue SSH (en cas de congestion).
Il est à noter qu'uniquement les queue fille de la même queue mère sont comparées entre-elles (c'est-à-dire que la priorité de la queue VoIP sera comparée à la priorité de la queue SSH, mais ne sera pas comparée à la queue HTTP par exemple).


Davantage d'informations sur le protocole CBQ : CBQ sur openbsd.org - EN



PRIQ - Priority Queueing
PRIQ est un protocole permettant de définir plusieurs queues attachées à une interface et d'y affecter une priorité. Une queue avec une priorité supérieure sera toujours traitée avant une queue avec une priorité plus faible.
Si deux queues ont à la même priorité, la distribution se fera suivant le processus round-robin.

La construction des queues PRIQ est plate (il n'y a pas de notion de queue mère et de queue fille) - il n'est pas possible de définir une queue au sein d'une autre queue.

Une queue "ROOT" (racine) est définie, qui sera la bande passante totale de la connexion. Les autres queues sont définies sous la queue ROOT.

Exemple :

Root Queue (2Mbps)
	- Queue 1 (priorité 2)
	- Queue 2 (priorité 1)

La queue Root est définie comme disposant de 2Mbps. La queue 1 disposant de la plus forte priorité, l'ensemble de ses paquets seront traités en priorité. Tant qu'il existe des paquets dans la queue 1, la queue 2 ne sera pas traitée.
Dans chaque queue, les paquets sont traités dans l'ordre FIFO (First IN First OUT).

/!\ Attention : il est bien important de comprendre que dans le processus PRIQ, les paquets se trouvant dans les queues disposant de la priorité la plus élevée sont toujours traités avant les paquets des autres queues.
Ainsi, si une queue disposant d'une priorité élevée reçoit un flux de paquet continu, les queues disposant d'une priorité plus faible seront peu, voire pas traitées.


Davantage d'informations sur le protocole PRIQ : PRIQ sur openbsd.org - EN



H-FSC
HFSC est un algorithme évolué de traitement hiérarchique permettant de répartir la bande passante d'un lien et de contrôler l'allocation de ressources en fonction de la bande passante et de la latence.

Tout comme dans l'algorithme CBQ, les queues HFSC sont organisées de manière hiérarchique. Au sommet, nous retrouvons la queue "ROOT" (racine).
Chaque queue fille partage la bande passante de sa queue mère.

Chaque queue fille peut elle-même avoir des queues filles :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Une priorité est donnée à chaque queue. Les priorités vont de 0 (priorité la plus faible) à 7 (priorité la plus forte). Comme pour CBQ, ces priorités ne sont appliquées qu'en cas de saturation du lien.

Root Queue (5Mbps)
	- Queue 1 (2Mbps, priorité 1)
		Queue VoIP (1Mbps, priorité 5)
		Queue SSH (1Mbps, priorité 3)
	- Queue 2 (2Mbps, priorité 1)
		Queue HTTP (800Kbps, priorité 1)
		Queue VNC (200Kbps, priorité 2)

Qlimit
Chaque queue se voit attribuée en plus un paramètre "Qlimit". Qlimit correspond à un buffer (tampon) qui va se remplir lorsque la bande passante attribuée à la queue sera saturée : plutôt que de rejeter les nouveaux paquets arrivant, ceux-ci vont être mis en file d'attente dans ce buffer.

La valeur de Qlimit (la taille du buffer donc) est exprimée en nombre de paquets. Par défaut, sa valeur est de 50.

Un fois que le buffer définit par Qlimit est saturé, les nouveaux paquets sont supprimés (drop).

Il n'est pas nécessaire, et sûrement contre-productif, de définir une valeur trop grande pour Qlimit : cela ne solvera pas un problème de saturation de bande-passante. Une trop grande valeur peut entraîner un "buffer bloat".

Pour calculer la bonne valeur de Qlimit, il faut se demander combien de temps nous souhaitons garder un paquet dans le buffer.

Si le concept de MTU ou de latence ne vous est pas familier, lisez tout d'abord les liens cités précédemment.

Si l'on souhaite qu'un paquet reste bufferisé au maximum 0,5 seconde (ce qui est déjà long), le calcul à effectuer pour connaître la valeur de Qlimit est le suivant :

(BP / 8) / MTU = nb paquets/sec.
Avec :
BP : bande passante (en bits/s)
MTU : MTU du lien (en bytes)

Par exemple, si nous disposons d'un lien offrant 10Mbps en upstream ayant une MTU de 1500 bytes :

(10.000.000 / 8) / 1500 = 833 pq/sec

Soit, si l'on souhaite une bufferisation de 0,5 sec sur notre lien : 833x0,5 = 416 paquets (=valeur de notre Qlimit)

Si vous ne souhaitez pas vous lancer dans de tels calculs, laissez la valeur par défaut de Qlimit (50 paquets).


realtime
Ce paramètre permet de définir la bande-passante minimale garantit en permanence à la queue.


upperlimit
Le paramètre upperlimit permet de définir une limite haute de bande passante que la queue ne pourra jamais dépasser.
Cela permet, par exemple, de limiter l'usage fait de la bande passante pour un type de service ou d'utilisateurs.


linkshare
Ce paramètre remplit la même fonctionnalité que le paramètre "bandwith" définit plus haut. C'est-à-dire qu'il permet de définir la bande-passante disponible pour une queue ; cette bande-passante pouvant être empruntée à d'autres queues.

Aussi, si nous définissons le paramètre "bandwith" ET le paramètre "link share (m2)", c'est le paramètre "linkshare m2" qui sera pris en compte.


Ainsi, nous avons les paramètres suivants :
  1. realtime : bande-passante minimale garantie à une queue
  2. linkshare : bande-passante globale attribuée à la queue (utilisée une fois que realtime est plein)
  3. upperlimit : bande-passante maximale que la queue ne pourra jamais dépassée
  4. bandwith : redondant avec linkshare. Peut être utilisé si l'on ne souhaite pas utiliser le mécanisme NLSC.

Il est important de comprendre que le paramètre "linkshare" n'est utile que si l'on souhaite activer le mode NLSC (non linear service curve). Autrement, seul le paramètre "bandwith" peut être utilisé dans le paramétrage des queues.


NLSC
NLSC est un mécanisme permettant de définir une bande-passante initiale, puis après un certain temps, une bande-passante définitive.
Ainsi, on va pouvoir définir une bande-passante qui va évoluer dans le temps.

Il existe 3 paramètres pour la configuration de NLSC :
  1. m1 : bande passante initiale attribuée à la queue
  2. m2 : bande passante définitive attribuée à la queue
  3. d : durée (en ms) durant laquelle la bande passante attribuée à la queue est la bande passante initiale (m1), avant de devenir la bande passante définitive (m2)

NLSC est principalement utilisé dans le but d'offrir un maximum de bande-passante sur un certain laps de temps, puis de brider cette bande-passante. Ainsi, ce "bridage" n'impacte que les gros fichiers transitant dans la queue concernée.

NLSC est activable aussi bien sur les directives realtime, upperlimit et linkshare.
Si l'on ne souhaite pas faire évoluer la bande-passante dans le temps, seul le paramètre m2 doit être défini.


Options
Il existe plusieurs options que l'on peut définir sur nos queues. Actuellement, elles sont au nombre de quatre :
  1. Default queue : permet de définir la queue par défaut. Il ne peut y avoir qu'une seule queue par défaut par interface.
  2. Explicit Congestion Notification (ECN) : ECN permet d'envoyer une notification de congestion sur le réseau afin de limiter le "drop" de paquets. N'est utilisable qu'entre deux équipements le supportant.
  3. Random Early Detection (RED) : utilisé avec ECN, offre un mécanisme de détection de congestion (avant qu'elle n'ait lieu).
  4. Random Early Detection In and Out (RIO) : idem RED.

Nous ne recommandons pas l'usage des paramètres RED, RIO et ECN.

Une fois tous ces paramètres appliqués, si nous reprenons notre exemple de queues définit précédemment :

Root Queue (5Mbps)
	- Queue 1 (2Mbps, upperlimit: 3Mbps, realtime: 1Mbps)
		Queue VoIP (1Mbps, realtime: 1Mbps, qlimit: 500)
		Queue SSH (1Mbps, qlimit 500)
	- Queue 2 (2Mbps, upperlimit: 3Mbps, default)
		Queue HTTP (800Kbps, realtime: 500Kbps)
		Queue VNC (200Kbps, qlimit: 500)


Nous venons de passer en revu les 3 principaux mécanismes de priorisation de trafic proposés dans pfSense.

Dans un prochain article, nous verrons comment les configurer et les activer dans pfSense.



Pour aller plus loin

[pfSense] Configurer la priorisation de trafic avec CBQ
[pfSense] Utiliser les limiters pour contrôler la bande-passante par utilisateur


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous

Découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

           

store.provya.fr

icon Tags de l'article :

[pfSense] Configurer la priorisation de trafic avec CBQ

icon 04/02/2015 - 8 commentaires

pfSense offre plusieurs mécanismes de priorisation de trafic. Après notre premier article présentant le mode de fonctionnement des trois principaux mécanismes de priorisation ([pfSense] Comprendre la priorisation de trafic), nous procédons dans cet article à sa mise en application à l'aide du protocole CBQ.

Si nos besoins en règles de priorisation de trafic sont des besoins traditionnels, il est conseillé de travailler avec CBQ.

Nous ne détaillerons pas ici le mode de fonctionnement de CBQ, ni ses avantages ou inconvénients. Nous traiterons d'un cas pratique de mise en application sous pfSense et des bonnes pratiques à respecter.
Le mode de fonctionnement de CBQ est présenté dans notre article dédié : [pfSense] Comprendre la priorisation de trafic



Généralités sur la priorisation de trafic

Pour la mise en place de la priorisation de trafic, nous allons configurer d'un côté des queues (file d'attente) et de l'autre des rules (règles d'affectation des paquets dans ces files d'attente) :
  • Queues : "file d'attente" à laquelle est associée une priorité de traitement et une bande passante
  • Rules : "règle d'affectation" définissant la queue par laquelle un paquet va transiter. Ces règles sont les mêmes que pour la configuration du firewall : filtrage par port et adresse IP source, port et adresse IP de destination, protocole utilisé, etc.

La priorité de traitement la plus forte doit toujours être donnée aux applications nécessitant un traitement temps-réel. Typiquement, la VoIP.

La priorité suivante doit toujours être donnée aux acquittements TCP (ACK). Les ACK correspondent à des sortes d'accusé de réception sur les données transmises en TCP. Il est important que ces paquets soient prioritaires car autrement l'émetteur considérera que les paquets envoyés n'ont pas été correctement reçus et procédera à leur réémissions. Ce qui, par effet boule de neige, augmentera la charge sur la ligne Internet.

On considère que la bande passante nécessaire pour les ACK est de 10 à 15% du débit maximum offert en dowload (nous verrons en fin d'article comment affiner ce réglage).

Enfin, par convention de nommage, les queues commencent toujours par la lettre "q" (ex : qVoIP, qACK, qDefault, ...).
Pour le nommage des queues, et afin de facilité la lisibilité, nous recommandons l'utilisation du lowerCamelCase.



Cas d'application

Nous partirons du cas d'application suivant : une entreprise disposant d'une connexion Internet SDSL de 3Mbps sur laquelle transite sa téléphonie (VoIP) vers son opérateur SIP et le reste de sa data (surf, messagerie, etc.).

Le besoin est de prioriser sa téléphonie afin de garantir la qualité des communications et de disposer d'une répartition dynamique de sa bande passante.

Nous respecterons le principe KISS et mettrons en place les trois queues suivantes :
  • qVoIP : ce sera la queue réservée à la téléphonie
  • qACK : ce sera la queue réservée aux paquets ACK
  • qDefaut : la queue par défaut par laquelle nous ferons passer le reste du trafic

Il est important de démarrer avec un nombre de queues réduit et sur des règles d'affectation simples. Puis, de procéder à du fine-tuning si nécessaire.

La queue qVoip disposera de la priorité la plus forte et d'une bande passante de 1Mbps (ce qui correspond environ à 10 appels simultanés)
La queue qACK disposera de la priorité suivante et d'une bande passante de 10% du débit max en download, soit 300Kbps.
Enfin, la queue qDefaut disposera d'une priorité assez faible (et du reste de la bande passante) permettant l'ajout ultérieur de queues avec des priorités intermédiaires en cas de besoin.



Configuration des queues

Nous commençons par la configuration des queues sur l'interface WAN.

Se rendre dans le menu Firewall > Traffic Shaper :



Dans l'onglet « By Interface » (celui par défaut), cliquer sur « WAN » :



Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface WAN
  • Schedule Type : choisir "CBQ"
  • Bandwidth : indiquer le débit max en download diminué de 10% (soit 2700Kbps)
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • TBR Size : laisser vide

Cliquer sur le bouton "Save" pour valider la configuration

Exemple de résultat obtenu :



À noter : ne pas tenir compte pour le moment du message nous invitant à appliquer les changements. Nous le ferons lorsque nous aurons fini de configurer l'ensemble des queues.

Nous allons maintenant créer les queues. Pour cela, se repositionner sur l'interface "WAN" :



Puis cliquer sur le bouton "Add new queue".

Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la file d'attente
  • Queue Name : le nom de la file d'attente. Ici, ce sera "qVoIP"
  • Priority : on choisit "7"
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • Scheduler options : laisser vide
  • Description : une description optionnelle
  • Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "1Mbps"
  • Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

Cliquer sur le bouton "Save" pour valider la configuration

Exemple de résultat obtenu :



Notre première queue est créée. Pour la création de la suivante, nous nous repositionnons sur l'interface WAN (l'icône a pris la forme d'un dossier) :



Puis cliquer sur le bouton "Add new queue".

Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la file d'attente
  • Queue Name : le nom de la file d'attente. Ici, ce sera "qACK"
  • Priority : on choisit "6"
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • Scheduler options : laisser vide
  • Description : une description optionnelle
  • Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "300Kbps"
  • Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

Cliquer sur le bouton "Save" pour valider la configuration

Exemple de résultat obtenu :



Notre seconde queue est créée. Pour la création de la troisième et dernière queue (la queue par défaut), nous nous repositionnons sur l'interface WAN.
Puis nous cliquons sur le bouton "Add new queue".

Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la file d'attente
  • Queue Name : le nom de la file d'attente. Ici, ce sera "qDefaut"
  • Priority : on choisit "2"
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • Scheduler options : cocher la case "Default queue"
  • Description : une description optionnelle
  • Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "1400Kbps"
  • Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

Cliquer sur le bouton "Save" pour valider la configuration

Exemple de résultat obtenu :



L'ensemble de nos queues côté WAN est créé. Nous disposons de 3 queues :
  1. qVoIP : pour le trafic à destination ou en provenance du fournisseur SIP
  2. qACK : pour le trafic ACK (acquittement TCP)
  3. qDefaut : pour le reste du trafic

Nous allons maintenant activer la priorisation de trafic sur l'interface LAN. Cliquer sur "LAN" :

pfSense configuration du traffic shaper


Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface WAN
  • Schedule Type : choisir "CBQ"
  • Bandwidth : indiquer le débit max en upload diminué de 10% (soit 2700Kbps)
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • TBR Size : laisser vide

Cliquer sur le bouton "Save" pour valider la configuration

Exemple de résultat obtenu :

pfSense configuration traffic shaping LAN


Nous allons maintenant dupliquer les queues créées sur l'interface WAN vers l'interface LAN. Se rendre dans l'onglet "By Queue" :



Sélectionner la queue "qVoIP", puis, dans la section "LAN", choisir "Clone shaper/queue on this interface" :



Procéder de la même manière avec les queues "qACK" et "qDefaut".

Nos queues sont toutes créées :



Nous validons l'ensemble de ces paramétrages en cliquant sur le bouton "Apply Changes" :





Configuration des rules

Nous allons maintenant créer les règles d'affectation dans ces queues.
La configuration s'effectue au niveau des règles du Firewall. Elle peut s'effectuer directement depuis les règles existantes, ou en créant des règles génériques sur l'interface "Floating".

Les règles de vérification du Firewall s'opèrent dans l'ordre suivant :
  1. Règles définies en Floating
  2. Règles définies sur les groupes d'interfaces
  3. Règles définies sur les interfaces logiques

Pour un rappel sur le mode de fonctionnement des interfaces réseaux ou groupe d'interfaces sous pfSense, se référer à l'article dédié [pfSense] Comprendre la gestion des interfaces réseaux.

Dans notre cas, nous ne toucherons pas aux règles de filtrage en place sur nos interfaces ou groupe d'interfaces, mais nous créerons des règles spécifiques d'affectation des paquets IP depuis l'interface "Floating".
C'est ce que nous recommandons de faire systématiquement. Ainsi, nous ne mélangeons pas la partie "filtrage firewall" de la partie "règles de priorisation de trafic".

Pour cela, se rendre dans le menu "Firewall" > "Rules", puis sur l'onglet "Floating" :

Menu Firewall Rules pfSense


La méthode de création des règles de firewall depuis l'onglet "Floating" est exactement la même que pour n'importe quelle interface. La seule différence est la présence de l'action "Match".
L'action "Match" signifie qu'aucune décision ne sera prise quant à l'acceptation (Pass) ou au refus (Block ou Reject) du paquet, mais que s'il correspond (="match") aux critères définis (adresse IP source ou destination, port source ou destination, système d'exploitation, protocole, etc.), alors il se verra appliquer les options définies dans les "Advanced features" (comme les queues d'affectation ou la gateway, par exemple).

Si nous reprenons notre exemple, nous devons créer les règles suivantes :
  1. Une première règle pour diriger le trafic en provenance de l'opérateur de VoIP vers la queue "qVoIP"
  2. Une seconde règle pour diriger le trafic à destination de l'opérateur de VoIP vers la queue "qVoIP"
  3. Une dernière règle pour diriger tous les paquets ACK du trafic TCP vers la queue "qACK"

Nous créons notre première règle en cliquant sur l'icône en forme de "+" et renseignons les champs comme suit :
  • Action : nous choisissons "Match"
  • Interface : nous choisissons l'interface "WAN"
  • Direction : nous choisissons "in" (c'est-à-dire arrivant sur l'interface WAN)
  • Protocol : nous choisissons "UDP" (les protocoles de VoIP SIP et RTP utilisant UDP)
  • Source : nous choisissons "Single host or alias" et renseignons l'adresse IP du serveur VoIP de l'opérateur

Exemple de résultat obtenu :

config floating traffic shaping pfSense


Puis, dans la section "Advanced features", nous cliquons sur le bouton "Advanced" se trouvant sur la ligne "Ackqueue/Queue". La première liste déroulante correspond à la queue d'acquittement (paquets ACK), la seconde liste déroulante correspond à la queue.

On ne peut choisir une "Ackqueue" (première liste déroulante), que si on a choisi une queue (seconde liste déroulante).

Ici, nous choisissons la queue "qVoIP" et nous laissons l'Ackqueue à "none" (les protocoles de VoIP SIP et RTP utilisant UDP).

Exemple de résultat obtenu :

config floating QoS queue pfSense


Enfin, on clique sur "Save" pour valider la règle.
Voila notre première règle créée :

floating rules QoS pfSense


Nous créons une nouvelle règle en cliquant sur l'icône en forme de "+".

Renseigner les champs comme suit :
  • Action : nous choisissons "Match"
  • Interface : nous choisissons l'interface "WAN"
  • Direction : nous choisissons "out" (c'est-à-dire sortant par l'interface WAN)
  • Protocol : nous choisissons "UDP"
  • Destination : nous choisissons "Single host or alias" et renseignons l'adresse IP du serveur VoIP de l'opérateur
Dans la section "Advanced features", nous cliquons sur le bouton "Advanced" se trouvant sur la ligne "Ackqueue/Queue".
Nous laissons la première liste déroulante à "none", et choisissons "qVoIP" pour la seconde.

Exemple de résultat obtenu :

pfSense floating rules QoS


On clique sur "Save" pour valider la règle.

Nous créons la dernière règle en cliquant sur l'icône en forme de "+".

Renseigner les champs comme suit :
  • Action : nous choisissons "Match"
  • Interface : nous choisissons les interfaces "WAN" et LAN
  • Protocol : nous choisissons "TCP"
Dans la section "Advanced features", nous cliquons sur le bouton "Advanced" se trouvant sur la ligne "Ackqueue/Queue".
Nous choisissons "qACK" dans première liste déroulante à "none", et choisissons "qDefaut" dans la seconde.

On clique sur "Save" pour valider la règle.

Exemple de résultat obtenu :

pfSense floating rules QoS ACK


Nos trois règles d'affectation sont créées. Nous cliquons sur "Apply changes" pour valider la configuration.

pfSense floating rules exemple




Remise à zéro de la table d'état

Les règles de priorisation de trafic ne s'appliquent que sur les nouvelles connexions. Les connexions en cours (visibles dans la table d'état) ne sont pas impactées par les règles que nous venons de créer.
Aussi, pour que ces règles soient prises en compte totalement, il est nécessaire de vider la table d'état.

Pour cela, se rendre dans le menu "Diagnostics" > "States".
Cliquer sur l'onglet "Reset States", puis sur le bouton "Reset" :

pfSense reset firewall states


À noter : la page va charger sans fin. Ce comportement est normal : l'état de la connexion entre notre navigateur et le pfSense vient d'être réinitialisé.
Il suffit de rafraîchir la page pour continuer.



Analyse et Debug

Les statistiques d'utilisation des queues se trouvent dans le menu "Status" > "Queues" :

Status queues pfSense


Si l'on voit des "drops" de paquets (avant-dernière colonne du tableau) dans une des queues prioritaires (qVoIP ou qACK), cela signifie que la bande passante qui leur est allouée est trop faible et qu'il faut, a priori, l'augmenter.

En revanche, avoir du drops de paquets dans les queues disposant d'une priorité faible (qDefaut) est normal : en cas de saturation de la ligne Internet, ces queues ne sont pas prioritaires.


La priorisation de trafic est maintenant en place sur notre pfSense !



Pour aller plus loin

[pfSense] Comprendre la priorisation de trafic
[pfSense] Utiliser les limiters pour contrôler la bande-passante par utilisateur


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

           

store.provya.fr

icon Tags de l'article :

[pfSense] Comprendre la gestion des interfaces réseaux

icon 13/01/2015 - 6 commentaires

La gestion des interfaces réseaux sous pfSense peut être quelque peu déroutante pour un débutant. Nous présentons ici les rappels de base et les cas d'utilisation de chaque type d'interface.

Il existe 3 types d'interfaces sous pfSense :

  • interface physique : correspond aux interfaces physiques réelles du serveur sur lequel tourne pfSense. Ces interfaces sont généralement nommées re0, re1, etc.
  • interface virtuelle : ces interfaces sont automatiquement créées lors de la création d'un VLAN, d'un serveur OpenVPN, etc. Elles sont donc associées à un service.
  • interface logique : ce sont les interfaces que nous pouvons configurer (attribution d'adresse IP, règle de filtrage du firewall, etc.). Ces interfaces sont associées à une interface physique ou virtuelle.

Les deux premiers types d'interfaces (interface physique et interface virtuelle) sont appelés "ports réseaux".

Une interface logique doit être associée à un port réseau.

Un port réseau (c'est-à-dire une interface physique ou virtuelle) ne peut être associé qu'à une seule interface logique (c'est-à-dire configurable).



Interfaces physiques

Une interface physique correspond à une carte réseau du serveur pfSense.
Ces interfaces sont généralement nommées re0, re1, re2, etc. Elles sont identifiées par leur adresse MAC.

Lors de l'installation de pfSense, il est proposé de configurer les interfaces. Ce sont des interfaces logiques. Elles sont créées, configurées et associées aux interfaces physiques.
Ainsi, dans le cas d'un pfSense disposant de deux interfaces (une interface LAN et une interface WAN), on aurait eu l'association suivante :

WAN [interface logique] = re0 [port réseau]
LAN [interface logique] = re1 [port réseau]





Interfaces virtuelles

Ces interfaces sont créées lors de l'activation de certains services (VLAN, OpenVPN).

La configuration d'un serveur OpenVPN entraîne automatiquement la création d'une interface virtuelle associée à cette instance serveur OpenVPN (elle sera nommée ovpns1, ovpns2, etc.). Cette interface n'est pas configurable en l'état : ce n'est qu'un port réseau. Il est nécessaire de l'associer à une interface logique afin de pouvoir lui associer des règles de firewall ou de NAT spécifiques.

Exemple de résultat obtenu :



Dans la capture d'écran ci-dessus, on voit que l'interface logique "monVPN" est associée à l'interface virtuelle "ovpns1" qui a été créée lors de la configuration du serveur OpenVPN "serveur VPN Provya".

De la même façon, la création d'un VLAN entraîne la création d'une interface virtuelle (qui sera nommée VLAN1, VLAN2, etc.).
Cette interface virtuelle devra être associée à une interface logique afin de pouvoir lui associer des règles de firewall ou de NAT spécifiques.



Interfaces logiques

Les interfaces logiques sont les interfaces configurables. Ce sont ces interfaces que l'on va configurer : associer une adresse IP ; activer un serveur DHCP ; configurer des règles de firewall ou de NAT ; etc.

Ainsi, lors de la configuration d'un service (DHCP, OpenVPN, Portail Captif, etc.) les interfaces proposées seront toujours les interfaces logiques.

Les interfaces logiques les plus connues sont LAN et WAN.

Une interface logique est obligatoirement associée à un port réseau (c'est-à-dire à une interface physique ou virtuelle).



Groupe d'interfaces

Un groupe d'interfaces rassemble plusieurs interfaces logiques.
Ce groupe est donc un groupe logique auquel on peut appliquer des règles de firewall ou de NAT.

L'utilisation d'un groupe d'interfaces est utile si l'on dispose de plusieurs interfaces logiques sur lesquelles on souhaite appliquer exactement les mêmes règles.
Ainsi, les règles de firewall définies pour ce groupe s'appliqueront à toutes les interfaces du groupe.

La création de groupe d'interfaces se fait dans le menu Interfaces > (assign) :



Puis onglet "Interface Groups".
L'ajout se fait en cliquant sur l'icône en forme de "+".
On renseigne le nom du groupe d'interfaces, une description (facultative) et la liste des interfaces faisant partie du groupe :



Ce groupe d'interfaces sera visible dans les onglets du firewall :



Il est à noter qu'au niveau du firewall, ce sont les règles du groupe d'interfaces qui sont vérifiées, avant les règles de l'interface logique.



Cas particuliers : OpenVPN

Lors de la création d'une instance serveur ou client OpenVPN, hormis les interfaces virtuelles (ovpns1 ou ovpnc1), un groupe d'interfaces nommé "OpenVPN" est automatiquement créé.

Les configurations réalisées sur ce groupe "OpenVPN" s'appliquent à l'ensemble des services OpenVPN (c'est-à-dire tous les serveurs ou tous les clients OpenVPN configurés).

Si l'on souhaite une granularité de configuration par instance OpenVPN, alors on doit créer une interface logique pour chaque interface virtuelle OpenVPN existante.



Cas d'application

Lors de la configuration d'un service (DHCP, OpenVPN, Portail Captif, etc.) les interfaces proposées seront toujours les interfaces logiques.
Pour les services dont la configuration peut se faire pour plusieurs interfaces (une règle de firewall, par exemple), il sera également proposé les groupes d'interfaces.

Il existe deux cas particuliers à noter : la configuration des clients ou serveurs OpenVPN et IPsec.
Pour ces services, le choix de l'interface sera :
  1. les interfaces logiques
  2. les groupes de gateway
  3. les adresses VIP
  4. l'interface localhost
  5. toutes les interfaces logiques existantes (choix "any")
Les groupes d'interfaces ne seront pas proposés.


Nous voila maintenant armés pour bien comprendre et configurer correctement les services sur les bonnes interfaces réseau !


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

           

store.provya.fr

icon Tags de l'article :

[pfSense] La gestion des certificats pour les connexions OpenVPN

icon 30/12/2014 - 2 commentaires

Il existe plusieurs méthodes pour monter un tunnel VPN site-à-site avec OpenVPN. Les deux principales consistent en l'utilisation de clés partagées ou en l'utilisation de certificats (X.509).

Après notre premier article sur la configuration d'OpenVPN avec clé partagée, nous abordons ici sa configuration avec la gestion des certificats.

À noter : nous ne détaillons pas dans cet article tous les détails de configuration d'OpenVPN. Nous nous concentrons sur la création, l'utilisation et la révocation de certificat. Il existe déjà un article dédié à la configuration d'OpenVPN : [pfSense] Monter un accès OpenVPN site-à-site.



Principe de fonctionnement

Le client et le serveur OpenVPN sont authentifiés à l'aide de certificats. Pour cela, ces certificats doivent être émis par une autorité de certification reconnue comme sûre aussi bien par le serveur que par le client.

Dans notre cas, nous créerons une autorité de certification (appelée "CA" pour Certificate Authority) sur le pfSense faisant office de serveur. Puis nous créerons deux certificats : un certificat client (qui sera utilisé côté Client) et un certificat serveur (qui sera utilisé côté Serveur). Ces deux certificats seront signés par l'autorité de certification que nous aurons créé précédemment.

Pour signer un certificat, il est nécessaire de disposer de la clé privée de l'autorité de certification.
Pour valider la signature d'un certificat, il est nécessaire de disposer de la clé publique de l'autorité de certification.



Création d'une autorité de certification - CA

Actions à effectuer coté serveur OpenVPN

Pour commencer, nous nous rendons dans le menu System > Cert Manager :



Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône en forme de "+" se trouvant en bas à droite de la liste des CAs existants.

Les champs à renseigner sont les suivants :
  • Descriptive name : le nom que l'on souhaite donner à notre autorité de certification
  • Method : 3 méthodes sont possibles :
  1. Import an existing Certificate Authority : permet d'importer le certificat (clé publique + clé privée) d'une autorité de certification existante
  2. Create an internal Certificate Authority : permet de créer une nouvelle autorité de certification
  3. Create an intermediate Certificate Authority : permet de créer une autorité de certification intermédiaire. Cette autorité de certification intermédiaire doit être rattachée à une autorité de certification existante
Dans notre cas, côté serveur, nous créerons une nouvelle autorité de certification (Create an internal Certificate Authority). Côté client, nous importerons la clé publique de l'autorité de certification créée côté serveur (Import an existing Certificate Authority).
  • Key length : la longueur de la clé de chiffrement du certificat. Plus elle est longue, plus elle sera sécurisée (mais plus la charge CPU sera grande également...). Nous gardons la valeur par défaut : 2048
  • Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
  • Lifetime : la durée de vie de l'autorité de certification. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (10 ans)
  • Distinguished name : l'ensemble de ces champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation. Le seul élément important est le "Common name" dans lequel il ne doit pas y avoir d'espace (il est possible d'en mettre, mais cela peut poser des problèmes...)

Exemple de résultat obtenu :



Notre autorité de certification est créée.



Création d'un certificat serveur

Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Pour créer un nouveau certificat (client ou serveur), nous cliquons sur l'icône en forme de "+" se trouvant en bas à droite de la liste des certificats existants.

Les champs à renseigner sont les suivants :
  • Method : 3 méthodes sont possibles :
  1. Import an existing Certificate : permet d'importer la clé publique et la clé privée d'un certificat existant
  2. Create an internal Certificate : permet de créer une nouveau certificat
  3. Create a certificate Signing Request : permet de créer un fichier de requête qui pourra être envoyé à un CA tiers pour être signé. Cela peut être utile pour obtenir un certificat d'un CA root de confiance.
Dans notre cas, nous créons un nouveau certificat (Create an internal Certificate).
  • Descriptive name : le nom que l'on souhaite donner à notre certificat serveur
  • Certificate authority : l'autorité de certification qui signera le certificat que nous sommes en train de créer. Dans notre cas, nous choisissons le CA que nous venons de créer, soit "CA Provya"
  • Key length : la longueur de la clé de chiffrement du certificat. Plus elle est longue, plus elle sera sécurisée (mais plus la charge CPU sera grande également...). Nous gardons la valeur par défaut : 2048
  • Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
  • Certificate Type : le type de certificat. Il existe 3 valeurs possibles :
  1. User Certificate : pour définir un certificat pour un client
  2. Server Certificate : pour définir un certificat pour un serveur
  3. Authority Certificate : pour créer un CA intermédiaire
Dans notre cas, nous choisissons "Server Certificate".
  • Lifetime : la durée de vie du certificat. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (10 ans)
  • Distinguished name : l'ensemble de ces champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation émettrice du certificat. Par défaut, l'ensemble des champs sont pré-complétés avec les informations issues du CA. Le seul élément important est le "Common name" dans lequel il ne doit pas y avoir d'espace (il est possible d'en mettre, mais cela peut poser des problèmes...) et qui doit, autant que possible, rester unique

Exemple de résultat obtenu :



Notre certificat pour le serveur OpenVPN est créé.



Création d'un certificat client

Nous procédons exactement de la même manière que pour la création d'un certificat serveur. Le seul élément distinctif est le champ Certificate Type pour lequel nous choisissons "User Certificate".

Exemple de résultat obtenu :



Notre certificat pour le client OpenVPN est créé.



Configuration du serveur OpenVPN

Le détail de la configuration du serveur OpenVPN se trouve dans l'article dédié [pfSense] Monter un accès OpenVPN site-à-site.

Les différences au moment de la configuration sont les suivantes :
  • Server Mode : choisir "Peer to Peer (SSL/TLS)"
  • TLS Authentication : cocher la case "Enable authentication of TLS packets" pour davantage de sécurité. Nous ne conseillons pas de la cocher
  • Peer Certificate Authority : choisir l'autorité de certification créée précédemment ("CA Provya (ca-provya)")
  • Server Certificate : choisir le certificat serveur créé précédemment ("Certificat Serveur (certif-serveur-provya)")
  • DH Parameters Length : . Nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :





Export des certificats

La configuration coté serveur OpenVPN est terminée. Il reste à faire la configuration côté client.
Nous devons exporter le certificat de l'autorité de certification (c'est-à-dire sa clé publique), ainsi que le certificat et la clé privée du client OpenVPN.

Pour cela, nous retournons dans le menu System > Cert Manager :



Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône "Export CA cert" de l'autorité de certification que nous avons créée précédemment :




Puis, dans l'onglet "Certificates", nous cliquons successivement sur les icônes "export cert" et "export key" du certificat client que nous avons créé précédemment :



La configuration côté serveur OpenVPN est terminée.
Maintenant, nous procédons à l'import des clés publiques/privées et à la configuration côté client OpenVPN.



Import de la clé publique du CA sur le pfSense client OpenVPN

Actions à effectuer coté client OpenVPN

Nous nous rendons dans le menu System > Cert Manager :



Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône en forme de "+" se trouvant en bas à droite de la liste des CAs existants.

Nous allons importer la clé publique du CA que nous avons créé sur le serveur OpenVPN.
Les champs à remplir sont les suivants :
  • Descriptive name : le nom que l'on souhaite donner à notre autorité de certification. Nous gardons le même que celui qui a été donné sur le serveur OpenVPN ("CA Provya")
  • Method : on choisit "Import an existing Certificate Authority"
  • Certificate data : on copie dans ce champ le contenu de la clé publique (.crt)
  • Certificate Private Key (optional) : si l'on souhaite importer la clé privée (.key), elle est à copier dans ce champ. Dans notre cas, nous le laissons vide. En effet, nous ne souhaitons pas signer de nouveaux certificats (nécessite la clé privée de l'autorité de certification), nous souhaitons seulement valider la signature du certificat qu'utilise le serveur OpenVPN (nécessite la clé publique de l'autorité de certification)
  • Serial for next certificate : ce champ est à remplir uniquement si l'on importe une clé privée. Dans ce cas, il est important que chaque certificat créé par un CA dispose d'un numéro de série unique (autrement, nous risquons de rencontrer des problèmes en cas de révocation de certificat). Il faut donc choisir une valeur suffisamment grande (supérieure au nombre de certificat déjà créé par ce CA) afin d'éviter toute collision.

Exemple de résultat obtenu :





Import de la clé publique et de la clé privée du certificat client OpenVPN

Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Nous cliquons sur l'icône en forme de "+" se trouvant en bas à droite de la liste des certificats existants.

Nous allons importer la clé publique et la clé privée du certificat client que nous avons créé sur le pfSense serveur OpenVPN.
Les champs à remplir sont les suivants :
  • Method : on choisit "Import an existing Certificate"
  • Descriptive name : le nom que l'on souhaite donner à notre certificat. Nous gardons le même que celui qui a été donné sur le serveur OpenVPN ("Certificat Client")
  • Certificate data : on copie dans ce champ le contenu de la clé publique (.crt)
  • Private key data : on copie dans ce champ le contenu de la clé privée (.key)

Exemple de résultat obtenu :





Configuration du client OpenVPN

Le détail de la configuration du client OpenVPN se trouve dans l'article [pfSense] Monter un accès OpenVPN site-à-site.

Les différences au moment de la configuration sont les suivantes :
  • Server Mode : choisir "Peer to Peer (SSL/TLS)"
  • TLS Authentication : cocher la case "Enable authentication of TLS packets" pour davantage de sécurité. Nous ne conseillons pas de la cocher
  • Peer Certificate Authority : choisir l'autorité de certification importée précédemment ("CA Provya")
  • Client Certificate : choisir le certificat client importé précédemment ("Certificat Client")
  • DH Parameters Length : . Nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :





Révocation de certificat

Le dernier élément, pour être complet sur la gestion des certificats, est la liste de révocation de certificats ou "Certificate Revocation Lists" (CRLs).

Cette liste de révocation contient les certificats qui ne doivent plus être considérés comme sûrs (car ils ont été compromis ou pour n'importe quelle autre raison).
Pour les connexions OpenVPN, la CRL peut être utilisée par le serveur pour vérifier les certificats utilisés par les clients OpenVPN.

Une CRL est signée par un CA. Ainsi, pour générer une CRL, il est nécessaire de disposer de la clé privée du CA.

Généralement, une seule CRL est maintenue par CA. Cependant, pfSense peut en maintenir davantage.
Néanmoins, une seule CRL pourra être sélectionnée par instance OpenVPN.
Ce fonctionnement permet, par exemple, d'empêcher un certificat de se connecter à une instance OpenVPN, mais de l'autoriser à se connecter à une autre instance.

Une CRL peut être soit créée, soit importée. La configuration se fait dans le menu System > Cert Manager depuis l'onglet "Certificate Revocation" (troisième onglet).

Pour ajouter une nouvelle CRL, nous cliquons sur l'icône en forme de "+" correspondant au CA qui signera cette CRL ("CA Provya"). Les champs à renseigner sont les suivants :
  • Method : deux méthodes sont possibles :
  1. Create an internal Certificate Revocation List : permet de créer une nouvelle CRL (nécessite de disposer de la clé privée du CA)
  2. Import an existing Certificate Revocation List : permet d'importer une CRL générée depuis un serveur tiers (disposant de la clé privée du CA)
  • Descriptive name : le nom de notre CRL. On y inclut généralement une référence au nom du CA et/ou l'usage de cette CRL
  • Certificate Authority : le CA qui a ou va signé cette CRL
  • Lifetime : la durée de vie de la CRL (9999 jours par défaut)
  • Serial : le numéro de série de la CRL (0 par défaut)

Exemple de résultat obtenu :



Notre CRL est créée. On peut maintenant lui ajouter les certificats à révoquer. Pour cela, cliquer sur l'icône "Edit CRL" :



Il reste à choisir le certificat à révoquer, la raison de la révocation (ce champ est purement informatif) et cliquer sur le bouton "ADD".

Enfin, dans la configuration de notre serveur OpenVPN, nous devons ajouter cette CRL (champ "Peer Certificate Revocation List").



Pour aller plus loin

[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

           

store.provya.fr

icon Tags de l'article :

[Asterisk] Mettre à jour son serveur Asterisk

icon 04/12/2014 - Aucun commentaire

Il est important de maintenir à jour sa version d'Asterisk en production.
Si Asterisk a été installé depuis les dépôts d'une distribution, la mise à jour se fait via les mises à jour classiques de la distribution (apt-get update/upgrade ou équivalent).

En revanche, si Asterisk a été installé directement depuis les sources téléchargées sur le site asterisk.org, nous devons faire les mises à jour manuellement.

Nous détaillerons ici la procédure pour une mise à jour de version mineure au sein d'une branche (ex : mise à jour d'Asterisk 11.10.2 vers 11.14.1), mais pas la procédure pour une mise à jour vers une version majeure d'une branche à l'autre (ex : mise à jour d'Asterisk 11.10.2 vers 13.0.1).

Dans notre cas, nous prendrons l'exemple d'une mise à jour d'Asterisk 11.10.2 vers 11.14.1.



Les étapes de la mise à jour

Comme pour toute mise à jour, nous procédons en 3 étapes :
  1. Sauvegarde de la configuration : permettra un retour-arrière rapide en cas de problème
  2. Mise à jour du serveur Asterisk
  3. Sauvegarde de la configuration après la mise à jour : permet de bénéficier d'une sauvegarde à jour de la configuration en cas de panne ultérieure



Sauvegarder ses fichiers de configuration Asterisk

Les répertoires à sauvegarder sont les suivants :
  • /etc/asterisk : le répertoire de configuration d'Asterisk
  • /var/spool/asterisk/voicemail/ : le répertoire des messageries vocales d'Asterisk
  • /var/lib/asterisk/sounds/ : le répertoire contenant les fichiers sons

Si les CDR sont stockés sous forme de fichier csv, il faut aussi en faire une sauvegarde :
/var/log/asterisk/cdr-csv/ : répertoire contenant les CDR au format CSV

Si les CDR sont stockés en base de données, il faut faire un dump de la base.
Par exemple, dans notre cas, les CDR sont stockés dans une base MySQL nommée "asteriskcdr" et nous souhaitons faire une sauvegarde que nous stockons dans le fichier "/sauvegarde/asterisk.sql" :

mysqldump -u root -p -r/sauvegarde/asterisk.sql asteriskcdr

Toutes nos sauvegardes étant faites, nous pouvons maintenant mettre à jour sereinement notre version d'Asterisk.



Connaître la dernière version d'Asterisk
La liste des versions d'Asterisk à jour se trouve à l'URL suivante : http://www.asterisk.org/downloads/asterisk/all-asterisk-versions

D'une façon générale, la dernière version d'Asterisk d'une branche (dans notre cas, nous travaillons avec la 11) se trouve toujours à l'URL suivante :

http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-11-current.tar.gz => pour la 11
http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-13-current.tar.gz => pour la 13
...



Télécharger la dernière version d'Asterisk

On se place dans le dossier /usr/src :

cd /usr/src

On télécharge la dernière version :

wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-11-current.tar.gz

On décompresse :

tar -zxvf asterisk-11-current.tar.gz

Cela crée un nouveau dossier portant le numéro de la dernière version téléchargée (ex : asterisk-11.14.1).

On se déplace dans le dossier qui vient d'être créé :

cd asterisk-11.14.1



Mettre à jour sa version d'Asterisk

Les étapes sont les mêmes que pour l'installation d'une nouvelle version d'Asterisk :

./configure
make menuselect
make
make install

Nous ne détaillons pas ces étapes : ce sont exactement les mêmes que celles suivies lors de l'installation ; elles sont donc a fortiori déjà connues.


Il ne reste plus qu'à vérifier le bon fonctionnement de son service Asterisk ; par exemple, en se connectant à la console et en passant un appel !


Enfin, nous pensons à refaire une sauvegarde des fichiers de configuration d'Asterisk suite à la mise à jour.


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

           

store.provya.fr

icon Tags de l'article :

[pfSense] Mettre à jour son serveur pfSense

icon 09/10/2014 - Aucun commentaire

Il est important de conserver une version de pfSense à jour sur ses firewall en production.
Nous présentons ici la procédure que nous utilisons lors de la mise à jour d'un pfSense standalone ou d'un cluster de pfSense

Note : Les procédures détaillées ici concernent les mises à jour de versions mineures (ex : passage de la 2.1.4 vers la 2.1.5) et non les mises à jour majeures (ex : passage d'une version 1.2.x vers une version 2.1.x)


1. Procédure de mise à niveau pour un pfSense seul

Dans le cas d'un serveur pfSense fonctionnant de manière autonome, la mise à jour va s'effectuer en 3 étapes :
  1. Sauvegarde de la configuration : permettra un retour-arrière rapide en cas de problème
  2. Mise à jour du serveur pfSense
  3. Sauvegarde de la configuration après la mise à jour : permet de bénéficier d'une sauvegarde à jour de la configuration en cas de panne ultérieure

  • Sauvegarde de la configuration
Se rendre dans le menu Diagnostics > Backup/Restore :




Dans le champ "Backup configuration" > "Backup area" choisir "ALL", cocher la case "Do not backup RRD data", décocher les deux autres cases, puis cliquer sur "Download Configuration" :




  • Mise à jour du serveur pfSense
Se rendre sur le tableau de bord de pfSense (la page d'accueil accessible depuis "Status" > "Dashboard"). Cliquer sur "upgrade now" pour lancer la mise à jour.

Lors de la mise à jour, une coupure de service est à prévoir (redémarrage du serveur pfSense possible).

  • Sauvegarde de la configuration après la mise à jour
Faire une sauvegarde suivant la procédure décrite précédemment.

La mise à jour du serveur pfSense est terminée !



2. Procédure de mise à niveau d'un cluster de pfSense

Dans le cas de serveurs pfSense fonctionnant en redondance, la mise à jour va s'effectuer de la manière suivante :
  1. Faire une sauvegarde du pfSense secondaire
  2. Lancer la mise à jour du pfSense secondaire
  3. Une fois la mise à jour du pfSense secondaire complète, faire une sauvegarde du pfSense primaire
  4. Désactiver CARP sur le pfSense primaire => la VIP va basculer sur le pfSense secondaire
  5. Lancer la mise à jour du pfSense primaire

  • Sauvegarde de la configuration du pfSense secondaire
Se rendre dans le menu Diagnostics > Backup/Restore :




Dans le champ "Backup configuration" > "Backup area" choisir "ALL", cocher la case "Do not backup RRD data", décocher les deux autres cases, puis cliquer sur "Download Configuration" :



  • Mise à jour du serveur pfSense secondaire
Se rendre sur le tableau de bord de pfSense (la page d'accueil accessible depuis "Status" > "Dashboard"). Cliquer sur "upgrade now" pour lancer la mise à jour.

  • Sauvegarde de la configuration du pfSense primaire
Une fois la mise à jour terminée sur le pfSense secondaire, effectuer une sauvegarde du pfSense primaire en suivant la procédure détaillée à l'étape précédente.

  • Désactivation CARP du pfSense primaire
Avant de mettre à jour le pfSense primaire, basculer la VIP sur le pfSense secondaire afin de ne pas perturber le service.

Pour cela, se rendre dans dans Status > CARP (failover) :




Puis cliquer sur "Disable CARP" :



Les adresses VIP vont basculer sur le serveur pfSense secondaire.

  • Mise à jour du serveur pfSense primaire
Nous pouvons maintenant mettre à jour tranquillement le serveur primaire. La procédure est toujours la même que celle décrite aux étapes précédentes.


Une fois la mise à jour du serveur primaire terminée, la VIP va re-basculer d'elle-même sur le serveur pfSense primaire.

Il ne reste plus qu'à faire une sauvegarde du serveur pfSense primaire afin d'avoir une sauvegarde de la dernière configuration à jour.

La mise à jour du cluster de pfSense est terminée !


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

           

store.provya.fr

icon Tags de l'article :

Passer outre un filtrage réseau (firewall/proxy) grâce à un tunnel SSH

icon 24/09/2014 - Aucun commentaire

Il arrive parfois que l'on se connecte à Internet derrière une connexion non-sûre (wifi public), filtrant le contenu (proxy) ou très restrictive et n'autorisant guère plus que les ports 80 (http) et le 443 (https).

Dans ces cas-là, une solution s'impose pour pouvoir surfer en toute liberté : le tunnel SSH !

Nous allons voir comment monter un tunnel SSH vers un serveur accessible par Internet. Ce serveur nous servira de porte de sortie vers un Internet non-bridé.


Principe de fonctionnement
Le principe de fonctionnement est le suivant :
Schéma tunnel VPN


Nous ouvrons depuis notre ordinateur un tunnel SSH vers un serveur de confiance. Puis, nous redirigeons nos flux réseau vers ce tunnel SSH qui nous servira de passerelle de sortie.
Afin d'être le plus efficace possible, nous utiliserons un serveur disposant d'un port SSH en écoute sur le port 443.


Mettre en écoute son serveur SSH sur le port 443
Par défaut, un serveur SSH écoute sur le port TCP 22. Ce qui peut poser problème si l'on se trouve derrière une connexion Internet n'autorisant pas le trafic sur ce port.
Le port TCP 443 (HTTPS) étant très rarement filtré, nous allons faire écouter notre serveur SSH sur ce port.

Pour cela, nous modifions le fichier de configuration de notre serveur OpenSSH (pour Debian/Ubuntu) :

myserver# vim /etc/ssh/sshd_config

Nous recherchons les lignes suivantes :

# What ports, IPs and protocols we listen for
Port 22

Et nous y ajoutons la ligne indiquant à OpenSSH d'être en écoute sur le port 443 :

Port 443

Ce qui nous donne, une fois la modification saisie, les trois lignes suivantes :

# What ports, IPs and protocols we listen for
Port 22
Port 443

Enfin, nous effectuons un rechargement de la configuration du serveur SSH :

myserver# /etc/init.d/ssh reload

/!\ Attention /!\ : si nous avons également un serveur Apache qui tourne sur le même serveur, nous devons d'abord nous assurer qu'il n'est pas déjà en écoute sur le port 443.

D'une façon générale, pour vérifier simplement si un port TCP est en écoute sur un serveur, un petit coup de telnet suffit :

telnet mon-serveur-cible mon-port-cible

Ce qui, dans notre cas, donne :

telnet myserver.mydomain.tld 443

Si notre serveur est en écoute, nous obtiendrons un message du type :

Trying myserver.mydomain.tld...
Connected to myserver.mydomain.tld.
Escape character is '^]'.

Si notre serveur n'est pas en écoute, nous obtiendrons alors un message du type :

Trying myserver.mydomain.tld...
telnet: Unable to connect to remote host: Connection refused

À ce stade, nous disposons d'un serveur SSH en écoute sur le port TCP 443. Il ne nous reste plus qu'à monter notre tunnel !


Monter le tunnel SSH - Solution Windows
Nous commençons par télécharger Putty.

Nous lançons le logiciel, puis, dans l'onglet session, nous renseignons les champs "Host name" et "Port" correspondant à notre serveur SSH :



Ensuite, nous nous rendons dans l'onglet SSH > Connection > Tunnels.
Dans le champ "Source port", nous saisissons 1234, et nous choisissons les options "Dynamic" et "Auto", puis nous cliquons sur le bouton "Add" :



Il nous reste à cliquer sur "Open", ce qui lance une connexion classique sur notre serveur distant.

Si vous êtes derrière un proxy
Si nous nous trouvons derrière un proxy (en entreprise, par exemple), il nous faut renseigner les informations du proxy au niveau des paramètres de Putty. Ça se passe dans Connection > Proxy.

Il reste à choisir le type de proxy (généralement HTTP), renseigner l'URL du proxy et le port d'écoute (souvent le 8080).

Si un username & password sont nécessaires pour l'accès au proxy, nous renseignons ces éléments sur cette même page :



Notre tunnel SSH est prêt. Il nous reste à rediriger nos flux vers ce tunnel.


Monter le tunnel SSH - Solution Linux
Sous GNU/Linux, la mise en place du tunnel se résume en une seule ligne de commande :

ssh -D port-local nomutilisateur@nomhôte -p port-distant

Soit, par exemple :
ssh -D 1234 root@myserver.mydomain.tld -p 443

Notre tunnel SSH est prêt.
Et pour éviter les timeout, nous pouvons ajouter une option de keep alive (option "ServerAliveInterval" avec sa valeur à préciser en seconde) :
ssh -o ServerAliveInterval=2 -D 1234 root@myserver.mydomain.tld -p 443

Il nous reste à rediriger nos flux vers ce tunnel.


Rediriger ses flux réseaux à travers le tunnel VPN
Notre tunnel SSH est monté. Nous souhaitons dorénavant l'utiliser pour rediriger nos flux à travers ce tunnel.
Pour cela, nous utiliserons ce tunnel SSH comme un proxy. C'est d'ailleurs la raison pour laquelle nous avons configuré un port d'écoute local (le port 1234).

Ainsi, pour utiliser ce proxy, nous devons configurer nos logiciels avec les informations suivantes :

- adresse du serveur proxy : localhost (ou 127.0.0.1)
- port du serveur proxy : 1234

Exemple pour Firefox :

Se rendre dans Édition > Préférences > Avancé > Réseau (ou Outils > Options > Avancé > Réseau)
Cliquer sur le bouton "Paramètres...", puis choisir "Configuration manuelle du proxy" et renseigner les paramètres comme suit :
Type : SOCKS5
URL : 127.0.0.1
Port : 1234



Voilà !


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

           

store.provya.fr

icon Tags de l'article :

[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN

icon 11/09/2014 - 7 commentaires

Un cas fréquent lorsque l'on souhaite connecter deux sites en VPN est que ces deux sites soient sur le même plan d'adressage. Dans ce cas, une bonne solution peut être de recourir au NAT pour la mise en place d'un VPN natté.

Par exemple, si l'on souhaite connecter deux réseaux utilisant le subnet 192.168.1.0/24, ceux-ci ne pourront pas communiquer l'un vers l'autre à travers le VPN car le subnet du réseau distant est le même que celui du réseau local.

Afin d'y remédier, on propose d'utiliser le NAT pour communiquer d'un réseau à l'autre. C'est le principe du VPN natté (overlap network).

À noter : nous ne détaillons pas dans cet article comment configurer OpenVPN. Il existe déjà un article dédié sur le sujet : [pfSense] Monter un accès OpenVPN site-à-site.


Principe de fonctionnement
Pour chaque subnet commun sur les sites distants, nous utiliserons un nouveau subnet disponible associé à du 1:1 NAT.

Nous allons prendre l'exemple de deux sites (A et B) disposant tous deux du même plan d'adressage 192.168.1.0/24 :

Schéma réseau


Afin de pouvoir relier ces deux sites en VPN, nous allons translater l'intégralité du plan d'adressage réseau du site B afin qu'il soit joignable depuis le site A à travers le VPN. Et nous ferons de même du plan d'adressage réseau du site A afin qu'il soit joignable depuis le site B à travers le VPN.

Le trafic à destination du site A sera translaté en 172.16.1.0/24.
Le trafic à destination du site B sera lui translaté en 172.17.1.0/24.

Une entrée 1:1 NAT sera ajoutée pour chaque subnet pour translater l'intégralité du /24.
Ainsi, pour joindre le site A depuis le site B, on utilisera une adresse IP du type 172.16.1.x et pour joindre le site B depuis le site A, on utilisera une adresse IP du type 172.17.1.x.

Grâce au 1:1 NAT, on conservera le dernier octet de l'adresse réseau de chaque site. C'est-à-dire que pour joindre l'adresse IP 192.168.1.10 du site A, depuis le site B on utilisera l'adresse IP 172.16.1.10. Et pour joindre l'adresse IP 192.168.1.50 du site B, depuis le site A on utilisera l'adresse IP 172.17.1.50.


Configuration du VPN natté
Sur le serveur pfSense du site A, nous créons une nouvelle règle 1:1 NAT (Firewall > NAT) que nous configurons comme suit :

Configuration 1:1 NAT


Dans le champ External subnet IP, nous indiquons l'adresse réseau du subnet natté soit 172.16.1.0.


Nous procédons de la même manière sur le serveur pfSense du site B ; nous créons une nouvelle règle 1:1 NAT (Firewall > NAT) que nous configurons comme suit :

Configuration 1:1 NAT


Dans le champ External subnet IP, nous indiquons l'adresse réseau du subnet natté soit 172.17.1.0.


Enfin, dans la configuration du client et du serveur OpenVPN, le champ "Remote Network" doit correspondre aux plages d'adresses IP nattées. Soit, sur le pfSense du site A, le champ "Remote Network" est renseigné à "172.17.1.0/24" et sur le site pfSense du site B, le champ "Remote Network" est renseigné à "172.16.1.0/24".

Pour davantage d'information sur la configuration OpenVPN sur pfSense, voir l'article dédié sur le sujet : [pfSense] Monter un accès OpenVPN site-à-site.

Le VPN natté est en place !



Pour aller plus loin

[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] La gestion des certificats pour les connexions OpenVPN


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

           

store.provya.fr

icon Tags de l'article :