RP 4 – Accès distant & Helpdesk

Le plan

Plan d'adressage

Équipement / VM	Rôle	Adresse IP	Accès distant / Identifiants
🏢 Agence El Hierro (192.168.54.0/24)
Stormshield SNS 310	Pare-feu / VPN (2FA activé)	192.168.54.254	`admin / Afpi5962!` + Code OTP (Google Authenticator)
AD/DNS/DHCP	Windows Server 2019	192.168.54.10	RDP : `Administrateur / @fpi5962!`
SRV-EL-WEB-01	Serveur Apache	192.168.54.15	SSH : `root / Afpi5962!`
SRV-EL-WEB-02	Serveur Apache	192.168.54.16	SSH : `root / Afpi5962!`
SRV-EL-PROXY	HAProxy (DMZ)	192.168.64.1	SSH : `root / Afpi5962!`
ESXi principal	Hyperviseur LAN	192.168.54.1	`root / Afpi5962!`
ESXi secondaire	Hyperviseur (Load Balancing)	192.168.69.94	`root / Afpi5962!`
TP-Link SG-3424	Switch manageable LAN	192.168.54.20	`admin / Afpi5962`
AP WiFi WA901N	Borne WiFi 802.1X	192.168.54.30	`admin / Afpi5962!`
🏢 Siège Tenerife (192.168.57.0/24)
Zimbra Mail	Messagerie	192.168.57.40	`admin@el-cicar.es / Afpi5962` 🌐 https://mail.el-cicar.es:7071 `Afpi5962!`
Centreon	Supervision SNMP	192.168.57.50	HTTPS : `admin / Centreon!123`
TrueNAS	NAS RAID-5 (sauvegardes Veeam)	192.168.57.2	📁 `el-user / Afpi5962!` 🖥️ `truenas_admin / Afpi5962!`
GLPI	Helpdesk & Inventaire	192.168.57.60	HTTPS : `glpi-admin` / À définir lors de l'installation

Schéma d'infrastructure

État des lieux technique : Représentation de l'infrastructure réseau avant déploiement des solutions d'accès distant. Le schéma détaille la segmentation par VLANs et la sécurisation par les pare-feu Stormshield.

Le projet

🖥️ 1. Accès distant centralisé — MobaXterm

MobaXterm centralise les connexions SSH (serveurs Linux), RDP (AD) et HTTPS (Stormshield) via le tunnel VPN IPsec.

📌 Appui à l'administrateur du siège : recensement des connexions et ouverture des flux.

🔌

PHOTO 1 — MobaXterm : sessions d'administration

Sessions SSH, RDP et HTTPS enregistrées pour l'agence El Hierro.

mobaxterm_sessions.png

🔐 2. Double authentification 2FA (Google Authenticator)

Pour renforcer la sécurité des accès administratifs, l'authentification à deux facteurs a été activée sur le pare-feu Stormshield SNS 310. La méthode retenue est le One Time Password (OTP) avec l'extension Google Authenticator.

⚙️

PHOTO 2 — Activation de la double authentification

Interface Stormshield : activation de la double authentification pour l'utilisateur Administrateur.
Méthode : Google Authenticator (OTP)

Capture d'écran 2026-03-30 113708.png

🔢

PHOTO 3 — Connexion avec code OTP

Page de connexion demandant le code OTP généré par Google Authenticator après saisie du mot de passe.

Capture d'écran 2026-03-30 113919.png

🌊 3. Gestion des flux — VPN IPsec

Un tunnel VPN IPsec est établi entre le Stormshield SNS 310 de l'agence El Hierro et le pare-feu du siège de Tenerife, permettant les accès distants sécurisés et les sauvegardes Veeam.

🔗

PHOTO 4 — Tunnels VPN IPsec actifs (Stormshield)

Console Stormshield SNS 310 : tunnels VPN IPsec établis entre l'agence El Hierro (192.168.54.0/24) et le siège Tenerife (Site_FW_TF).
Profil de chiffrement : StrongEncryption.

Capture d'écran 2026-03-30 085743.png

📦 4. GLPI — Inventaire et Helpdesk

GLPI installé au siège, avec GLPI_Agent sur tous les postes/serveurs pour l'inventaire automatique et la gestion des tickets.

🖥️

PHOTO 5 — GLPI : Inventaire matériel

Liste des ordinateurs remontés par GLPI_Agent.

glpi_inventory.png

⚙️

PHOTO 6 — GLPI Agent

Installation GLPI Agent.

glpi_agent.png

🧪 5. Tests des remontées et tickets

Test inventaire : nouveau poste → remontée automatique dans GLPI
Test ticket : création ticket → notification administrateur
Test workflow : traitement, changement de statut, clôture

📝 6. Procédure utilisateur helpdesk

📌 Création d'un ticket d'incident sur GLPI

Cette procédure décrit les étapes à suivre pour soumettre une demande via la plateforme GLPI, qu'il s'agisse d'un incident (dysfonctionnement) ou d'une demande de service. Toute demande doit impérativement transiter par GLPI afin de garantir un traitement structuré, un suivi efficace et une traçabilité complète.

Accès à la plateforme

Aller sur https://glpi.el-cicars.es
S'authentifier avec vos identifiants professionnels (login / mot de passe).
Depuis la page d'accueil, sélectionner l'option correspondant à votre besoin :
- « Signaler un problème » — pour tout dysfonctionnement ou incident
- « Demander un service » — pour toute demande hors panne

Choix du type de demande

Sélectionnez l'option adaptée à votre situation :

⚠ Signaler un problème

Pour tout dysfonctionnement constaté :

Application indisponible
Incident matériel
Message d'erreur

✦ Demander un service

Pour toute demande hors panne :

Demande d'accès ou de droits
Installation de logiciel
Demande de matériel

Remplissage du formulaire

Compléter l'ensemble des champs disponibles dans le formulaire :

Urgence

Sélectionner le niveau d'urgence : faible, moyenne ou élevée selon l'impact constaté.

Catégorie

Choisir la catégorie correspondant à la demande : matériel, logiciel, réseau, accès, etc.

Matériel

Sélectionner l'équipement concerné si applicable (ordinateur, imprimante, téléphone...).

Observateurs

Ajouter, si nécessaire, les personnes devant être notifiées du suivi du ticket.

Lieu

Indiquer le site ou l'emplacement géographique concerné par la demande.

Titre

Saisir un titre court et explicite. Ex : « Impossible d'accéder à l'application métier ».

Description

Décrire précisément : le problème / besoin, le contexte, la date d'apparition, les messages d'erreur, les actions déjà effectuées.

Ajout de pièces jointes

Joindre tout document utile à la compréhension de la demande :
- Captures d'écran illustrant le problème
- Fichiers journaux (logs) ou documents de référence
Utiliser l'éditeur intégré pour structurer la description si nécessaire.

Validation et envoi

Vérifier l'ensemble des informations saisies avant envoi.
Cliquer sur « Envoyer » ou « Soumettre » pour créer le ticket.
Une confirmation de création est transmise automatiquement par e-mail.

Suivi de la demande

Accéder à « Voir vos tickets » depuis la page d'accueil pour consulter l'état de la demande.
Tous les échanges avec le support sont centralisés directement dans le ticket.
Toute mise à jour génère une notification e-mail automatique.

Bonnes pratiques

✔Renseigner des informations précises et complètes pour accélérer le traitement.
✔Choisir un titre explicite et synthétique décrivant clairement la situation.
✔Joindre des captures d'écran en cas d'incident visuel pour faciliter le diagnostic.
✔Ne créer qu'un seul ticket par demande — éviter les doublons.
✔En cas d'urgence critique, contacter également le support par téléphone.

📌 RAPPEL IMPORTANT

Toute demande, qu'il s'agisse d'un incident ou d'une demande de service, doit impérativement être effectuée via la plateforme GLPI afin de garantir un traitement structuré, un suivi efficace et une traçabilité complète pour le service informatique.

📋

PHOTO 7 — Formulaire de création de ticket GLPI

Cliquez sur une capture pour l'agrandir.

✅

Livrables RP 4 validés

✔ Accès distant MobaXterm (SSH, RDP, HTTPS)
✔ 2FA Google Authenticator sur Stormshield
✔ Règles de filtrage configurées
✔ GLPI + GLPI_Agent (inventaire + helpdesk)
✔ Tests remontées et tickets validés
✔ Procédure utilisateur rédigée
✔ Maquettage redondance FAI (HSRP Cisco)

RE4

Maquettage — Redondance FAI avec HSRP

        Suite à une panne FAI de 2 jours sur l'agence de Madère, le gérant demande une solution de redondance de la connexion internet. La solution retenue est le protocole HSRP (Hot Standby Router Protocol) avec deux routeurs Cisco, permettant un basculement automatique en cas de défaillance d'un lien WAN.
    

Contexte et solution retenue

L'agence de Madère dispose d'un routeur Cisco. En cas de panne du FAI principal, l'activité est paralysée. La solution maquettée repose sur :

2 routeurs Cisco (router1 = actif HSRP, router2 = standby) connectés chacun à un FAI différent
HSRP groupe 1 avec IP virtuelle 192.168.1.254 comme passerelle unique pour les clients LAN
NAT overload sur chaque routeur pour la sortie internet
SSH configuré sur les routeurs pour l'accès distant sécurisé
Tracking d'interface WAN : si le lien WAN du routeur actif tombe, le basculement est automatique

Plan d'adressage de la maquette

Équipement	Interface	Adresse IP	Rôle
router1	FastEthernet 0/3/0	192.168.1.250 /24	LAN — ip nat inside
router1	FastEthernet 0/3/1	DHCP (FAI 1)	WAN — ip nat outside
router2	FastEthernet 0/3/0	192.168.1.251 /24	LAN — ip nat inside
router2	FastEthernet 0/3/1	DHCP (FAI 2)	WAN — ip nat outside
HSRP VIP	—	192.168.1.254	Passerelle virtuelle partagée

Schéma de la maquette

🖊️

Figure 1 — Architecture réseau redondante HSRP pour RE4

FAI 1 → R1 (192.168.1.250) — FAI 2 → R2 (192.168.1.251)
HSRP VIP : 192.168.1.254 — NAT sur les deux routeurs — Switch → Poste client
GW client : 192.168.1.254 — DNS : 8.8.8.8 — no ip domain lookup

Configuration des interfaces

🔧 Étape 1 — Configuration des interfaces de router1

Interface LAN (Fa0/3/0) configurée en 192.168.1.250/24, interface WAN (Fa0/3/1) en DHCP.

🖥️

Configuration interfaces — Router1

Interface Fa0/3/0 : 192.168.1.250/24 (LAN) — Fa0/3/1 : DHCP (WAN)

🖥️

Configuration interfaces — Router2

Interface Fa0/3/0 : 192.168.1.251/24 (LAN) — Fa0/3/1 : DHCP (WAN)

Configuration HSRP

⚡ Étape 2 — Configuration HSRP sur router1 (priorité 95 + preempt)

interface fastEthernet 0/3/0
 standby 1 ip 192.168.1.254
 standby 1 priority 95
 standby 1 preempt
 standby 1 track fastEthernet 0/3/1 10

Router1 a une priorité de 95. Si l'interface WAN (Fa0/3/1) tombe, la priorité est réduite de 10, provoquant le basculement vers router2.

⚙️

HSRP — Router1 (configuration)

Standby IP 192.168.1.254 — Priorité 95 — Preempt — Track Fa0/3/1

⚙️

HSRP — Router2 (configuration)

Router2 : priorité 100 (défaut) — devient actif si router1 bascule

Configuration NAT overload

🌐 Étape 3 — NAT sur les deux routeurs

access-list 1 permit 192.168.1.0 0.0.0.255
ip nat inside source list 1 interface fastEthernet 0/3/1 overload

Le NAT overload permet à tous les postes du LAN de sortir sur internet via l'interface WAN de chaque routeur selon lequel est actif HSRP.

🔄

NAT — Router1

NAT overload sur Fa0/3/1 — access-list 1 / 192.168.1.0/24

🔄

NAT — Router2

NAT overload sur Fa0/3/1 — access-list 1 / 192.168.1.0/24

📋

NAT router2 — vue configuration complète

Configuration NAT complète sur router2 — ip nat inside / outside + overload

SSH sur les routeurs

🔐 Étape 4 — Activation SSH (accès distant sécurisé)

aaa new-model
username adminlocal secret Afpi5962!
ip domain-name cicar.es
crypto key generate rsa  (2048 bits)
ip ssh version 2
line vty 0 4
 transport input ssh
 transport output ssh

🔐

Installation SSH — Router1

Génération clé RSA 2048 bits — SSH v2 activé — domaine cicar.es

Configuration finale et vérification

✅

Configuration finale — Router1 (show running-config)

Running-config complet de router1 : HSRP, NAT, SSH, interfaces configurées

Tests et validation HSRP

🧪 Vérification avec show standby

La commande show standby sur chaque routeur permet de confirmer l'état HSRP, la priorité, l'IP virtuelle et le tracking d'interface.

🟢

show standby — Router1

State: Active — VIP: 192.168.1.254 — Priorité 95 — Track Fa0/3/1 (Up, -10)

🟡

show standby — Router2

State: Active (quand router1 bascule) — VIP: 192.168.1.254 — Priorité 100

        ✅ Résultat : HSRP opérationnel — IP virtuelle 192.168.1.254 active — Basculement automatique validé en cas de panne du lien WAN principal. Les clients LAN ne voient aucune interruption lors du failover.
    

✅

Livrables RE4 validés

✔ Maquettage redondance FAI avec 2 routeurs Cisco
✔ HSRP groupe 1 — VIP 192.168.1.254 configurée
✔ NAT overload sur les deux routeurs
✔ Tracking WAN avec basculement automatique
✔ SSH configuré pour accès distant sécurisé
✔ Vérification show standby validée

Synthèse : Schéma Réseau Final (RP 4)

Schéma complet incluant les accès distants (2FA), le helpdesk GLPI et l'administration via MobaXterm.

← Retour au portfolio

Projet CICAR

Sommaire

📌 Création d'un ticket d'incident sur GLPI