[Réseaux] IGMP snooping

L’IGMP Snooping  est une fonction de couche 2 permettant d’écouter le traffic IGMP en permettant à un commutateur (switch) d’intercepter les communications entre les routeurs  multicast et les hôtes.

 

Introduction

 

Le protocole IGMP est utilisé pour l’adhésion d’hôtes à un ou plusieurs groupes multicast présents sur le réseau.
Un obstacle apparaît cependant lorsque le réseau ne contient pas uniquement des équipements réseaux Cisco. En effet, seuls les équipements réseaux Cisco ont la possibilité d’utiliser le protocole CGMP (Cisco Group Management Protocol) qui permet de restreindre le traffic IGMP à la couche 2 du modèle OSI. Pour contrer ce conflit, la plupart des équipements réseaux (non Cisco) possèdent la fonction d’IGMP Snooping permettant l’utilisation des groupes multicast sur un réseau composé d’équipements de marques différentes.

 

Rappel sur le protocole IGMP

 

IGMP (Internet Group Management Protocol) est un protocole actuellement en version 3 défini par l’IETF (Internet Engineering Task Force) en tant que RFC 3376 qui opère au niveau de la couche 2. Il permet aux hôtes du réseau de rejoindre des groupes multicast en se déclarant sur les routeurs multicast. L’inscription à ce(s) groupe(s) multicast peut se faire soit de manières spontanée par l’hôte, soit après l’envoi d’un paquet IGMP par le routeur multicast à l’adresse 224.0.0.1.
Le protocole IGMPv3 supporte 3 types de messages :

  • Host membership query : message envoyé par les routeurs à intervalle de temps régulier (125 secondes par défaut) pour connaître les membres des groupes multicast.
  • Host membership report : message envoyé par l’hôte lorsqu’il adhère à un groupe. Ce type de message peut être envoyé de l’initiative de l’hôte ou suite à un host membership query.

igmp1

Principe

 

Comme dit précédemment, l’IGMP snooping permet de mettre en place des groupes multicast sur des réseaux ne fonctionnant pas uniquement avec du matériel Cisco. L’IGMP snooping a pour principe de donner à un équipement de couche 2 (commutateur) un niveau de couche 3.
Le commutateur disposant de cette fonctionnalité analyse tout le trafic IGMP entre les hôtes et le routeur multicast et effectue différentes opérations selon le type de trafic.
Si un hôte transmet un message host membership report au routeur multicast, le commutateur rajoutera à sa liste multicast le numéro de ports de cet hôte. Le but est de n’envoyer le trafic multicast que vers cet hôte et non pas vers tous hôtes comme le ferait un commutateur dépourvu de l’IGMP snooping. Ce processus fait donc une économie de bande passante dans des réseaux pourvus de groupes multicast.
Le processus inverse s’opère lorsqu’un hôte envoie au routeur un leave group, le numéro de port de cet hôte est supprimé de la table multicast du commutateur. Bien qu’il y ait un gain non négligeable en bande passante, le commutateur doit analyser tout le trafic IGMP ce qui peut provoquer une surcharge du processeur du commutateur. C’est pourquoi il est vivement conseillé d’implémenter cette fonctionnalité sur des routeurs ayant un CPU performant.

 

Exemple de configuration mettant en place l’IGMP snooping

igmp_snooping1

Dans cet exemple de configuration, nous savons que les hôtes 1 et 3 ont déclaré au routeur multicast leur appartenance au groupe multicast. Pour cela ces 2 hôtes ont envoyé au routeur multicast un host membership report. Lorsque ces messages ont traversé le commutateur, celui-ci les a examinés, il a compris que les hôtes 1 et 3 souhaitaient appartenir au groupe multicast. Il les ajoute donc à sa liste multicast et redirige les paquets host membership report vers le routeur multicast.
L’hôte 2 n’a en revanche pas déclaré son appartenance au groupe, il n’est donc pas dans la liste multicast du commutateur.
Maintenant le routeur souhaite communiquer avec les hôtes appartenant au groupe, il envoie ses paquets vers le commutateur en multicast. Ce dernier consulte sa liste multicast et se rend compte que seuls les hôtes 1 et 3 appartiennent au groupe multicast. Les paquets provenant du routeur sont donc redirigés vers les hôtes 1 et 3. L’hôte 2 ne reçoit aucune information.
Si l’IGMP snooping n’était pas implémenté sur le commutateur, l’hôte 2 aurait reçu les mêmes informations que les hôtes 1 et 3.

 

Mettre en place l’IGMP snooping

 

Voici les commandes à entrer sur un commutateur Cisco pour mettre en place l’IGMP snooping :

 

1) Activer l’IGMP snooping (désactivé par défaut) :

Console> (enable) set igmp enable

 

2) Configurer le routeur multicast :

Console> (enable) set multicast <port>

 

3) Afficher les statistiques d’IGMP :

show multicast router

 

et

show igmp statistics <VLAN_ID>

 

Exemple :

 

Console> (enable)show multicast router
CGMP disabled
IGMP enabled

Port       Vlan
———  —————-
3/1        2-3

Total Number of Entries = 1
‘*’ – Configured

Console> (enable) show igmp statistics 3
IGMP enabled

 
IGMP statistics for vlan 2:
Total valid pkts rcvd: 329
Total invalid pkts recvd 0
General Queries recvd 82
Group Specific Queries recvd 0
MAC-Based General Queries recvd 0
Leaves recvd 0
Reports recvd 82
Queries Xmitted 0
GS Queries Xmitted 0
Reports Xmitted 0
Leaves Xmitted 0
Failures to add GDA to EARL 0
Topology Notifications rcvd 0

[Réseaux] Protocole VRRP

A l’heure où la haute disponibilité est un des maîtres mots du réseau, le protocole VRRP (Virtual Router Redundancy Protocol) permet d’augmenter la disponibilité des routeurs lors de transferts de données importantes dans un même sous-réseau.

 

Introduction

 

Le transfert de données importantes effectué via un seul routeur peut s’avérer problématique en cas de dysfonctionnement de celui-ci. Le protocole VRRP offre la possibilité via un système de virtualisation qui créé des liens entre les routeurs pour augmenter leurs disponibilités.
Le principe étant de faire travailler les routeurs en collaboration pour éviter toute perte de données.
Ce protocole non propriétaire est défini par la norme RFC 3768.
Attention, VRRP fournit des informations sur l’état du routeur et ne donne en aucun cas des informations sur les routes échangées par les routeurs. VRRP n’est pas un protocole de routage.

Le transfert de données importantes effectué via un seul routeur peut s’avérer problématique en cas de dysfonctionnement de celui-ci. Le protocole VRRP offre la possibilité via un système de virtualisation qui créé des liens entre les routeurs pour augmenter leurs disponibilités. Le principe étant de faire travailler les routeurs en collaboration pour éviter toute perte de données.Ce protocole non propriétaire est défini par la norme RFC 3768. Attention, VRRP fournit des informations sur l’état du routeur et ne donne en aucun cas des informations sur les routes échangées par les routeurs. VRRP n’est pas un protocole de routage.

 

Principe

 

Pour utiliser le protocole VRRP, il faut au minimum 2 routeurs. Dans ce groupe, une adresse IP virtuelle va être partagée entre les différents routeurs. Le routeur permettant l’acheminement le plus rapide des données de part sa position est désigné comme le master routeur, comprenez le routeur maître et va répondre aux requêtes de l’adresse IP virtuelle qui sera utilisée comme passerelle par défaut pour les autres membres du réseau. L’adresse MAC virtuelle sera toujours de la forme 00-00-5E-00-01-XX où XX est le VRID pouvant aller de 0x01 à 0xFF.
Les autres routeurs membres de ce groupe sont dit de backup et permettent de répondre aux requêtes de l’adresse IP virtuelle en cas de dysfonctionnement du routeur maître. Chaque groupe VRRP est identifié par un VRID (Virtual Routeur Identifier) qui doit être unique. La portée de chaque routeur étant restreint à un seul LAN.
Chaque routeur se voit également attribué une priorité allant de 1 à 255. La routeur maître possède la priorité la plus élevée (255). Les autres priorités sont une nouvelle fois attribuées en fonction de la vitesse d’acheminement des données.

schema_vrrp

Le routeur maître communique périodiquement (1sec par défaut) avec ses routeurs de backup via l’adresse de multicast 224.0.0.1 en leur envoyant sa priorité. Le routeur de backup vérifie donc si sa priorité est bien plus faible que celle du maître. Plusieurs cas se présentent alors (cas de 2 routeurs) :
si la priorité du routeur de backup est plus faible que celle du maître, tout se passe normalement et rien ne change.
si la priorité du routeur de backup est plus importante que celle du maître, alors le routeur de backup s’auto-proclame maître
si le routeur de backup ne reçoit pas de message du routeur maître après une période définie (3,6sec par défaut), alors il s’auto-proclame maître également.

 

Load balancing (répartition des charges)

 

Le protocole VRRP assure simplement une haute disponibilité durant le transfert de données, mais n’assure en aucun cas la répartition de charges entre les différents routeurs afin d’améliorer les vitesses de transfert. Pour effectuer du load balancing en plus de la redondance de liens, préférez le protocole propriétaire Cisco GLBP (Gateway Load Balancing Protocol) qui permet de faire de la répartition de charge sur plusieurs routeurs en utilisant qu’une seule adresse IP virtuelle, mais plusieurs adresses MAC virtuelles. Attention pour utiliser ce protocole, il faut absolument que votre routeur supporte les adresses MAC multiples sur une interface physique.

 

Mise en place

 

Voici comment se déroule la mise en place du protocole VRRP sur une interface :

 

Router(config)#interface <interface>
Router(config-if)#ip address <ip> <masque>
Router(config-if)#no shutdown
Router(config-if)#ip vrrp <VRID>
Router(config-if)#ip vrrp <VRID> priority <entre 1 et 255>
Router(config-if)#ip vrrp <VRID> authentication-type <type>
Router(config-if)#ip vrrp <VRID> virtual-address <ip> <masque>
Router(config-if)#ip vrrp <VRID> enable

 

En prenant un exemple concret on obtient des commandes de ce type pour la configuration du routeur maître :

 

Router(config)#interface fastEthernet 4/0
Router(config-if)#ip address 194.50.1.42 255.255.255.0
Router(config-if)#no shutdown
Router(config-if)#ip vrrp 25
Router(config-if)#ip vrrp 25 priority 255
Router(config-if)#ip vrrp 25 authentication-type none
Router(config-if)#ip vrrp 25 virtual-address 194.50.1.50 255.255.255.0
Router(config-if)#ip vrrp 25 enable

 

Pour redéfinir certains paramètres comme la durée entre chaque émission (1sec par défaut) du message par le routeur maître, vous devez utiliser la commande :

 

Router(config-if)#ip vrrp 25 advertise-interval 50

Des commandes “show” sont également disponibles afin de vérifier le fonctionnement et la mise en place de VRRP sur votre réseau :

 

– Statisiques de VRRP : show ip vrrp

 

Console> (enable)show ip vrrp

 

Exemple:

 

Console> (enable)show ip vrrp
Interface: fastEthernet5/0.0 vrrpVrid: 1
primary address: 10.0.0.2
operational state: backup (current master: 130.0.0.1)
admin state: enabled
up time: 145 seconds
interval: 1 second
last error status: no error
priority: 101
auth type: none
preemption: enabled
auto assoc address(es): 10.0.0.1, 100.0.0.1, 101.0.0.1

 

– Affiche un bref résumé sur la mise en place de VRRP : show ip brief vrrp

 

Console> (enable)show ip brief vrrp

 

Exemple:

 

Console> (enable)show ip brief vrrp
Interface              VRID  Primary Address  State   Adv  Pri  Admin
———————  —-  —————  ——  —  —  —–
fastEthernet12/8.1.1   255  123.123.123.123    init    1  100  disabled
gigabitEthernet12/8.1.1  1          1.1.1.1  master    1  254  enabled

 

Conclusion

 

L’implémentation du protocole VRRP est un excellent moyen de faire de la redondance de liens afin d’augmenter la disponibilité de votre réseau. Petit inconvénient, celui-ci ne propose pas la répartition de charges en plus de la redondance de liens comme le fait le protocole Cisco GBLB. Pour une alternative open sources, vous pouvez opter pour le protocole CARP (Common address redundancy protocol).

[Réseaux] Le Bluetooth

Introduction

Le bluetooth est une technologie utilisant les ondes radio sur de courtes distances afin de créer des PAN (Personal Area Network) entre un téléphone portable et un ordinateur ou entre un téléphone et une oreillette.


800px-Bluetooth_logo

Historique

La naissance du Bluetooth remonte à 1994 par le constructeur Ericsson. C’est ensuite en 1998 avec la création du SIG, Bluetooth Interest Group (association de Agere, IBM, Intel, Microsoft, Motorola, Nokia et Toshiba) que le Bluetooth s’est vulgarisé. Il est maintenant largement diffusé notamment dans le monde de la téléphonie mobile.

Le terme Bluetooth vient d’un roi danois nommé Harald Ier et surnommé “homme à la dent bleue”. Ce roi avait réussi à rapprocher le Danemark et la Norvège alors que l’Europe était déchirée par de nombreux conflits.

Principe et fonctionnement

Le standard du Bluetooth se fractionne en plusieurs normes définies par l’IEEE (Institues of electrical and electronics engineers), http://www.ieee.org :

  • IEEE 802.15.1 : Bluetooth 1.x
  • IEEE 802.15.2 : Bluetooth avec une bande de fréquence de 2,4 GHz (non validé)
  • IEEE 802.15.3 : Bluetooth à 20Mbils/s
  • IEEE 802.15.4 : En cours de développement

Un réseau formé par un périphérique Bluetooth s’appelle un pico-réseau. Un périphérique (le maître) peut se connecter aux périphériques voisins (les esclaves). En théorie, le maître peut se connecter à 7 esclaves en simultané (l’adresse d’un périphérique ne se codant que sur 3bits, il ne peut y avoir que 8 adresses possibles, soit 8 périphériques en même temps).

Rééllement, un périphérique ne peut se connecter qu’à un seul esclave à la fois. Grâce à une vitesse de commutation très rapide, le périphérique maître semble connecté à plusieurs périphériques esclaves.

Pour établir une connexion, le maître envoie des requêtes aux périphériques auxquels il souhaitent se connecter. Les périphériques esclaves répondent au maître en renvoyant leurs adresses respéctives.

Le maître choisit ensuite sur quel esclave il se connecte et se synchronise avec celui-ci.

Le protocole de transfert de données utilisé par le Bluetooth est le L2CAP (Logical Link Control & Adaptation Protocol).

Le service RFCOMM permet (au dessus du L2CAP d’émuler des liaisons séries (notamment pour certaines applications GPS).

Concernant la sécurité, le Bluetooth propose un système de pairage. Les deux périphériques demandent à leurs utilisateurs respéctifs un code PIN (Personal Identification Number). Pour que les 2 périphériques communiquent, il faut que les deux codes PIN rentrés soient identiques.

Les profils

GAP : Accès générique

SDAP : Découverte d’applications

SPP : Port série

HS Profile : Oreillette

DUN Profile : Accès réseau à distance

LAN Access Profile : ce profil est maintenant obsolète ; il est remplacé par le profil PAN

GOEP : Echange d’objets

SP : Gestionnaire d’informations personnelles

FTP : Transfert de fichiers

CTP : Téléphonie sans fil

IP : Intercom (talkie-walkie)

A2DP : Distribution audio avancée

AVRCP : Commande à distance

HFP : Mains libres

PAN : Réseau personnel

BIP : Infographie basique

BPP : Impression basique

SAP : Accès à une carte SIM


Conclusion


Le Bluetooth est un protocole très pratique pour créer de très petits réseaux sur de faibles distances. Sa facilité d’utilisation fait de lui un acteur majeur de la téléphonie mobile actuelle.

[Réseaux] Protocole ARP

Indispensable à l’usage d’IPv4, le protocole ARP (Address Resolution Protocol) permet de connaître l’adresse physique d’une machine (adresse MAC (Media Access Control)) à partir de son adresse physique (Adresse IP).

 

Introduction

 

Sur un réseau, les périphériques sont identifiés par leurs adresses logiques de couche 3 du modèle OSI (adresse IP). Ces adresses sont contrôlées par la IANA (Internet Assigned Numbers Authority). Les adresses physiques, couche 2 du modèle OSI (adresse MAC) quant à elles sont définies en usine lors de la fabrication de la carte réseau du périphérique. C’est pour cela qu’elles ne sont pas utilisées sur internet, car le changement d’une carte réseau, entraînerait un ré-adressage des ordinateurs. Contrairement à une adresse IP qui est codée sur 32bits, une adresse MAC est codée sur 48bits. Le protocole ARP se charge d’établir une correspondance entre ces 2 types d’adresses.
Il est défini par le RFC 826.

 

Principe et cas de figure

 

2 cas de figure peuvent se présenter dans le cadre du protocole ARP.
Si un périphérique souhaite communiquer avec un autre périphérique dont il connaît l’adresse IP, alors il cherche dans sa table de cache ARP si il a une correspondance Adresse IP : Adresse MAC. Si c’est le cas il envoie simple une trame ethernet avec comme adresse de destination l’adresse MAC du périphérique avec lequel il souhaite communiquer.
Si il n’a aucune correspondance Adresse IP : Adresse MAC, le message devant être expédié est mis en attente et le périphérique émet une requête ARP en broadcast pour “demander” aux périphériques connectés si leur adresse IP correspond avec l’adresse IP avec laquelle on veut communiquer. Dans le cas où un périphérique possède l’adresse IP souhaitée il répond à la requête et met sa table de cache ARP à jour.
A la réception de la requête, la machine à l’origine du trafic peut mettre à jour sa table de cache ARP et envoyer le message qu’elle avait mis en attente précédemment.

Il existe un protocole inverse au protocole ARP, le protocole RARP (Reverse Address Resolution Protocol), mais celui-ci est beaucoup moins utilisé car la table dont il a besoin est statique et doit donc être remplie à la main puis maintenue à jour. Cependant ce protocole peut être utilisé dans le cadre de stations de travail sans disque dur ne connaissant pas leurs adresses IP. Ce protocole est défini par la RFC 903.
Pour palier aux limitations de RARP il est conseillé d’utiliser le DRARP (RARP dynamique) ou encore le DHCP.

 

Structure d’une trame ARP

 

– Trame MAC 802.3

trame_ARP_803_3

– Trame Ethernet Xerox

trame_ARP_Xerox

Sécurisation du protocole ARP

 

Le protocole ARP est sensible à une attaque nommée ARP cache poisoning ayant pour idée d’envoyer une trame ARP erronée à un périphérique pour qu’il l’enregistre dans sa table de correspondances Adresse IP : Adresse MAC (cf 1).
Admettons que A veut envoyer un message à B mais il ne connait pas son adresse MAC. Il envoie donc une requête ARP en broadcast (cf 1) pour connaître l’adresse MAC de destination. Le but de l’attaque est de répondre avant la machine B en envoyant une trame ARP contenant l’adresse IP de B, mais avec l’adresse MAC de notre machine. Lorsque A voudra correspondre avec B, c’est notre machine qui recevra le message. Ensuite libre à vous de rediriger les messages venant de A vers B pour plus de transparence. Ce type d’attaque est dit “Man in the middle”.

Voici quelques protections contre les attaques basées sur le protocole ARP :

La première solution, qui reste inenvisageable sur un réseau de grande taille, est l’ARP statique, c’est à dire entrer manuellement le couple Adresse IP/Adresse MAC de chaque périphérique connecté et ce sur chaque périphérique.

Solution plus pérenne, la mise en place d’un filtrage ARP permettant de forcer des associations IP/MAC. Sur des équipements de couche 3, on peut également mettre en place des associations port/MAC/IP statiques.

La mise en place d’un IDS/firewall permettant de détecter ce type d’attaque.

 

ARP sur Cisco IOS

 

Afficher la table ARP :

 

router# show arp
Address Age Hardware Addr State Type Interface
192.168.7.19 00:59:32 0030.7131.abfc Dynamic ARPA FastEthernet0/0
192.168.7.20 00:59:32 0000.0c07.ac24 Dynamic ARPA FastEthernet0/1

 

Supprimer le cache ARP :

 

router# clear arp-cache

 

Ajouter une entrée statique dans la table ARP (mode configuration du routeur) :

 

router(config)# arp 192.168.7.19 0030.7131.abfc arpa

 

Soit sous forme générique :

 

router(config)# arp <ip> <mac> <encapsulation>

 

L’encapsulation étant “arpa” pour les interfaces ethernet et “snap” pour les interfaces Token Ring et FDDI.

Il existe d’autres commandes disponibles sur les équipements Cisco telles que proxy-arp ou arp timeout

 

Conclusion

 

Le protocole ARP permet donc de trouver l’adresse MAC d’une machine à partir de son adresse IP. Il est encore utilisé de nos jours avec IPv6, mais tend à disparaître avec l’apparition d’IPv6 qui lui utilise le protocole NDP (Neighbour Discovery Protocol).

[Réseaux] Introduction au VPN

A l’heure où la mobilité est un argument dans le domaine professionnel, il est nécessaire de pouvoir travailler pour son entreprise à n’importe quel endroit du monde.

Pour des raisons évidentes de sécurité, toutes les informations indispensables à une entreprise ne peuvent pas être stockées sur un serveur accessible publiquement depuis internet. Elles ne sont donc théoriquement pas accesssibles depuis un réseau extérieur à celui de l’entreprise.

Un commercial en déplacement ne peut donc pas accéder aux informations de son entreprise si il est en déplacement à l’autre bout du monde ou non connecté au réseau de l’entreprise.

Pour remédier à ce problème, la technologie VPN (Virtual Private Network) a été mise en place afin contrer ce problème de sécurité et de permettre à un utilisateur n’étant pas connecté à un réseau interne de pouvoir quand même y accéder en totalité ou en partie au travers d’un reseau public (cf Internet).

Le principe du VPN est relativement simple, il a pour but de créer au travers d’un réseau public (et par conséquent non sécurisé) un tunnel crypté permettant de faire transiter des données jusqu’à un réseau privée disposant d’une connexion internet.

Pour envoyer des données au travers de ce tunnel, les 2 protagonistes (le commercial et l’entreprise par exemple) doivent se mettre d’accord sur l’algorithme de cryptage utilisé. Le commercial envoie ensuite ses données cryptées et éventuellement signées (pour rajouter une sécurité supplémentaire) dans le tunnel.

Ces données sont reçues par le serveur VPN de l’entreprise qui va les déchiffrer et vérifier leur intégrité.

Si un utilisateur récupérait les paquets transmis entre les 2 protagonistes, il ne trouverait que des paquets chiffrés et donc inexploitables sans avoir l’algorithme pour les déchiffrer. L’opération inverse se déroule lorsque les informations transitent du réseau de l’entreprise vers le commercial.

Voici la liste des protocoles de tunnelisation (source Wikipédia) :

  • L2F (Layer Two Forwarding) est un protocole de niveau 2 développé par Cisco Systems, Nortel et Shiva. Il est désormais quasi-obsolète.

  • L2TP (Layer Two Tunneling Protocol) est l’aboutissement des travaux de l’IETF (RFC 3931) pour faire converger les fonctionnalités de PPTP et L2F. Il s’agit ainsi d’un protocole de niveau 2 s’appuyant sur PPP.

  • IPsec est un protocole de niveau 3, issu des travaux de l’IETF, permettant de transporter des données chiffrées pour les réseaux IP.

  • SSL/TLS offre une très bonne solution de tunnelisation. L’avantage de cette solution est d’utiliser un navigateur Web comme client VPN.

  • SSH, initialement connu comme remplacement sécurisé de telnet, offre la possibilité de tunneliser des connexions de type TCP, permettant d’accéder ainsi de façon sûre à des services offerts sur un réseau protégé, sans créer un réseau privé virtuel au sens plein. Toutefois, depuis sa version 4.3, le logiciel OpenSSH permet de créer des tunnels entre deux interfaces réseau virtuelles au niveau 3 (routage du seul trafic IP, interfaces TUN) ou au niveau 2 (tout le trafic Ethernet, interfaces TAP). Toutefois, OpenSSH ne gère que la création de ces tunnels, la gestion (routage, adressage, pontage, etc …), c’est à dire la création du VPN utilisant ces tunnels, restant à la charge de l’utilisateur.

  • VPN-Q : La mise en quarantaine des connexions permet d’isoler un utilisateur authentifié et d’inspecter sa configuration pour voir s’il ne présente aucun risque (le cas échéant de le mettre en conformité – correctifs, antivirus, pare-feu…). Ensuite et seulement s’il est conforme, il aura accès au réseau interne de l’entreprise. L’ajout de l’inspection du poste permet de réduire considérablement le risque des attaques contre le VPN. Sur les passerelles Microsoft ISA Server, la technologie est appeléeVPN Quarantaine (VPN-Q). L’automatisation est réalisée à travers le logiciel QSS (Quarantine Security Suite). Microsoft fournit le service NAP qui permet de faire la même chose également sur les câbles réseaux (switchs, …) et les accès Wi-Fi sécurisés.

La connexion VPN est intégrée nativement dans la plupart des systèmes d’exploitation qui supportent le plus souvent les protocoles PPTP et L2TP/IPsec. Il est donc simple sous Windows XP/Vista et Mac OS X de configurer en quelques secondes une connexion vers un serveur VPN.

Conclusion

Le VPN est donc un outil puissant permettant la mobilité de l’information au travers d’un média sécurisé. Cependant attention, un serveur VPN est souvent placé dans une DMZ (Zone déminilitarizée) et doit doit donc être correctement configuré afin de pouvoir accéder à tout ou partie des informations du réseau interne de l’entreprise.