Chaque année, l’Amicale de mon lieu d’études organise une LAN-party. Jusqu’à présent les étudiants amicalistes organisaient cette dernière à « l’arrache » et les résultats étaient assez variables. Cette année était à notre tour de l’organiser. Nous voulions donc changer les mauvaises habitudes et réaliser quelque chose de plus élaboré. Je vais ici vous parler de tout ce que nous avons mis en place afin de réaliser la soirée, du site internet jusqu’au câblage. Je vais me concentrer plus sur l’aspect technique de la soirée, la mise en place des serveurs et leurs configurations. Ceci n’est pas un tutoriel.

Détails de la soirée

• Capacité: 50 personnes prévues, 80 maximum,
• Lieu: dans une des salles de cours de l’université,
• Réseau: >300Mbit vers internet par le réseau de notre campus, dont uniquement 100Mbit disponible à notre prise,
• Matériel à disposition
  • 2 PC avec 2 NIC gigabit pour chacun,
  • 3 switchs Cisco Catalyst 3750G 24 ports gigabit cuivre + 4 uplinks SFP,
  • 8 switchs Cisco Catalyst 2960 8 ports 100M cuivre + 1 uplink RJ45 ou SFP,
  • tous les petits trucs: câbles ethernet, multiprises, etc.

L’un des 2 PC fourni fait office de routeur, l’autre de serveur de fichier et de jeu. Nous avons mis en place un site internet donnant toutes les informations concernant la soirée. Les joueurs peuvent également s’inscrire par le biais de ce même site internet. Ce site web est hébergé sur un serveur externe mis en place pour l’occasion. Les informations et discussions concernant la soirée ont également circulé sur le serveur Discord de la section. Un camarade a également réalisé une affiche pour promouvoir la soirée.

Première étape: le site web

Un peu plus d’un mois avant l’événement, nous avons réalisé un site web reprenant toutes les informations concernant la soirée ainsi qu’un formulaire d’inscription. Réalisation pas très complexe, le site enregistre le formulaire dans une base de données et envoie un mail à l’utilisateur pour qu’il confirme son adresse mail. La soirée étant réservée aux membres de l’université, une vérification du nom de domaine de l’adresse mail par expression régulière nous permet d’écarter les « intrus ».

La partie statique du site a été réalisé avec amour par notre ami Romain Thomann, qui a également contribué à l’affiche et à toutes les photos de la soirée que vous pouvez retrouver tout au long de cet article.

Serveur physique

Bon ce n’est pas réellement un serveur physique, mais plutôt une machine virtuelle hébergée sur le public cloud Scaleway. Nous avons instancié une VM Debian 8 et y avons installé le serveur web Apache, le moteur de base de données MariaDB (fork de MySQL), le MTA Postfix et le serveur RADIUS FreeRADIUS (qu’on verra plus tard). J’ai connecté cette VM au reste de mon infra perso via un lien VPN (cette infra ne fera pas l’objet de ce post). La configuration par défaut pour chaque logiciel fait très bien l’affaire.

Quelques précisions de sécurité: il faut faire attention sur quels ports et IP les différents daemons écoutent. Un netstat -nlp permet de voir qui écoute sur quoi. Des coups de règles iptables permettent de fermer les ports indésirés. L’installation de fail2ban permet également de limiter les possibles attaques.

Autre petit point de sécurité: j’ai désactivé l’accès au serveur par mot de passe. Je n’y ai donc accès que par clé SSH. Je m’authentifie en général soit par clé SSH, soit par mot de passe + TOTP, mais pour ce serveur j’ai complètement désactivé l’authentification par mot de passe.

Nom de domaine

Nous avons pris un nom de domaine pour l’occasion: rt-colmar.ovh. Je n’ai pas voulu d’excentricité, un simple domaine chez OVH à 1€/an suffit amplement pour ce qu’on voulait faire.

Le domaine obtenu, il a fallu maintenant le configurer. Une configuration assez simpliste, mais qui contient le nécessaire pour le bon fonctionnement du site. J’y ai mis notamment un enregistrement SPF pour l’authentification des mails, sans aller pour loin (enregistrement DMARC, DKIM, etc.). A noter que les mails partant vers les serveurs d’Outlook passeront systématiquement aux SPAM tant que les IP expéditeurs ne sont pas explicitement whitelistées. Voici la zone ci-dessous:

$TTL 300
@	IN SOA dnsX.ovh.net. tech.ovh.net. (2033023199 86400 3600 3600000 300)
; Nameservers
					IN NS		dnsX.ovh.net.
					IN NS		nsX.ovh.net.

; Mail		 
					IN MX 1		redirect.ovh.net.
					IN TXT		"v=spf1 a mx include:mx.ovh.com ~all"

; Hosts
					IN A		1.2.3.4
					IN AAAA		2001:XXXX:YYYY:Z::dead:beef
vod					IN A		1.2.3.4
vod					IN AAAA		2001:XXXX:YYYY:Z::dead:beef
www					IN A		213.186.33.5
www					IN TXT		"1|rt-colmar.ovh"

; VPN
int					IN CNAME	b.rt-colmar.exch.int.pingex.net.
lan					IN CNAME	b.lanrt.exch.int.pingex.net.

Base de données

Une base de données est associée au site et ne comprend qu’une seule table. Cette table contient les données des joueurs: leur nom, mail, mot de passe, IP et date d’inscription, etc.

Explication des différents champs:

• mdp: hashé SHA1,
• qualification: champ custom pour des précision sur la personne et visible uniquement des admins,
• token: token de confirmation mail,
• ip: IPv4 ou IPv6,
• isctimestamp: date et heure d’inscription,
• streamkey: devait être à l’origine utilisée avec un serveur RTMP afin que les joueurs puissent streamer leur écran sur le projo de la salle avec OBS ou XSplit. L’idée n’a été au final pas mise en place faute de temps,
• admin: non utilisé,
• enabled: vaut 0 lorsque le compte est en attente d’activation, -1 lorsque le compte est administrativement désactivé et 1 lorsque le compte est activé.

PHP

La partie dynamique du site a été créé avec PHP et est structuré en deux parties: un répertoire privé contenant différentes classes PHP pour les interactions avec la base de données, RADIUS, fonctions de crypto, etc. On trouve également un répertoire public contenant les ressources CSS/JS et les scripts PHP générant les pages.

Nous avons souhaité rester dans la simplicité et avons évité l’utilisation de frameworks ou libraires externes. Le code source se trouve sur un dépôt Git (pour l’instant privé, mais cela peut toujours évoluer).

FreeRADIUS

Le serveur RADIUS permet l’authentification des utilisateurs par rapport une base de données d’utilisateurs et groupes: MySQL, LDAP, etc. Il s’agit de la partie la plus complexe a gérer. Nous avons configuré le serveur RADIUS afin d’utiliser une autre base de données MySQL en backend, car les bases de RADIUS et du site sont incompatibles. Nous avons donc du réaliser un script permettant la synchronisation entre les deux bases.

Un serveur RADIUS étant très difficile à configurer, je ne vais pas détailler sa configuration ici. Il faut juste savoir qu’il s’agit d’une installation standard avec un backend MySQL classique. Le portail captif du routeur de la LAN est configuré en tant qu’agent auprès du serveur RADIUS.

PHP x RADIUS

Il existe donc 2 bases de données distinctes qu’il faut synchroniser. Nous utilisons un script PHP pour faire le boulot. Ce script est appelé en ligne de commande avec sudo -Hu www-data php /path/to/radius.php et est programmé pour tourner de manière régulière avec cron. Le script fonctionne selon le principe suivant:

• Vide la base de données RADIUS,
• Pour chaque utilisateur activé (enabled=1):
  • Convertir le hash de son mot de passe en base64 utilisable par RADIUS,
  • Ajoute son entrée dans la table radcheck,
  • Donne une confirmation d’ajout sur la sortie standard.
• Donne le nombre d’utilisateurs ajoutés dans radcheck sur la sortie standard.

Voici le script en entier:

<?php
require_once "routines.php";
Routines::init();
SQLManager::initRad();

echo "Emptying the RADIUS Table.\n";
SQLManager::radTruncate();

echo "Repopulating\n";
$i=0;
foreach(SQLManager::getAllEnabled() as $user)
{
	echo $user['mail'] . "\n";
	SQLManager::radAdd($user['mail'], $user['mdp']);
	$i++;
}
echo "Done. Populated $i users.\n";
exit;

// La fonction de conversion du SHA
function hex_to_base64($hex)
{
	$return = '';
	foreach(str_split($hex, 2) as $pair)
		$return .= chr(hexdec($pair));
	return base64_encode($return);
}

Cela donne dans la table radcheck des entrées similaires à celle-ci:

Deuxième étape: le réseau

Comme spécifié précédemment, nous disposons de trois grands switchs pour la « backbone » et de huit switchs plus petits pour couvrir d’éventuelles zones blanches. Nous n’avons pas de réseau wifi en place. Le principal défi maintenant est de gérer la topologie et l’architecture du réseau de manière à avoir une qualité de service constante, une bande passante suffisante pour tout le monde tout en maintenant une certaine sécurité sur l’ensemble du réseau.

Topologie physique

Il s’agit globalement d’une architecture réseau en étoile avec une redondance entre les deux switchs secondaires. sw0 est le switch primaire au niveau de spanning-tree. Quelques détails supplémentaires:

• spanning-tree est configuré sur tous les switchs, sw0 ayant la priorité la plus élevée et est donc le switch root.
• Les liens sw0-sw1, sw0-sw2 et sw0-nas sont en agrégation de lien 2*1Gbit=2Gbit passif (sans LACP), distribution par hashage L2+L3 dst-src.
• Le lien sw1-sw2 est bloqué par spanning-tree et sert uniquement de redondance au cas où l’un des liens entre sw1/2 et sw0 viendrait à tomber.
• Les participants peuvent se connecter sur n’importe quel switch avec des ports attribués aux joueurs.
• Les liens sont forcés à 100M pour les participants afin de mieux partager la bande passante entre les switchs.
• Le lien VPN remonte du routeur à mon infra perso et contacte le serveur RADIUS par routage. Ce lien sert également à la supervision de l’infrastructure des équipements de la LAN à distance.
• Il est fait usage de RIP afin de partager les routes avec le reste de l’infrastructure VPN.

VLAN et IP

Nous utilisons deux VLAN pour chaque trafic:

• VLAN 10 « PROD » 10.192.28.0/24: trafic joueur, isolation de ce VLAN par rapport aux autres VLAN (pas de routage inter-VLAN), limitation de bande passante par participant.
• VLAN 20 « ADM » 10.192.29.0/25: trafic administration des switchs et du NAS, routage VPN, pas de limitation de bande passante.

Les VLAN 10 à 20 sont accessibles sur tous les switchs. Même si nous n’utilisons que 2 VLAN, l’utilisation d’un range nous permet de rajouter d’autres VLAN sans devoir reconfigurer les autres switchs. L’université ayant refusé de nous déléguer un préfixe IPv6, il était prévu de passer un /60 pris d’un /56 de l’un de mes serveurs via un tunnel protocole 41. Le tunnel n’a au final pas été monté, faute de temps.

Configuration des switchs

Nous sommes donc face à des switchs de la gamme Catalyst de chez Cisco. Nous avons utilisé dans un premier temps la console série de chaque switch pour la configuration initiale. Les configurations ultérieures se sont faits in-band par telnet.

Configuration commune

On trouve ici toutes les directives communes à tous les switchs: déclaration des VLAN, directives SNMP, etc.

version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname swX
!
enable secret 5 <hash-MD5-mdp-enable>
!
no aaa new-model
clock timezone UTC+1 1
clock summer-time UTC+1 recurring last Sun Mar 2:00 last Sun Oct 3:00
ip subnet-zero
ip domain-list lan.rt-colmar.ovh
ip name-server 10.192.29.126
!
port-channel load-balance src-dst-ip
!
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
vlan 10
 name prod
vlan 20
 name adm
!
interface Vlan1
 no ip address
 no ip route-cache
 shutdown
!
interface Vlan20
 ip address 10.192.29.X 255.255.255.128
 no ip route-cache
!
ip default-gateway 10.192.29.126
ip classless
ip http server
no ip http secure-server
snmp-server community public RO
!
line con 0
line vty 0 4
 no login
line vty 5 15
 login
!
ntp clock-period 36029324
ntp server 10.192.29.126 prefer

Certains switchs ne disposent pas des fonctionnalités de cryptographie. De ce fait certaines directives telles que ip http secure-server ou feature ssh ne fonctionneront pas. Il est possible de vérifier la présence des fonctions de cryptographie avec la présence de « k9 » dans les identifiants des firmwares.

Configuration spécifique à sw0

sw0 joue le rôle de switch central. Nous devons donc ajuster la priorité spanning-tree de ce switch afin que tout le trafic converge vers ce dernier. Le protocole STP fonctionne indépendamment pour chaque VLAN.

spanning-tree vlan 10-20 priority 24576

Configuration des ports

Les différents ports doivent être configurés selon qu’ils jouent le rôle d’uplink/downlink au backbone ou de port d’accès au joueur. Voici les différentes directives pour chaque cas.

Trunk de backbone

interface GigabitEthernet1/0/9
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 10-20
 switchport mode trunk
 switchport nonegotiate

La directive switchport nonegociate permet d’empêcher qu’un port access devienne trunk à cause d’un switch intrus et vice versa. Cela accroît la sécurité du réseau.

Trunk avec agrégation de lien

interface Port-channel1
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 10-20
 switchport mode trunk
 switchport nonegotiate
!
interface GigabitEthernet1/0/1
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 10-20
 switchport mode trunk
 switchport nonegotiate
 channel-group 1 mode on
!
interface GigabitEthernet1/0/2
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 10-20
 switchport mode trunk
 switchport nonegotiate
 channel-group 1 mode on

Similaire à un trunk classique, à l’exception de la directive supplémentaire channel-group qui permet de spécifier que ce port est membre d’une agrégation de liens. Si il existe plusieurs groupe de liens agrégés, il faut prendre soin d’incrémenter le 1 à Port-channel1 et channel-group 1 mode on.

Trunk vers serveur

interface GigabitEthernet1/0/5
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 10
 switchport trunk allowed vlan 10-20
 switchport mode trunk
 switchport nonegotiate
 spanning-tree portfast

Encore une fois similaire à un trunk classique, à l’exception qu’on spécifie un vlan natif en plus (non taggé) afin que le serveur puisse se connecter même si son réseau n’est pas configuré correctement. On trouve aussi spanning-tree portfast qui nous permet d’éviter de bloquer le port durant les 30 premières secondes à cause de l’écoute du port initial.

Port d’accès joueur

interface GigabitEthernet1/0/13
 switchport access vlan 10
 switchport mode access
 switchport nonegotiate
 speed 100
 spanning-tree portfast

On force le lien à 100M avec speed 100 si le port est gigabit. On peut omettre cette directive si le port ne l’est pas. On peut également modifier le VLAN à 20 si on souhaite que le port soit plutôt administratif.

Remise à zéro du switch

Les switchs n’ayant que été prêtés, il faut les ramener avec une configuration à blanc. Voici quelques directives simples pour remettre un switch au propre:

write erase
delete flash:vlan.dat
!
! Vous pouvez également supprimer tous les fichiers en .renamed
! qui ne sont pas utiles si vous voulez un switch encore plus propre
delete flash:?

Câblage et installation

Nous avons à disposition des câbles patch Cat. 6 SFTP de plusieurs dizaines de mètres pour les liens de backbone. Nous avons également utilisé des adhésifs afin de différencier les câbles parmi la montagne de câbles. Vu qu’il s’agit d’un câblage temporaire, nous avons utilisé de l’adhésif aluminium pour les sécuriser au sol et pour éviter que les gens se prennent les pieds dedans.

Troisième étape: le routeur

Le routeur utilisé pour la soirée est une distribution de firewall basée sur FreeBSD appelée pfSense. Complet et puissant, ce dernier nous permet de mettre en place facilement et rapidement une configuration complète, de la liaison VPN jusqu’au portail captif, en passant par la gestion des VLAN et des règles de pare-feu.

Configuration des interfaces

Le routeur dispose de deux interfaces physiques. L’une d’elles est connectée au réseau de l’IUT, tandis que l’autre sur un trunk serveur de sw0. Sur pfSense les liens VPN et VLAN représentent une interface à part. Nous avons donc configuré au total 4 interfaces: l’interface externe, 2 VLAN et le VPN.

Firewall

Nous avons décidé de configurer le pare-feu de la manière suivante:

• Aucun accès depuis WAN vers l’intérieur,
• Le réseau LAN doit être isolé des autres réseaux et doit avoir accès à internet avec une limite de bande passante de 4 Mbit/IP,
• Le réseau ADM doit pouvoir communiquer librement avec le réseau VPN et vice-versa, ainsi qu’avoir accès à internet librement sans restriction de bande passante,
• Tout le monde (sauf WAN) doit pouvoir accéder aux services fournis par le routeur.

pfSense répartit les règles de pare-feu en 2 grandes catégories: les règles « flottantes » et les règles pour chaque interface. Les règles flottantes permettent d’appliquer une règle dans les 2 sens de communication, sur plusieurs interfaces à la fois et est utilisé pour le traffic shaping. Les règles par interface permettent juste de filtrer le trafic en entrée de leurs interfaces respectives.

La seule règle flottante est celle qui permet d’accéder au pare-feu depuis toutes les interfaces, sauf « WAN ». Cette règle est marqué « quick » afin qu’elle passe en priorité par rapport aux autres règles définies.

Dans le réseau LAN, on fait passer le trafic vers toutes les IP, sauf les RFC1918 (les réseaux non routables sur internet). Cela exclut donc les autres réseaux privés, dont ADM et VPN. De même sur ADM on autorise le trafic vers internet, mais une règle supplémentaire permet également de faire passer le trafic vers le reste du préfixe VPN (10.192.16.0/20).

Les règles pour l’interface VPN sont un peu particulières: on autorise tout d’abord le trafic vers le réseau ADM, ainsi que vers le pare-feu lui-même. Cette dernière règle est redondante avec la règle flottante définie précédemment. On ajoute également une autre règle autorisant le trafic multicast. Cette règle est notamment utile pour le protocole de routage RIP qui utilise le multicast sur 224.0.0.9.

Services réseau (DHCP, DNS, etc.)

DHCP

Le serveur DHCP de pfSense nous permet de configurer automatiquement les machines présentes sur le réseau de la LAN. Il n’y a aucune configuration particulière pour le réseau LAN principal. Les leases sont attribués de 10.192.28.1 à 10.192.28.200, gardant les quelques dernières adresses pour des appareils spécifiques (NAS ou le routeur lui-même) configurés de manière statique ou ayant un mapping statique au niveau du serveur DHCP.

Le serveur DHCP du côté ADM fonctionne de la même manière, à l’exception près que le pool est plus restreint principalement à cause du fait que les appareils interagissant avec ce VLAN sont en général connus et disposent de mappings statiques. On peut également au besoin activer l’option « Deny unknown clients » pour un peu plus de sécurité.

DNS

pfSense dispose au choix d’un serveur DNS ou d’un forwardeur. Nous avons choisi d’utiliser le serveur DNS complet. Ce dernier à l’avantage d’aller chercher ses réponses directement auprès des serveurs root, au contraire du forwardeur qui va simplement retransmettre les requêtes aux serveurs de l’Université.

Vous n’êtes pas obligé d’utiliser le serveur complet, le forwardeur peut très bien suffire. Question de goût. A noter cependant que si vous utilisez le forwardeur, le serveur DNS à qui vous forwardez les requêtes pourra potentiellement vous espionner car il aura connaissance de tous les domaines qui auront été résolus.

OpenVPN et RIP

Le serveur RADIUS se trouvant sur un serveur externe au réseau de la LAN et n’étant pas un protocole « sécurisé » par défaut, il a fallu relier le routeur et le serveur entre eux par un lien VPN. Disposant d’une infrastructure VPN perso existante, il n’aura pas fallu énormément d’efforts pour intégrer les 2 machines dans mon réseau. Cette infrastructure VPN fera l’objet d’un autre article.

Les 2 machines sont reliées entre eux par le point central de mon infrastructure qui relie également mes autres équipements. Cela me permet de gérer les équipements de la LAN à distance, au travers de l’infrastructure VPN.

OpenVPN

OpenVPN est un logiciel VPN bien connu et supporté par pfSense et d’autres distributions. On aurait pu faire usage d’IPSec ou de n’importe quel protocole du même esprit, cependant OpenVPN est le plus simple à mettre en place et à maintenir. Je vais donner ici la configuration du lien point-à-point entre le routeur et le nœud agrégateur. La configuration entre l’agrégateur et le serveur web est très similaire.

dev landnlnk
dev-type tap
secret landnlnk.key
port 6949

keepalive 10 60
persist-tun
persist-key
cipher AES-128-CBC
auth SHA1
comp-lzo no

ifconfig 10.192.31.9 255.255.255.252

Vu que nous faisons un simple tunnel entre deux hôtes spécifiques, il n’est pas nécessaire de créer une CA ou d’utiliser la directive server. On génère la clé statique avec sudo openvpn –genkey –secret landnlnk.key. Cette même clé devra être utilisée des 2 côtés du tunnel.

Se pose ensuite la question de choisir entre les deux drivers tun et tap pour le tunnel. La différence entre les 2 réside dans le fait que tun crée un tunnel L3 (IP) et ne fonctionne donc qu’en point-à-point avec le serveur (comme PPPoE). L’IP à l’autre bout du tunnel est connu à l’avance et le réseau du tunnel utilise en général un /30 IPv4. tap de son côté émule un réseau L2 (Ethernet) et peut donc faire passer tout trafic Ethernet classique: ARP, mcast, bcast, etc. Le tunnel peut être donc bridgé en L2 avec un réseau physique afin de l’étendre ailleurs. L’inconvénient est la présence d’un certain overhead à cause des en-têtes ethernet et le surplus de signalisation (ARP, etc.).

Pour en revenir à notre lien routeur-agrégateur, nous avons choisi un tunnel tap qui permet de faire passer les multicasts que génère RIP. RIP peut être utilisé en unicast, autorisant ainsi l’utilisation de tun au lieu de tap. Cependant je ne pouvais pas configurer le daemon RIP du côté du routeur pour utiliser unicast.

La configuration du tunnel côté routeur se fait simplement via le webConfigurator.

RIP

RIP est le protocole de routage me permettant de partager et de propager les différentes routes au sein de mon réseau VPN. Cela me simplifie la maintenance des routes et me permet d’ajouter de nouveaux sous-réseaux sans devoir réajuster toutes les routes. La pfSense de la LAN déclare les réseaux qu’elle gère au reste du réseau VPN via son proche VPN (ici l’agrégateur) afin de pouvoir accéder aux ressources extérieures au réseau de la LAN (le RADIUS notamment), et inversement.

La mise en place du daemon RIP sur l’agrégateur se fait via le paquet Quagga qui comprend également tous les autres protocoles de routage le plus utilisés (OSPF, BGP, etc.). Sa configuration est la suivante (dans /etc/quagga/ripd.conf):

hostname aggregator.pingex.net_RIP
password enable_password
!
router rip
 version 2
! Routes à redistribuer
 redistribute connected
 redistribute kernel
! Réseaux sur lesquelles seront envoyés les informations de routage
 network nasptp
 network hostvpn
 network landnlnk
 neighbor 10.192.31.18
 network homepf
! Filtrage des routes entrantes et sortantes
 distribute-list private-only out
 distribute-list private-only in
! La ligne suivante permet d'exclure l'interface publique de Scaleway
access-list private-only deny 10.2.XXX.YYY/31
! Permet de ne partager que les IP se trouvant dans 10.0.0.0/8
access-list private-only permit 10.0.0.0/8
access-list private-only deny any
access-list match-all permit any

Ne pas oublier d’activer zebra et ripd dans /etc/quagga/daemons.

L’activation de RIP dans pfSense se fait au moyen du paquet routed disponible dans le gestionnaire de paquets de pfSense. Sa configuration se fait dans Services > RIP. A remarquer cependant que les options disponibles sont relativement limitées, on ne pourra donc pas faire énormément avec.

Portail captif

Afin de gérer l’authentification des utilisateurs, nous avons mis en place un portail captif par lequel les utilisateurs arrivant sur le réseau doivent passer afin de pouvoir accéder à internet. Nous avons configuré le portail afin que les utilisateurs puissent s’authentifier via le serveur RADIUS mis en place. Les utilisateurs sont automatiquement déconnectés au bout de 6 heures d’inactivité et sont limités à 4 Mbit/s de bande passante. Nous avons également une page d’authentification personnalisée. La configuration est détaillée ci-dessous.

Captive Portal Configuration

• Interfaces: LAN (même si le portail est censé tourner uniquement sur cette interface, les autres interfaces se font quand même bloquer à cause de ça, voir plus bas)
• Idle timeout: 360 minutes
• Logout popup window: coché (affiche une popup pour la déconnexion, totalement optionnelle)
• After authentication Redirection URL: https://rt-colmar.ovh (sur quelle URL renvoyer après l’authentification de l’utilisateur)
• Concurrent users login: cocher « Disable Concurrent users login »
• Per-user bandwidth restriction: enable (c’est ici qu’on définit les restrictions de bande passante pour chaque utilisateur)
  • Download: 4 Mbit/s
  • Upload: 4 Mbit/s

Authentication

• Authentication method: RADIUS Authentication
• RADIUS protocol: PAP

Primary Authentication Source

• Primary RADIUS server
  • IP: 10.192.31.XXX (l’IP du serveur web/RADIUS)
  • Port: laisser par défaut (port 1812)
  • RADIUS shared secret: celui définit lors de la config de FreeNAS
• Secondary RADIUS server
  • Laisser vide si aucun RADIUS redondant

Secondary Authentication Source

• Laisser vide

Accounting

• Désactivé

RADIUS Options

• Reauthentication: coché (permet de déconnecter un utilisateur automatiquement si son compte a été désactivé au niveau du RADIUS)
• RADIUS MAC Authentication: décoché (permet de réaliser l’authentification via l’adresse MAC de l’utilisateur)
• RADIUS NAS Attribute: choisir l’interface VPN (l’interface depuis laquelle la demande RADIUS sera émise)

HTML Page Contents

Cette section permet d’upload une page HTML personnalisée pour le portail captif. Les ressources supplémentaires (CSS, images) peuvent être upload par l’onglet « File Manager ».

Le problème des autres interfaces

Curieusement le portail captif bloque également l’accès internet sur les autres interfaces. Il faut donc autoriser toutes les autres réseaux internes gérés par la pfSense (sans restriction de bande passante).

Résultat

Les utilisateurs accédant à un site internet non HTTPS seront automatiquement redirigés sur le portail captif pour authentification. Une tentative d’accès à un serveur web en HTTPS ne fonctionnera pas (le serveur ne répondra pas). Le portail captif ne redirigera pas automatiquement en HTTPS. A noter que les versions récentes des navigateurs et OS vont automatiquement avertir de la présence du portail et au besoin ouvrir la fenêtre d’authentification. A noter également que si un utilisateur fait usage d’un serveur DNS externe, ce dernier ne pourra rien résoudre tant qu’il ne sera pas identifié. Cela lui donnera des erreurs « serveur non trouvé ». Les utilisateurs authentifiés peuvent être trouvés dans Status > Captive Portal.

Monitoring

Le serveur NAS s’occupe également de monitorer les différents équipements réseau. Nous tirons profit de l’agent SNMP présent sur chaque switch et sur le routeur afin d’avoir des statistiques d’utilisation par port et pour chaque équipement.

Nous utilisons le grapheur munin et son support de SNMP pour tirer les statistiques des équipements. L’ajout d’un équipement SNMP se fait comme suit:

# Configurez chaque hostname dans /etc/hosts au besoin
sudo munin-node-configure --shell --snmp sw0.lan.rt-colmar.ovh
sudo munin-node-configure --shell --snmp sw1.lan.rt-colmar.ovh
sudo munin-node-configure --shell --snmp router.lan.rt-colmar.ovh
# ...

# Relancer munin-node
sudo service munin-node restart

Cette commande retourne des commandes bash à copier-coller afin d’ajouter les différents graphes. A noter que seuls les ports up seront scannés. Si entre temps d’autres ports passent en up, il faudra ré-exécuter à nouveau les commandes ci-dessus.

Il faut ensuite ajouter l’équipement dans /etc/munin/munin.conf:

[lan.rt-colmar.ovh;sw0.lan.rt-colmar.ovh]
    address 127.0.0.1
    use_node_name no
[lan.rt-colmar.ovh;sw1.lan.rt-colmar.ovh]
    address 127.0.0.1
    use_node_name no
[lan.rt-colmar.ovh;router.lan.rt-colmar.ovh]
    address 127.0.0.1
    use_node_name no

Il n’y a pas lieu de relancer un quelconque service après l’ajout des équipements dans ce dernier fichier, le master munin fonctionnant via une tâche cron.

Améliorations futures possibles

• Il manquait d’un réseau wifi pour les quelques rares personnes jouant à LoL sur leur tablette Surface. Ce réseau wifi pourrait fonctionner sur un VLAN séparé avec authentification 802.1x afin d’économiser le couple portail captif + WPA2. L’authentification 802.1x permet de garder une sécurité sur le réseau et d’oublier le portail captif car 802.1x nécessite un utilisateur/mot de passe qui sera vérifié par le même serveur RADIUS.
• Diffusion de la soirée sur le site internet. On pourrait faire cela via un serveur RTMP/HLS (par exemple MistServer), quelques caméras IP disséminées dans la salle et un logiciel de régie. On rassemble les caméras IP avec un logiciel type vMix qui nous permet également d’incorporer les écrans des joueurs. Il faut cependant un ordinateur d’une puissance conséquente pour le transcodage à la volée.

Conclusion

Cet événement nous a permis de mettre en œuvre les connaissances que nous avons acquises durant notre cursus, tout en faisant usage de nos connaissance pour une cause commune aux étudiants: une LAN. Le modèle de réseau et les configurations que nous avons mis en place sont parfaitement perfectibles et peuvent être réutilisés pour un autre événement.

Vous pouvez retrouver les photos de la soirée ici => https://romain-thomann.fr/fullscreen/soiree-lan/