Cahier groupe n°4 : Différence entre versions
(→Serveur DNS et DNSSEC avec Bind) |
(→Serveur DNS et DNSSEC avec Bind) |
||
| Ligne 272 : | Ligne 272 : | ||
$TTL 604800 | $TTL 604800 | ||
| − | + | ||
@ IN SOA ns.zegbicho.lol. root.zegbicho.lol. ( | @ IN SOA ns.zegbicho.lol. root.zegbicho.lol. ( | ||
| − | + | 2015102001 ;serial | |
| − | + | 14400 ;refresh | |
| − | + | 3600 ;retry | |
| − | + | 604800 ;expire | |
| − | + | 10800 ;minimum | |
) | ) | ||
| − | + | ||
57.48.193.in-addr.arpa. IN NS ns.zegbicho.lol. | 57.48.193.in-addr.arpa. IN NS ns.zegbicho.lol. | ||
57.48.193.in-addr.arpa. IN NS ns6.gandi.net. | 57.48.193.in-addr.arpa. IN NS ns6.gandi.net. | ||
| − | + | ||
| − | + | 164 IN PTR zegbicho.lol. | |
| + | |||
Version du 11 janvier 2016 à 08:34
Sommaire
Cahier des charges de la tâche particulière
Présentation de la tâche particulière
La tâche particulière que nous devons effectuer est de configurer le commutateur Cisco 6009 présent en salle E304. Nous devons dans un premier temps de les mettre à jour de CatOS vers IOS, pour pouvoir dans un second temps mettre en place les différents VLAN. Cette tâche particulière est effectuée avec le groupe n°3 qui s'occupera du commutateur présent dans la salle voisine E306.
Matériel utilisé pour la tâche particulière
- Commutateur Cisco 6009
- Un ordinateur muni d'un port série pour la configuration
- Un câble reliant le commutateur à ce port série
Suivi de l'avancement du TP
Partie commutateur
Semaine 1 (01/10/2015)
- Découverte des commutateurs Cisco 6009 présents en E304 et E306
- Le commutateur possède deux modules constitués d'une carte mère appelée carte superviseur et une carte fille qui est la carte routeur.
- Ces cartes possèdent toutes les deux leurs propres mémoires flash à savoir sup-bootflash pour le superviseur et bootflash pour la carte fille.
- On peut également insérer une carte flash de 20Mo dans le module
Initialement, ces modules fonctionnent sous CatOS pour la plupart d'entre eux. L'idée est de migrer tout les modules vers des systèmes d'exploitation de type IOS (le seul système utilisé aujourd'hui par Cisco).
- Echange d'un superviseur entre les deux commutateurs afin d'avoir sur chacun d'entre eux un superviseur sous IOS et un autre sous CatOS
- Un des superviseurs en E304 censé fonctionner sous CatOS ne démarre pas correctement
- On décide donc d'utiliser une carte flash formatée sous CatOS grâce à l'autre commutateur présent dans la salle voisine. On y copie également un système CatOS pour le superviseur et un boostrap CatOS
Pour la prochaine séance, l'objectif est d'utiliser cette carte pour booter le 2e module en CatOS.
Semaine 2 (08/10/2015)
- Le premier module fonctionne correctement sous IOS
- Problème de la semaine précédente : le 2e module refuse de booter, même sous le CatOS initialement présent.
- Les données de la carte ont été supprimées, on ne peut les récupérer car tous les autres modules tournent actuellement sou IOS.
- Il faut trouver une solution pour booter le commutateur sous CatOS d'une autre façon
Semaine 3 (15/10/2015)
- On cherche une solution pour copier un fichier sur la bootfalsh du module qui ne fonctionne pas :
- xmodem, ymodem, zmodem3
- CuteCom
- Un CatOS, puis un IOS a pu être installé sur le superviseur défectueux depuis une carte mémoire flash. On veut que le système démarre sur une image de IOS. On modifie alors le "boot system" par la commande configure terminal :
Router#config terminal Router(config)#boot system flash sup-bootflash:c6sup11-js-mz.121-27b.E1.bin //On quitte le mode configuration et on sauvegarde les modifications Router#write
- On se connecte sur le rommon et on modifie le mode de démarrage lors de la mise sous-tension par la commande confreg. Ainsi, le système ne bootera plus sur le ROM Monitor mais sur l'image de l'OS configurée précédemment.
- Pour la prochaine fois, il suffira de brancher les deux superviseurs, de formater en IOS le bootflash et sup-bootflash du superviseur qui était défectueux (slave), et d'y copier les fichiers binaires correspondants depuis l'autre superviseur (master).
La configuration réseau du commutateur se déroule en 3 étapes.
Dans un premier temps, on configure les liaisons trunk. Il s'agit ici de la liaison qui relie le commutateur au routeur en E304, sur l'interface 4/1, et la liaison câble qui relie le commutateur au routeur en E306 sur l'interface 2/2. On entre donc les commandes ci-dessous :
conf t int Gi4/1 switchport switchport mode trunk switchport trunk allowed vlan 1,11-20,110,130 no shut exit
int Gi2/2 switchport switchport trunk encapsulation dot1q switchport mode trunk switchport trunk allowed vlan 11-20,110,130 no shut exit
interface GigabitEthernet4/10 switchport switchport mode trunk switchport trunk allowed vlan 11-20,110,130 exit
Nous avons ensuite créé les VLAN 11-20, 110 et 130 de cette façon :
conf t vlan 11 name vlan11 exit
On leur attribue ensuite un port physique du commutateur :
int Gi4/11 switchport switchport access vlan 11 no shut exit
On obtient donc le schéma physique suivant :
- VLAN11 : Gigabit 4/11
- VLAN12 : Gigabit 4/12
- VLAN13 : Gigabit 4/13
- VLAN14 : Gigabit 4/14
- VLAN15 : Gigabit 4/15
- VLAN16 : Gigabit 4/16
- VLAN17 : Gigabit 4/17
- VLAN18 : Gigabit 4/18
- VLAN19 : Gigabit 4/19
- VLAN20 : Gigabit 4/20
- VLAN 110 : Gigabit 5/1
Semaine 9 (26/11/2015)
Pour pouvoir ajouter la borne wifi au commutateur, on rajoute le vlan 1 dans l'interface 4/10 :
interface GigabitEthernet4/10 switchport switchport mode trunk switchport trunk allowed vlan 1, 11-20,110,130 exit
En mode trunk pour que la borne ait accès à tous les vlan. Le vlan est configuré de cette facon :
Internet address is 10.10.10.1/24 Broadcast address is 255.255.255.255
VM xen
Création de la machine
Semaine 3 (15/10/2015)
En parallèle, on crée notre machine virtuelle Xen sur Cordouan : On achète un nom de domaine sur Gandi : zegbicho.lol
- On se connecte en ssh sur cordouan :
ssh root@cordouan.insecserv.deule.net
xen-create-image --hostname=KARMELIET --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.174 --ip=193.48.57.164
- On regarde l'était d'avancement de la création et on récupère notre mot de passe root dans le fichier : KARMELIET.log
tail -f /var/log/xen-tools/KARMELIET.log
- On modifie le fichier de conf KARMELIET.cfg :
- bridge=IMA5sc
- on retire l'IP
- mémoire à 512M
Semaine 4 (22/10/2015)
- On lance la VM xen:
xl create /etc/xen/KARMELIET.cfg
- On se connecte sur la VM xen :
xl console KARMELIET
- Activation l'IPv4 packet forwarding en de-commentant la ligne appropriée dans le fichier /etc/sysctl.conf
- On vérifie le fichier /etc/network/interfaces
- Mises à jour :
apt-get update apt-get upgrade
On ajoute le serveur apache, le serveur DNS et SSH:
apt-get install openssh apt-get install bind9
On active la possibilité de se connecter en SSH en tant que root en modifiant le fichier de config /etc/ssh/sshd_config :
PermitRootLogin yes
Configuration du serveur apache et installation du certificat SSL
Pour activer le certificat SSL, nous devons à la fois manipuler sur notre machine Xen et sur le site gandi. Nous nous sommes d'ailleurs aidés des tutoriels gandi pour réaliser cette tâche. Nous certifions les domaines www.zegbicho.lol et zegbicho.lol. Nous avons tout d'abord besoin de clés, on génère donc le premier fichier .csr à fournir à gandi avec la commande :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout zegbicho.lol.key -out zegbicho.lol.csr
Cette commande nous a donc généré deux fichier : un fichier .key qui correspond à notre clé privée et un .csr ( clé publique) que nous devons fournir à gandi. Ce dernier nous retourne alors un .crt, nous supprimons aors la .crs dont nous n'avons plus besoin. Nous décidons de les ranger dans des dossier situés dans le dossier /etc/ssl/ de notre machine xen :
- Le fichier .crt dans /etc/ssl/certs/
- le fichier .key dans /etc/ssl/private/
Nous allons à présent suivre le tutoriel gandi : https://wiki.gandi.net/fr/hosting/using-linux/tutorials/ubuntu/ssl
On active le module ssl d'apache :
a2enmod ssl
Puis on fait en sorte qu'apache écoute sur le port 443, on édite donc le fichier de configuration /etc/apache2/ports.conf et on ajoute:
<IfModule mod_ssl.c> Listen 443 NameVirtualHost 193.48.57.164:443 </IfModule>
Maintenant nous pouvons obtenir le certificat intermédiare de gandi. Nous récupérons le fichier GandiStandardSSLCA2.pem qui nous plaçons dans le répertoire /etc/ssl/certs/ On effectue le rehash de la structure ssl:
c_rehash /etc/ssl/certs
Pour ajouter un domaine sur notre apache sécurisé, on crée le site dédié www.zegbicho.lol. Enfin, on ajoute un VirtualHost servant le contenu du dossier /var/www/www.zegbicho.lol/ sur le port 443, dans /etc/apache2/sites-available/000-zegbicho.lol-ssl.conf :
NameVirtualHost *:443 <VirtualHost *:443>
ServerName www.zegbicho.lol
ServerAlias zegbicho.lol
DocumentRoot /var/www/www.zegbicho.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/zegbicho.lol.crt
SSLCertificateKeyFile /etc/ssl/private/zegbicho.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>
Nous vérifions la chaine SSl crée avec la commande :
openssl s_client -connect 193.48.57.164:443
Notre chaine est validée, on passe donc à la configuration du serveur DNS
Serveur DNS et DNSSEC avec Bind
Nous nous aidons ici aussi des tutos gandi
Il s'agira tout d'abord de s'occuper du changement de DNS sur le site gandi. Nous devons au prélable gérer les glue records : https://wiki.gandi.net/fr/domains/management/change-glue On va alors créer un enregistrement Glue :
- Nom du serveur : ns.zegbicho.lol
- Adresse IP : 193.48.57.164
On peut alors modifier les serveurs de nom sur gandi.net : https://wiki.gandi.net/fr/dns/change
- DNS1 : ns.zegbicho.lol
- DNS2 : ns6.gandi.net
On utilise un serveur DNS secondaire appartenant à gandi.
On attends la propagation DNS et on s'attaque à la configuration de BIND : https://wiki.gandi.net/fr/hosting/using-linux/tutorials/ubuntu/bind
Toute cette configuration s'effectue dans le dossier /etc/bind/
On commence par créer un dossier zones dans lequel on créer un fichier de zone /etc/bind/zones/db.zegbicho.lol :
$TTL 604800
@ IN SOA ns.zegbicho.lol. root.zegbicho.lol. (
2015102001 ; Serial
86400 ; Refresh
3600 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
$include /etc/bind/zegbicho.lol.dnssec/zegbicho.lol-ksk.key
$include /etc/bind/zegbicho.lol.dnssec/zegbicho.lol-zsk.key
@ IN NS ns.zegbicho.lol.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.164
www IN A 193.48.57.164
michel IN A 193.48.57.164
ns IN AAAA 2001:660:4401:60bb:216:3eff:fef6:5366
www IN AAAA 2001:660:4401:60bb:216:3eff:fef6:5366
michel IN AAAA 2001:660:4401:60bb:216:3eff:fef6:5366
@ IN A 193.48.57.164
@ IN AAAA 2001:660:4401:60bb:216:3eff:fef6:5366
Puis on créer le fichier définissant la zone inverse pour la résolution des adresses IP, 57.48.193.in-addr.arpa :
$TTL 604800
@ IN SOA ns.zegbicho.lol. root.zegbicho.lol. (
2015102001 ;serial
14400 ;refresh
3600 ;retry
604800 ;expire
10800 ;minimum
)
57.48.193.in-addr.arpa. IN NS ns.zegbicho.lol.
57.48.193.in-addr.arpa. IN NS ns6.gandi.net.
164 IN PTR zegbicho.lol.
On modifie ensuite le fichier de configuration /etc/bind/named.conf.local, dans lequel on ajoute les zones :
zone "zegbicho.lol" {
type master;
file "/etc/bind/zones/db.zegbicho.lol.signed";
allow-transfer { 217.70.177.40; };
notify yes;
};
zone "57.48.193.in-addr.arpa" IN {
type master;
file "/etc/bind/zones/57.48.193.in-addr.arpa";
allow-transfer { 217.70.177.40; };
};
On finit avec la sécurisation DNS avec DNSSEC: On remarque que le fichier référencé dans /etc/bind/named.conf.local est
/etc/bind/zones/db.zegbicho.lol.signed
Ce fichier est créé après la signature de la zone, mais nous devons tout d'abord réaliser quelques manipulations.
DNSSEC est un protocole de sécurisation du protocole DNS. Celui-ci a pour but de signer les informations publiées grâce à un jeu de clés chiffrées.
On crée donc 2 clés : une Key Signing Key (KSK) et une Zone Signing Key (ZSK). Pour accélérer la génération nous utilisons l'option -r /dev/urandom qui permet d'utiliser une génération pseudo-aléatoire au lieu d'une génération /dev/random par défaut.
Génération de la KSK :
dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE zegbicho.lol
Génération de la ZSK :
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE zegbicho.lol
On obtient donc 4 clés. En effet, à chaque génération de clé, on obtient une clé publique et une clé privée. Pour s'y retrouver, on renomme ces clés et on les place dans un dossier qu'on créer : /etc/bind/zegbicho.lol.dnssec
Ces clés (les deux clés publiques) sont référées dans le fichier de zone db.zegbicho.lol :
$include /etc/bind/michay.lol.dnssec/zegbicho.lol-ksk.key $include /etc/bind/michay.lol.dnssec/zegbicho.lol-zsk.key
On va ensuite sur gandi.net dans la rubrique "gérer DNSSEC" et on leur fourni les deux clés publiques KSK et ZSK. Il peut alors les propager.
Finalement, on signe la zone avec la commande suivante :
dnssec-signzone -o zegbicho.lol -k zegbicho.lol.dnssec/zegbicho.lol-ksk zones/db.zegbicho.lol zegbicho.lol.dnssec/zegbicho.lol-zsk
Cette commande va créer le fichier /etc/bind/zones/db.zegbicho.lol.signed qu'on réfère dans le fichier de configuration /etc/bind/named.conf.local
On finit alors par créer et éditer le fichier de cofiguration des options : /etc/bind/named.conf.options :
options {
dnssec enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
listen-on-v6 {any;};
};
Vérification de la fonctionnalité de notre site
On entre l'URL zegbicho.lol, qui est automatiquement redirigée vers https://zegbicho.lol
On remarque que le certificat est valide.
La page est uniquement accessible en https car nous avons modifié le fichier de confguration etc/apache2/sites-available/000-default.conf:
<VirtualHost *:80> ..... Redirect permanent / https://zegbicho.lol .... </VirtualHost>
On test également notre configuration avec l'outil DNSSEC de l'outil https://www.zonemaster.fr/ et on remarque que le DNSSEC est validé/actif.
Le site web réalisé est donc sécurisé !
Wifi
Tests d'intrusion par cassage de clé WEP
Pour ce faire, on passe l'interface Wifi en mode monitor :
airmon-ng start wlan0
On affiche ensuite le trafic Wifi visible à l'aide de la commande :
airodump-ng mon0
Une fois notre point d'accès repéré, on procède à un échange de données avec le point d'accès qui nous intéresse (cracotte04) :
airodump-ng --essid cracotte04 --ch 7 --write out mon0
En parallèle de ce processus, on peut lancer le cassage de la clé WEP avec la commande :
aircrack-ng out-01.cap
Après quelques minutes d'attente (soit env. 66249 IVs), on obtient enfin notre clé :
KEY FOUND! [ 55:55:55:55:55:55:55:55:55:55:55:11:11 ]
Wifi : Cassage de clé WPA-PSK par force brute
Pour craquer ce type de clé, il faut trouver un moyen un peu plus complexe car aircrack n'est pas capable de trouver la clé par ses propres moyens. Il est nécessaire de lui fournir un dictionnaire contenant la clé de réseau pour espérer pouvoir s'y connecter. Nous avons donc commencé par générer un dictionnaire comprenant cent millions de clés (tous les nombres à 8 chiffres : 00000000 à 99999999). Nous avons pour cela créé un petit code C :
#include <stdio.h>
#include <stdlib.h>
int main(){
int i=0;
FILE* dico = fopen("dictionnaire.txt","w+");
for(i=0;i<=99999999;i++){
fprintf(dico, "%08d\n", i);
}
fclose(dico);
return 0;
}
On passe l'interface Wifi en mode monitor :
airmon-ng start wlan0
On affiche ensuite le trafic Wifi visible à l'aide de la commande :
airodump-ng mon0
Une fois notre point d'accès repéré, on procède à un échange de données avec le point d'accès qui nous intéresse (cracotte04) :
airodump-ng --essid cracotte04 --ch 12 --write crackage_wpa-psk.txt mon0
On peut ensuite lancer le cassage de la clé WPA-PSK en référant notre dictionnaire créé précédemment avec la commande :
aircrack-ng -w dictionnaire.txt crackage_wpa-psk.txt-02.cap
Le test des clés se fait à une vitesse moyenne de 3700 clés par seconde.
Après quelques minutes d'attente , on obtient enfin notre clé :
Sécurisation des données
- On crée les trois partitions LVM de 1Go :
lvcreate -L 1G -n /dev/virtual/ima5-karmeliet-raid1 -v lvcreate -L 1G -n /dev/virtual/ima5-karmeliet-raid2 -v lvcreate -L 1G -n /dev/virtual/ima5-karmeliet-raid3 -v
- On ajoute les partitions dans le fichier de configuration :
disk = [
'file:/usr/local/xen/domains/levrette/disk.img,xvda2,w',
'file:/usr/local/xen/domains/levrette/swap.img,xvda1,w',
'phy:/dev/virtual/ima5-karmeliet-home,xvdc,w',
'phy:/dev/virtual/ima5-karmeliet-var,xvdb,w',
'phy:/dev/virtual/ima5-karmeliet-raid1,xvdd,w',
'phy:/dev/virtual/ima5-karmeliet-raid2,xvde,w',
'phy:/dev/virtual/ima5-karmeliet-raid3,xvdf,w',
]
- Puis, on crée le RAID5 logiciel à l'aide de la commande:
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf
- Pour vérifier que notre md0 a été correctement créé, on exécute la commande:
cat /proc/mdstat
On obtient :
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[2] xvde[1] xvdd[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
- Et pour vérifier notre RAID5 logiciel avec les trois partitions :
mdadm --detail /dev/md0
Ce qui donne :
Version : 1.2
Creation Time : Thu Nov 26 13:40:21 2015
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Thu Nov 26 13:49:20 2015
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : KARMELIET:0 (local to host KARMELIET)
UUID : 4bb46fbe:6292cc6b:5fdccfcc:a4a94ae3
Events : 2
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf
Après avoir redémarré la VM, on remarque que le volume nouvellement créé nommé md0 a été remplacé par md127.
Après avoir supprimé une partition, on refait la commande :
mdadm --detail /dev/md127
Et on obtient :
Version : 1.2
Raid Level : raid0
Total Devices : 2
Persistence : Superblock is persistent
State : inactive
Name : KARMELIET:0 (local to host KARMELIET)
UUID : 4bb46fbe:6292cc6b:5fdccfcc:a4a94ae3
Events : 2
Number Major Minor RaidDevice
- 202 48 - /dev/xvdd
- 202 64 - /dev/xvde
On vérifie le volume md127 :
cat /proc/mdstat
On a :
Personalities :
md127 : inactive xvde[1](S) xvdd[0](S)
2095104 blocks super 1.2
unused devices: <none>
Cryptage des données
A l'aide de la commande suivante, on formate la carte SD de telle sorte qu'elle n'ait plus qu'une seule partition :
fdisk /dev/sdb
On crée maintenant la partition cryptée protégée par un mot de passe avec la commande :
cryptsetup luksFormat -c aes -h sha256 /dev/sdb1
Avec la commande suivante, on affiche l'état du disque crypté :
cryptsetup luksDump /dev/sdb1
On y ajoute ensuite un système de fichiers (ici au format ext3) :
cryptsetup luksOpen /dev/sdb1 karmeliet mkfs.ext3 /dev/mapper/karmeliet
Pour monter la partition :
mount -t ext3 /dev/mapper/<nom_du_disque> /mnt/
On peut ainsi lire et écrire des fichiers sur la carte SD en travaillant dans le dossier /mnt/. Après avoir fini, on démonte la carte SD avec les commandes :
umount /mnt/ cryptsetup luksClose karmeliet
Lors de l'échange de cartes SD, en exécutant la commande d'ouverture du système de cryptage ('luksOpen'), un mot de passe est nécessaire pour le montage et l'utilisation de la carte. Le cryptage fonctionne !
Authentification et serveur RADIUS
FreeRadius
Nous commençons par la configuration d'un serveur FreeRadius sur notre VM pour sécuriser le WiFi par WPA2-EAP. On travaille dans le dossier :
apt-get install freeradius cd /etc/freeradius
Il nous faut rajouter un nouvel utilisateur qui nous servira pour authentification sur le réseau WiFi. Pour cela, on rajoute une ligne dans le fichier users :
zegbicho Cleartext-password := "ima15"
On édite ensuite le fichier client.conf et on y ajoute :
client E304 {
ipaddr = 10.10.10.1
netmask = 32
secret = password
}
client E306 {
ipaddr = 10.10.10.2
netmask = 32
secret = password
}
client VLAN14 {
ipaddr = 172.20.14.0
netmask = 24
secret = password
}
On configure aussi le fichier eap.conf pour utiliser le PEAP-MSCHAPv2. On édite donc ce fichier et on change le type de méthode :
- default_eap_type = peap
- Dans peap : default_eap_type = mschapv2
eap {
default_eap_type = peap
peap {
default_eap_type = mschapv2
}
}
Sécurisation WiFi WPA2-EAP
Configuration de la borne
Une fois notre configuration sur la machine xen réalisée, on configure la borne WiFi. Le but est de faire en sorte que l'accès à la borne soit controlé par WPA2-EAP. On ajoute à la configuration du point d'accès Wifi un SSID protégé par la méthode WPA2-EAP.
On se connecte en telnet à la borne WiFi en 10.10.10.1 avec les identifiants Cisco/Cisco :
apt-get install telnet telnet 10.10.10.1
conf t aaa new-model aaa authentication login eap_karmeliet group radius_karmeliet radius-server host 193.48.57.164 auth-port 1812 acct-port 1813 key password aaa group server radius radius_karmeliet server 193.48.57.164 auth-port 1812 acct-port 1813 ! exit dot11 ssid SSID_KARMELIET vlan 14 authentication open eap eap_karmeliet authentication network-eap eap_karmeliet authentication key-management wpa mbssid guest-mode ! exit interface Dot11Radio0 encryption vlan 14 mode ciphers aes-ccm tkip ssid SSID_KARMELIET exit interface Dot11Radio0.14 encapsulation dot1Q 14 no ip route-cache bridge-group 14 bridge-group 14 subscriber-loop-control bridge-group 14 spanning-disabled bridge-group 14 block-unknown-source no bridge-group 14 source-learning no bridge-group 14 unicast-flooding exit interface GigabitEthernet0.14 encapsulation dot1Q 14 bridge-group 14 exit
On réitère l'opération sur la borne située en E306 à l'adresse 10.10.10.2
Test sur l'eepc
Configuration de l'eepc /etc/network/interfaces :
auto wlan0 iface wlan0 inet static address 172.20.14.12 netmask 255.255.255.0 gateway 172.20.14.254 wpa-ssid SSID_KARMELIET wpa-key-mgmt WPA-EAP wpa-identity zegbicho wpa-password ima15
On regarde sur notre VM si cela fonctionne : en mode debug sur le RADIUS :
service freeradius stop /usr/sbin/freeradius -X
Validé !
PCBX
Après avoir installé 'asterisk' à l'aide de apt-get, on configure le fichier /etc/asterisk/sip.conf en y ajoutant cela :
[general] hasvoicemail = yes hassip = yes hasiax = yes callwaiting = yes threewaycalling = yes callwaitingcallerid = yes transfer = yes canpark = yes cancallforward = yes callreturn = yes callgroup = 1 pickupgroup = 1 nat = yes [1001] type=peer host=dynamic dtmfmode=rfc2833 disallow=all allow=ulaw fullname = zegboy username = zegboy secret = coucou1 context = work [1002] type=peer host=dynamic dtmfmode=rfc2833 disallow=all allow=ulaw fullname = tibeechaw username = tibeechaw secret = coucou2 context = work
Ensuite, on ajoute dans le fichier /etc/asterisk/extensions.conf :
[work]
exten => _1XXX,1,Dial(SIP/${EXTEN},20)
exten => _1XXX,2,Hangup()
Après avoir connecté nos téléphones (Android) au spot Wi-Fi SSID_KARMELIET, on utilise l'application CSipSimple et on y ajoute un compte sur chaque téléphone sur le modèle suivant (exemple pour l'utilisateur 1001) :
Nom du compte : zegboy Utilisateur : 1001 Serveur : 172.20.14.6 //Adresse IP de l'EeePC sur lequel est installé Asterisk Mot de passe : coucou1
Ainsi, on obtient un résultat correct puisqu'on a bien sur nos deux téléphones une communication par voie IP.
/*Image à venir*/
