Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

[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

Nouveau : 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.

Nouveau : 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.

Nouveau : 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.

Nouveau : 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.

Nouveau : 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.

Nouveau : 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.

Nouveau : 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.

Nouveau : découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

   

store.provya.fr

icon Tags de l'article :

[pfSense] Configurer son serveur DHCP

icon 04/09/2014 - 1 commentaire

pfSense peut être utilisé comme serveur DHCP ou relai DHCP.

Nous allons configurer ici pfSense en tant que serveur DHCP pour des adresses IPv4. Nous nous en servirons également pour de l'auto-provisioning de téléphones IP.


Activer le service DHCP

Pour commencer, se rendre dans "Services" > "DHCP Server" :



On commence par choisir l'interface sur laquelle nous souhaitons activer le serveur DHCP. Dans notre cas, ce sera "LAN".

Pour commencer, nous cochons évidemment la case "Enable DHCP server on LAN interface".


Configuration du serveur DHCP

L'interface de configuration suivante est proposée :

  • Deny unknown clients : cette option permet de filtrer les requêtes DHCP.
Par défaut (option non-cochée), pfSense attribue une adresse IP à n'importe quel terminal connecté sur le réseau qui fait une demande d'adresse IP. C'est, à priori, le mode souhaité dans la plupart des cas. Cependant, il est possible, dans des environnements plus restrictifs, de n'autoriser la distribution d'adresses IP qu'aux terminaux connus (c'est-à-dire dont l'adresse MAC a été renseignée dans pfSense) ; dans ce cas, cette case doit être cochée. Il est à noter que cette option se définit par plage d'adresses.

  • Subnet : cette ligne rappelle l'adresse du réseau.

  • Subnet mask : cette ligne rappelle le masque de sous-réseau.

  • Available range : cette ligne donne la plage maximale sur laquelle des adresses IP peuvent être attribuées. Cette information est bien pratique pour les réseaux n'étant pas en /24.

  • Range : permet de définir la plage d'adresses IP qui sera utilisée.
Par défaut, pfSense propose la plage d'adresse allant de 100 à 199 (soit, par exemple, 192.168.1.100 à 192.168.1.199). Nous sommes libres de la modifier dans la limite de la taille maximale rappelée à la ligne précédente (available range).
Si nous souhaitons définir plusieurs plages d'adresses IP différentes (soit pour filtrer les terminaux connus des terminaux inconnus, soit pour d'autres raisons liées à notre architecture réseau), il est possible de définir plusieurs plages d'adresses IP (ligne Additional Pools).

Pour ajouter une seconde plage d'adresses IP, cliquer sur le "+" correspondant. Cela aura pour effet d'ouvrir une nouvelle fenêtre permettant de définir l'ensemble des paramètres propres à cette plage d'adresses IP.

Évidemment, cette option n'est utile que si nous disposons d'un serveur WINS sur notre réseau. Les serveurs WINS n'ont pas forcément besoin d'être sur le même subnet (dans ce cas, il faut veiller à bien configurer les règles de routage et de filtrage au niveau du firewall).
Dans le cas où nous n'utilisons pas de serveur WINS (ce qui doit être le cas de la quasi-totalité des réseaux modernes), nous laissons ces champs vides.

  • DNS servers : ce champ peut être renseigné ou resté vide. Si l'on souhaite passer au client la même configuration DNS que celle configurée dans pfSense, alors il faut laisser ces champs vides. En revanche, si l'on souhaite passer au client d'autres serveurs DNS que ceux configurés dans pfSense, il faut les renseigner ici.
Pour les réseaux locaux avec des terminaux Windows et un serveur Active Directory, il est conseillé d'indiquer l'adresse du serveur Active Directory.

  • Gateway : si pfSense est la passerelle pour ce réseau, ce champ peut être laissé vide. Dans le cas contraire, nous indiquons ici l'adresse IP de la passerelle.

  • Domain name : permet d'indiquer aux clients le nom de domaine correspondant au réseau et donc qu'ils devront utiliser pour former leur FQDN. Si rien n'est indiqué, c'est le nom de domaine de pfSense qui sera passé aux clients.

  • Domain search list : cette information est utile dans le cas où l'on dispose de plusieurs domaines.
Lors d'une recherche sur un nom d'hôte sur le réseau, le client concaténera le nom d'hôte au nom de domaine. Chaque domaine doit être séparé par une virgule. Cette information est passée au client via l'option DHCP 19. Donc, dans le cas où il n'y a qu'un seul domaine local, ce champ doit être laissé vide (lorsque qu'un client fera une recherche sur un nom d'hôte, la concaténation se fera avec le nom de domaine défini à la ligne précédente).

  • Default lease time et Maximum lease time : ces deux options permettent de contrôler la durée des baux DHCP.
Default lease time est utilisée quand un client ne demande pas de durée spécifique d'enregistrement pour son bail. Si le client demande une durée de bail qui est supérieure à Maximum lease time, la durée de bail donnée sera celle définie dans Maximum lease time. Ces valeurs sont définies en secondes.
Si les champs sont laissés vides, les valeurs par défaut sont de 7.200 secondes (2h) pour la durée de bail par défaut et 86.400 secondes (1 jour) pour la durée de bail max.

  • Failover peer IP : si vous possédez deux serveurs pfSense configurés en failover, renseignez ici l'adresse IP physique (pas l'adresse virtuelle) du second serveur pfSense. Autrement, laissez ce champ vide.

  • Static ARP : cette option est l'exact opposé de "Deny unknow clients" : elle permet de lister les machines capables de communiquer avec pfSense sur le réseau. Ainsi, tous les terminaux n'étant pas référencés (c'est-à-dire dont l'adresse MAC est connue et référencée dans pfSense) ne pourront pas communiquer avec pfSense. Il faut faire très attention lorsque l'on manipule cette option ! De plus, lorsqu'elle est cochée, cette option reste active même si le service DHCP est arrêté.

  • Time format change : par défaut, les durées de baux DHCP sont affichées au format UTC. En cochant cette option, elles sont formatées au fuseau horaire local. C'est une option d'affichage purement esthétique.

  • Dynamic DNS : cette option permet de définir un serveur DNS dynamique (à saisir dans le champ correspondant). Dans le cas où pfSense est configuré en mode "DNS forwarder", cette option ne devrait pas être cochée, et le DNS forwarder devrait être configuré en conséquence. Il est à noter que cette option ne fonctionne qu'à partir de la version 2.1 de pfSense.

  • MAC Address Control : cette option permet de filtrer les accès au serveur DHCP par adresses MAC.
Le premier champ permet de définir les adresses MAC autorisées. Le second champ, les adresses MAC interdites. Ces adresses MAC peuvent être saisies partiellement (par exemple, saisir 01:E5:FF autorisera ou interdira, suivant le champ dans lequel elle aura été saisie, toutes les adresses MAC commençant par cette séquence).
Les adresses MAC (ou adresses MAC partielles) doivent être séparées par une virgule, sans espace. Ces champs peuvent être laissés vides si l'on ne souhaite pas appliquer de contrôle sur les adresses MAC des terminaux.

Il est important de comprendre qu'à partir du moment où une adresse MAC (ou adresse MAC partielle) est saisie dans le champ des adresses autorisées, toutes les autres adresses MAC seront interdites d'accès ; et inversement, si l'on saisi une ou des adresses MAC dans le champ des adresses interdites, toutes les autres adresses MAC seront autorisées.

Un exemple d'utilisation de cette fonctionnalité est la séparation des téléphones IP et des ordinateurs sur un même réseau. En admettant que tous les téléphones IP disposent d'une adresses MAC commençant par aa:bb:cc, alors sur la plage d'adresses réservées aux ordinateurs, nous interdirons les adresses MAC commençant par aa:bb:cc (en saisissant cette séquence dans le champ des adresses interdites) ; et sur la plage d'adresse réservées à la VoIP, nous autoriserons uniquement les adresses MAC commençant par aa:bb:cc (en saisissant cette séquence dans le champ des adresses autorisées).


  • TFTP server : permet de saisir l'adresse IP ou le nom d'hôte d'un serveur TFTP. Cette option est principalement utilisée pour l'auto-provisioning pour la téléphonie sur IP. Elle correspond à l'option DHCP 66.

  • LDAP URI : permet d'envoyer l'URI d'un serveur LDAP aux clients en faisant la demande. Cela correspond à l'option DHCP 95. Le format saisi doit être celui d'une URI LDAP tel que ldap://ldap.example.com/dc=example,dc=com.

  • Enable network booting : pour activer cette fonctionnalité, il faut cocher la case correspondante (Enables network booting), saisir l'adresse IP du serveur ainsi que le nom du fichier d'image disque bootable. L'ensemble de ces champs doit être complété pour que cette option fonctionne correctement.

  • Additional BOOTP/DHCP Options : permet de pousser n'importe quelle option DHCP (dont nous détaillons le paramétrage au paragraphe suivant).

Une fois l'ensemble des configurations effectué, il ne reste plus qu'à cliquer sur Save !


Les options avancées du serveurs DHCP

L'une des grandes forces du serveur DHCP de pfSense est qu'il offre une interface de configuration simple pour la plupart des fonctionnalités DHCP. Mais il permet également de délivrer l'intégralité des options DHCP. La liste des options DHCP possibles est disponible sur le site de l'IANA.

Plusieurs formats sont disponibles pour ces options DHCP. Les noms de ces formats pouvant être peu intuitifs, nous les détaillons ici :

Text : texte libre de forme.
String : une suite de chiffres hexadécimaux séparés par le caractère deux-points ":" (ex : 00:a8:c9)
Boolean : la valeur true ou la valeur false
Unsigned 8, 16, or 32-bit Integer : un nombre entier positif (supérieur à zéro), jusqu'à 86400
Signed 8, 16, or 32-bit Integer : un nombre entier positif ou négatif, jusqu'à -512
IP address or host : une adresse IP (ex : 192.168.1.2) ou un nom d'hôte (ex : www.example.com)


Exemple de configuration avancée : serveur DHCP pour ordinateurs et téléphones IP

Nous prenons l'exemple d'un réseau en 192.168.2.0/24, d'un serveur pfSense en 192.168.2.1, d'un serveur téléphonique Asterisk en 192.168.2.2 et de 20 postes informatiques et autant de téléphones IP.

Dans notre exemple, les téléphones IP ont tous une adresse MAC commençant par la séquences AA:BB:CC.

Nous souhaitons attribuer des adresses IP de 192.168.2.150 à 192.168.2.250 aux téléphones IP ; et des adresses IP de 192.168.2.10 à 192.168.2.99 aux autres terminaux (ordinateurs, imprimantes, etc.).


Le schéma de notre réseau est donc le suivant :

Schéma réseau


Nous configurons pfSense avec une première plage (champ Range) allant de 192.168.2.10 à 192.168.2.99 pour laquelle nous interdisons les adresses MAC (second champ de l'option MAC Address Control) commençant par AA:BB:CC :

Configuration pfSense ordi



Nous ajoutons une seconde plage (icône "+" de l'option Range) allant de 192.168.2.150 à 192.168.2.250 pour laquelle nous n'autorisons que les adresses MAC (premier champ de l'option MAC Address Control) commençant par AA:BB:CC :

Configuration pfSense VoIP


Notre configuration est terminée :

Configuration pfSense VoIP


Dernière étape : si un serveur d'auto-provisioning des téléphones IP est présent sur le réseau, on pourrait ajouter ce paramètre au serveur DHCP.


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

Nouveau : découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

   

store.provya.fr

icon Tags de l'article :

[pfSense] Monter un accès OpenVPN site-à-site

icon 15/06/2014 - 8 commentaires

Nous allons voir dans cet article comment monter un VPN site-à-site entre deux environnements pfSense en nous reposant sur le logiciel OpenVPN.


VPN site-à-site
OpenVPN permet de monter un VPN site-à-site de manière très simple et efficace.

L'un des sites est configuré comme client et l'autre site comme serveur.

Pour monter notre VPN, nous utiliserons ici le système de clés partagées.
Si avez peu de liens site-à-site à monter, il est recommandé d'utiliser des clés partagées. Au dela de 5 à 6 liens site-à-site, il peut être judicieux d'utiliser la gestion de certificat (SSL/TLS - PKI) par simplicité d'administration.


IPsec vs OpenVPN
Faut-il monter son VPN site-à-site avec OpenVPN ou IPsec ? Vaste question à laquelle nous ne répondrons pas ici ! :-)

Nous préciserons simplement qu'IPsec et OpenVPN peuvent tous les deux être actifs et en service en parallèle sur un même serveur pfSense. La seule contrainte étant, évidemment, de ne pas attribuer les mêmes subnet sur vos lien OpenVPN et IPsec.


OpenVPN Client & Serveur
OpenVPN est basé sur un mode de fonctionnement client-serveur. Qu'un pfSense soit définit comme client ou comme serveur ne changera strictement rien d'un point de vue réseau. Cependant, si vous souhaitez connecter plusieurs sites distants sur un site principal, le plus logique est bien-sûr de définir le site principal comme "serveur" et les sites distants comme "clients".


Configurer OpenVPN côté "serveur"
Sur le pfSense du site "serveur", se rendre dans VPN > OpenVPN. Vous serez dirigez sur la page server par défaut :



Cliquer sur l'icône en forme de "+" pour ajouter un serveur VPN.


  • Server Mode : ici, nous avons cinq possibilités :
  1. Peer to peer (SSL/TLS) : pour monter un VPN site-à-site en utilisant une authentification par certificat.
  2. Peer to peer (Shared Key) : pour monter un VPN site-à-site en utilisant une authentification par clé partagée.
  3. Remote Access (SSL/TLS) : pour monter un accès distant pour clients nomades en utilisant une authentification par certificat.
  4. Remote Access (User Auth) : pour monter un accès distant pour clients nomades en utilisant une authentification par login/password.
  5. Remote Access (SSL/TLS + User Auth) : pour monter un accès distant pour clients nomades en utilisation une authentification par certificat et par login/password.
Nous choisissons Peer to peer (Shared Key).

  • Protocol : nous choisissons UDP.
L'utilisation du protocole TCP n'est pas adaptée à un environnement VPN, car en cas de pertes de paquets ceux-ci devront être retransmis. Ce qui n'est pas forcément souhaité. La conséquence serait un ralentissement du lien VPN à cause d'une forte ré-émission de paquets.
TCP est en revanche particulièrement intéressant si vous devez passer au travers d'une connexion particulièrement restrictive. Dans ce cas, l'utilisation du port 443 (correspondant au port HTTPS) est particulièrement judicieux (il est rare que le port 443 soit bloqué en sortie d'un réseau vers Internet). Attention toutefois, si vous choisissez le port 443, assurez-vous d'abord que le WebGUI de pfSense ne tourne pas déjà sur ce port !

  • Device Mode : nous choisissons tun
TUN travaille avec des frames IP.
TAP travaille avec des frames Ethernet.
  • Interface : l'interface sur laquelle le serveur va recevoir les connexions entrantes. Généralement WAN ou OPT1. Il est également possible de choisir "any" et dans ce cas le serveur sera en écoute sur toutes les interfaces.
  • Local port : port d'écoute du serveur OpenVPN. Par défaut, c'est le 1194. Il est à noter que chaque serveur VPN doit disposer de son propre port d'écoute. De la même manière, il est important de s'assurer qu'aucun autre service ne soit déjà en écoute sur le port choisi... y'en a qui ont essayé ils ont eu des problèmes :-)
  • Description : nom que l'on souhaite donner à ce serveur VPN. C'est ce nom qui apparaîtra dans les listes déroulantes de sélection de VPN se trouvant aux différents endroits du WebGUI pfSense.
  • Shared Key : nous conseillons de laisser coché la case "Automatically generate a shared key". La clé sera à copier/coller côté client.
  • Encryption algorithm : ce paramètre doit être le même côté client et côté serveur. N'importe quel choix sera bon. CAST/DES/RC2 sont moins sécurisés, mais plus rapides. Notre choix se porte sur AES 128 bits
  • Hardware Crypto : précise si le serveur dispose d'un support cryptographique.
  • Tunnel Network : réseau utilisé pour le tunnel VPN. N'importe quel réseau inutilisé dans l'espace d'adressage de la RFC 1918 peut être utilisé. Pour une connexion site-à-site, l'utilisation d'un /30 est suffisant (inutile d'utiliser un /24).
  • Local Network/s : désigne les réseaux locaux accessibles par le client. Il convient d'utiliser la notation CIDR. Dans le cas où l'on souhaite indiquer plusieurs réseaux, il faut les séparer par un point-virgule.
  • Remote Network/s : utilisé uniquement pour l'accès au réseau distant (donc dans une configuration site-à-site). Il convient d'utiliser la notation CIDR. Dans le cas où l'on souhaite indiquer plusieurs réseaux, il faut les séparer par un point-virgule.
  • Concurrent connections : précise le nombre de connexion client possible en simultanée sur ce serveur. Dans le cas d'un VPN site-à-site, ce paramètre peut être renseigné à 1.
  • Compression : permet d'activer la compression LZO sur l'ensemble des flux transitant par ce tunnel VPN. Si les données transitant dans ce tunnel VPN sont principalement des données chiffrées (HTTPS, SSH, etc.), cocher cette option ne fera qu'ajouter un overhead inutile aux paquets.
  • Type-of-Service : cocher cette case indique de reprendre dans les paquets envoyés par OpenVPN la valeur du champ TOS des paquets encapsulés traversant le tunnel. Cette option peut être considérée comme présentant un risque potentiel de sécurité. Aussi, nous ne recommandons pas nécessairement son utilisation.
  • Duplicate Connections : cette option ne doit généralement pas être cochée, à moins que vous ne sachiez ce que vous faites.
  • Advanced : permet de passer des paramètres avancés à OpenVPN. Cela peut notamment être utile si l'on décide de faire du VPN natté (entre deux sites ayant le même plan d'adressage) ou pour pousser des routes spécifiques. Nous ne rentrerons pas dans le détail ici.




Configuration du Firewall
Il est maintenant nécessaire d'autoriser le flux VPN au niveau du firewall. Se rendre dans Firewall > Rules :



Sur l'interface sur laquelle le serveur OpenVPN est en écoute, créer une règle autorisant le trafic à atteindre l'adresse IP et le port du serveur OpenVPN.

Dans notre exemple, nous travaillons sur l'interface WAN et l'adresse IP de notre pfSense sur notre WAN est 109.190.190.10, ce qui donne :

  • Interface : WAN
  • Protocol : UDP
  • Source : si l'adresse IP publique du site distant est connue et fixe, la renseigner en choisissant le type "Single host or alias"
  • Destination : type "Single host or alias", address à 109.190.190.10
  • Destination port range : port choisi lors de la configuration du serveur OpenVPN, soit 1194

Ce qui nous donne la règle suivante :




La configuration côté serveur est terminée. Il nous reste simplement à penser à autoriser ou filtrer nos flux transitant à travers notre nouvelle interface OpenVPN. Pour cela, se rendre dans Firewall > Rules > OpenVPN.


Configurer OpenVPN côté "client"
Sur le pfSense du site "client", se rendre dans VPN > OpenVPN. Puis cliquer sur l'onglet "Client".

Cliquer sur l'icône en forme de "+" pour ajouter un client VPN.

  • Server Mode : ici, nous avons deux possibilités :
  1. Peer to peer (SSL/TLS)
  2. Peer to peer (Shared Key)
Nous choisissons Peer to peer (Shared Key), conformément à ce que nous avons configuré côté OpenVPN serveur.

  • Protocol : choisir le même protocole que celui choisi côté serveur (soit UDP)
  • Device mode : choisir tun
  • Interface : l'interface d'écoute du client OpenVPN. Dans notre cas, ce sera WAN
  • Local port : si ce champ est laissé vide, un port aléatoire sera choisi
  • Server host or address : le nom FQDN ou l'adresse IP publique du site distant (ici, 109.190.190.10)
  • Server port : port d'écoute du serveur OpenVPN distant (ici, 1194)
  • Proxy host or address : adresse du proxy si le pfSense client nécessite de passer par un proxy
  • Proxy port : idem ci-dessus
  • Proxy authentification extra options : idem ci-dessus
  • Server host name resolution : laissez décoché cette case
  • Description : le nom que vous souhaitez donner à votre tunnel VPN
  • Shared Key : copier/coller la clé générée côté OpenVPN serveur
  • Encryption algoithm : renseigner le même algorithme que celui saisi côté OpenVPN serveur
  • Hardware Crypto : précise si le serveur dispose d'un support cryptographique
  • Tunnel Network : même réseau que celui renseigné côté OpenVPN serveur
  • Remote Network/s : Renseigner le réseau du site distant ou n'importe quel autre réseau inutilisé si vous souhaitez faire du VPN natté par exemple. Il convient d'utiliser la notation CIDR. Dans le cas où l'on souhaite indiquer plusieurs réseaux, il faut les séparer par un point-virgule.
  • Limit ourgoing bandwidth : bande-passante maxi allouée à ce tunnel VPN. Laisser vide pour ne pas fixer de limite.
  • Compression : doit être similaire à la configuration côté OpenVPN serveur
  • Type-of-Service : cocher cette case indique de reprendre dans les paquets envoyés par OpenVPN la valeur du champ TOS des paquets encapsulés traversant le tunnel. Cette option peut être considérée comme présentant un risque potentiel de sécurité.
  • Advanced : permet de passer des paramètres avancés à OpenVPN. Nous ne rentrerons pas dans le détail ici.




La configuration côté client est terminée. Il nous reste simplement à penser à autoriser ou filtrer nos flux transitant à travers notre nouvelle interface OpenVPN. Pour cela, se rendre dans Firewall > Rules > OpenVPN.


Debug
Pour disposer d'informations sur vos liens OpenVPN (état, date de début de mise en service, volume entrant/sortant, etc.), se rendre dans Status > OpenVPN.

Pour les logs du firewall, se rendre dans Status > System logs > Firewall.


Pour aller plus loin
[pfSense] La gestion des certificats pour les connexions OpenVPN
[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN
[pfSense] Sécurisez l'accès distant de vos collaborateurs nomades avec OpenVPN


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

Nouveau : découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

   

store.provya.fr

icon Tags de l'article :