Niveau 🟡 intermédiaire
Durée estimée : 20 min · Prérequis : Le piège vécu : Docker contourne ufw
Exposer un service sur Internet, c'est ouvrir une porte donnant directement sur la rue plutôt que
sur un couloir privé. Ce n'est pas interdit — un commerce a besoin d'une vitrine — mais ça ne se
décide jamais par défaut : chaque porte donnant sur l'extérieur mérite une raison précise, pas
seulement « ce serait pratique ».
Le choix par défaut, cohérent avec tout ce qui a été vu dans ce module : ne rien exposer.
Un service accessible uniquement depuis le réseau local (vu dès
M2) élimine d'un coup toute la surface d'attaque venue d'Internet —
scans automatisés, tentatives de connexion opportunistes, exploitation de failles connues sur des
services exposés massivement. Ce choix ne coûte rien en confort tant qu'on n'a pas besoin
d'accéder à ses services depuis l'extérieur du réseau local.
L'arbre de décision, à parcourir pour chaque service, un par un :
L'alternative la plus courante à l'exposition directe : le VPN (Virtual Private Network).
Un VPN crée un tunnel chiffré entre un appareil distant et le réseau local, faisant apparaître
cet appareil comme s'il s'y trouvait physiquement — sans jamais ouvrir de port public pour le
service lui-même. C'est la réponse au cas n°2 de l'arbre ci-dessus : accéder à ses propres
services depuis l'extérieur, sans les rendre accessibles à qui que ce soit d'autre sur Internet.
Cette approche reste, à ce stade de ce wiki, une notion générale non testée sur notre
installation — voir l'encadré ci-dessous.
⚠️ Honnêtement, VPN et exposition publique : deux notions non testées ici. Le choix retenu
sur notre installation — détaillé plus bas — n'a jamais nécessité ni VPN ni exposition
publique. Le VPN reste donc présenté ici comme une alternative générale reconnue, pas comme une
pratique vécue et documentée sur ce serveur.
🧪 Concrètement, sur notre exemple : la réponse à la question n°1 de l'arbre a été « non »
pour chacun des services couverts dans ce wiki jusqu'ici — reverse proxy, administration
Docker, supervision, monitoring. Aucun n'a de raison objective d'être joignable depuis
l'extérieur du réseau local, et le choix a donc été, systématiquement, de ne rien exposer.
C'est ce choix, répété service après service, qui explique pourquoi les modules réseau et
sécurité de ce wiki (M2, M7) n'ont jamais eu besoin de couvrir la redirection de port ou le
VPN en pratique.
Le chemin par défaut ramène systématiquement vers « ne pas exposer » — l'exposition publique
n'est atteinte qu'au bout d'une suite de réponses affirmatives et réfléchies, jamais par défaut.
Pas de commande de mise en œuvre ici — l'exercice est une décision à documenter, service par
service :
Service : <nom>
Q1 -- Besoin d'accès externe réel ? OUI / NON
Q2 -- Si oui, pour qui (moi seul / autrui) ?
Q3 -- Coût d'un incident sur ce service ?
Q4 -- Capacité de maintenance dans la durée ?
Décision : exposé / VPN / non exposé
Pour chaque service actuellement installé sur ton homelab, tu devrais pouvoir remplir le gabarit
ci-dessus et arriver à une décision cohérente avec ta réponse à la première question.
| Symptôme | Cause probable | Solution |
|---|---|---|
| Exposer un service « parce que ce serait pratique », sans besoin identifié | Confort à court terme, sans évaluation du risque | Repartir de la question 1 : le besoin est-il réel, ou seulement hypothétique ? |
| Confondre besoin d'accès personnel à distance et besoin d'exposition publique | Ne pas connaître l'alternative VPN | Un VPN répond au besoin d'accès personnel sans exposer le service à tout Internet |
| Exposer un service sans avoir les moyens de le maintenir à jour dans la durée | Sous-estimation de l'engagement que représente une exposition publique | Répondre honnêtement à la question 4 de l'arbre avant toute exposition |
Non — l'exposition est l'exception à justifier explicitement par un besoin réel, pas le choix
par défaut.
Un VPN, qui crée un tunnel chiffré faisant apparaître un appareil distant comme s'il se trouvait
sur le réseau local, sans ouvrir de port public pour le service lui-même.
Parce qu'un service exposé publiquement et laissé sans mise à jour de sécurité devient, avec le
temps, plus dangereux que l'absence même du service.
Pour chacun des services que tu envisagerais d'installer sur ton propre homelab, remplis le
gabarit de décision de cette page et détermine, pour chacun, s'il devrait être exposé, accessible
via VPN, ou strictement interne.
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.