Mise en place d’un environnement local avec Gluetun VPN et Nginx Proxy Manager

07 novembre 2024

7 mins de lecture

Docker

Mise en place d’un environnement local avec Gluetun VPN et Nginx Proxy Manager

Dans cet article, nous allons voir comment mettre en place un environnement de développement local sécurisé utilisant Gluetun (VPN) et Nginx Proxy Manager (NPM).

Cette configuration vous permettra de :

Faire passer tout votre trafic par un VPN
Gérer facilement vos domaines locaux via une interface graphique
Sécuriser vos connexions

Pourquoi Gluetun et Nginx Proxy Manager

Gluetun tel un majordome du trafic web, orchestre vos connexions à travers un large éventail de VPNs compatibles. Dans mon cas, j’ai opté pour NordVPN et la genèse de ce projet ? Pure curiosité geek ! Comme dirait Tony Stark : « Parfois, il faut courir avant de savoir marcher ». J’ai relevé le défi technique, et non seulement ça fonctionne, mais c’est diablement satisfaisant ! 🚀

Nginx Proxy Manager (NPM pour les intimes) est votre maestro du trafic web local. Fini les jonglages avec localhost:8081, localhost:8082 – place à l’élégance avec des URLs stylées comme stark.test.dave ou geek.test.dave ! 🎯 Tel un portier de boîte de nuit numérique, NPM gère tout : reverse proxy, hôtes virtuels, redirections, certificats SSL et sécurité. C’est un peu comme avoir son propre petit coin d’Internet, mais en beaucoup plus classe et organisé.

Pour la touche finale SSL (parce que la sécurité, c’est sexy 🔒), optez pour un certificat wildcard – c’est comme avoir un passe-partout VIP pour tous vos domaines en *.test.dave. Plus besoin de générer un certificat à chaque nouveau projet, un seul suffit pour tous les gouverner !

Côté DNS, un petit tour dans votre fichier hosts (127.0.0.1 stark.test.dave), et le tour est joué. Mais pourquoi s’arrêter là quand on peut automatiser ? Dnsmasq entre en scène, gérant automatiquement vos domaines locaux. 🤓

Prérequis

Docker et Docker Compose installés
Un compte NordVPN (ou autre fournisseur VPN compatible)
Connaissance basique de Docker

Structure du projet

.
├── docker-compose.yml
├── .env
├── data/
│   ├── npm/
└── letsencrypt/

Configuration

1. Créez le fichier .env pour vos credentials NordVPN :

NORDVPN_USER=login
NORDVPN_PASSWORD=votre_mot_de_passe

2. Créez le docker-compose.yml :

services:
  vpn:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    environment:
      - VPN_SERVICE_PROVIDER=nordvpn
      - VPN_TYPE=openvpn
      - OPENVPN_USER=${NORDVPN_USER}
      - OPENVPN_PASSWORD=${NORDVPN_PASSWORD}
      - UPDATER_PERIOD=24h
      - TZ=Europe/Paris
      - LOG_LEVEL=debug
    ports:
      - "8888:8888"  # Proxy HTTP/HTTPS
      - "8388:8388"  # SOCKS5
      - "80:80"      # HTTP
      - "443:443"    # HTTPS
      - "3306:3306"  # MySQL
      - "81:81"      # NPM
    restart: unless-stopped

  npm:
    image: 'jc21/nginx-proxy-manager:latest'
    container_name: nginx-proxy
    depends_on:
      - vpn
    network_mode: "service:vpn"  # Utilise le réseau de Gluetun
    environment:
      DB_MYSQL_HOST: localhost
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: root
      DB_MYSQL_PASSWORD: super_mdp_root
      DB_MYSQL_NAME: npm
      # Ajout des variables de débogage
      DB_MYSQL_CONNECTION_LIMIT: 10
      DB_MYSQL_CONNECTION_TIMEOUT: 60000
    volumes:
      - ./data/npm:/data
      - ./letsencrypt:/etc/letsencrypt
    restart: unless-stopped

Notre infrastructure repose sur un duo de choc : Gluetun et Nginx Proxy Manager, tels Batman et Robin du trafic web ! 🦇 Dans notre docker-compose.yml, ils répondent aux noms de code ‘vpn‘ et ‘npm‘.

Un point crucial à noter : dans la directive network_mode: « service:vpn », ‘vpn’ fait référence au nom du service Gluetun. C’est comme une adresse postale – si vous aviez nommé votre service vpn_gluetun, la directive deviendrait network_mode: « service:vpn_gluetun ».

Démarrage des services

1. Créez les dossiers nécessaires :

mkdir -p data/npm letsencrypt

2. Démarrez les services :

docker-compose up -d

3. Vérifiez que tout fonctionne :

# Vérifier les containers
docker ps

# Vérifier les logs
docker logs gluetun
docker logs nginx-proxy

# Vérifier la connexion VPN
# Si wget dispo
docker exec gluetun wget -qO- ifconfig.me
# Et si curl dispo
docker exec gluetun curl ifconfig.me

Accès à Nginx Proxy Manager

1. Accédez à l’interface d’administration 🗄 :

URL : http://localhost:81
Email par défaut : [email protected]
Mot de passe par défaut : changeme

2. Les identifiants par défaut ([email protected]/changeme) vous tendent les bras ! Et même si votre âme de security ninja vous démange de les changer… surprise ! 🎭 À ce stade, la modification échouera gracieusement. Pas d’inquiétude, c’est normal, et franchement, en local, c’est comme mettre un antivol sur son frigo : techniquement possible, mais pas franchement utile ! 😅 Mais par principe je le fais 🦺

Troubleshooting 💣💣💣

Normalement, a ce stade, NPM s’affiche dans votre navigateur mais impossible de se connecter ⛔.

C’est normal, dans ma configuration, la base de données est dans un container séparé.

MariaDB

Ici, rien de bien méchant, un fichier docker-compose.yml et côté structure :

.
├── docker-compose.yml
├── data/

services:

  db:
    image: mariadb:latest
    container_name: mariadb
    network_mode: "container:gluetun"  # Utilise le réseau de Gluetun
    restart: always
    volumes:
      - ./data:/var/lib/mysql
    environment:
      MARIADB_ROOT_PASSWORD: super_mdp_root

On passe par le réseau gluetun configuré avant.

1. On démarre le service :

docker-compose up -d

Normalement MariaDB est accessible via client SQL ou via un container phpMyAdmin 💩💩💩 :

host : 127.0.0.1 (ou localhost)
port : 3306
user : root
Mot de pase : super_mdp_root

Voilà ! MariaDB ronronne tranquillement dans son coin. 🐱 Mais avant de sabrer le champagne, il nous manque un petit détail : créer la base de données ‘npm‘.

Direction http://localhost:81 pour tester la connexion. Si vous tombez sur un mur au lieu du tapis rouge, pas de panique ! C’est probablement que les credentials de base de données dans votre container npm font leur rebelle. Un petit check des paramètres de connexion s’impose – comme dirait Sherlock Holmes : « Élementaire, mon cher Watson, vérifions ces variables d’environnement ! » 🔍

Points importants à retenir

Sécurité
- Les credentials VPN sont stockés dans .env
- Tous les services utilisant network_mode: « service:vpn » passeront par le VPN
- NPM gère automatiquement les certificats SSL
Maintenance
- Les configurations NPM sont persistantes dans ./data/npm
- Les certificats SSL sont stockés dans ./letsencrypt
Ports exposés
- 81 : Interface NPM
- 80 : HTTP
- 443 : HTTPS
- 8888 : Proxy HTTP/HTTPS
- 8388 : SOCKS5
- 3306 : MySQL

⚠️ Point crucial à comprendre

L’arrêt de Gluetun ou NPM entraîne l’interruption de tous les containers qui en dépendent. C’est en réalité un avantage en termes de sécurité : cela garantit qu’aucun trafic ne peut contourner le VPN. Si Gluetun s’arrête, tous vos services sont mis en pause, évitant ainsi toute fuite de données.

Bien que cela implique de redémarrer tous les containers dépendants lors d’un redémarrage de Gluetun/NPM, c’est un petit prix à payer pour une sécurité garantie. Un simple script de gestion peut automatiser ce processus de redémarrage.

💡 Astuce de dev : Pensez à scripter le redémarrage de vos containers. C’est une tâche unique qui vous fera gagner beaucoup de temps par la suite.

Le bonus – Configuration d’un WordPress passant par le VPN

Coté structure, rien de méchant, un docker-compose.yml avec :

services:
  wordpress:
    image: wordpress:latest
    container_name: wp_samy
    network_mode: "container:gluetun"  # Utilise le réseau de Gluetun
    env_file:
      - ./conf/wp.env
    environment:
      - APACHE_PORT=8083
      - WORDPRESS_CONFIG_EXTRA=
        define('WP_HOME', 'https://wp_samy.test.dave');
        define('WP_SITEURL', 'https://wp_samy.test.dave');
        define('FORCE_SSL_ADMIN', true);
        define('WP_SITEURL_FORCE_SSL', true);
    command: |
      /bin/bash -c 'sed -i "s/Listen 80/Listen $${APACHE_PORT}/g" /etc/apache2/ports.conf &&
                    sed -i "s/<VirtualHost \*:80>/<VirtualHost *:$${APACHE_PORT}>/g" /etc/apache2/sites-available/000-default.conf &&
                    apache2-foreground'
    restart: always
    volumes:
      - ./wp:/var/www/html

Dans le dossier wp.env qui contient les informations de la base de données.

WORDPRESS_DB_HOST=127.0.0.1:3306
WORDPRESS_DB_USER=root
WORDPRESS_DB_PASSWORD=super_mdp_root
WORDPRESS_DB_NAME=WP_samy
WORDPRESS_TABLE_PREFIX=NlAp_
WORDPRESS_DEBUG=true

👨‍🎓 Côté explications :

network_mode: « container:gluetun » : tu as compris on lui dit explicitement de passer par le VPN.
APACHE_PORT=8083 : c’est un choix, comme tout doit passer par NPM, il faut différencier les ports et de toute façon, le 80 et 443 est prix par NPM.
WORDPRESS_CONFIG_EXTRA : on set plusieurs constantes (tu peux en rajouter si tu en as besoin)
command : c’est simplement pour modifier facilement et rapidement les ports d’écoute dans le container une fois créé. C’est pour éviter de devoir créer des images avec des ports assignés. Là on peux facilement utiliser des images externes ou créer les notres sans devoir toucher aux ports. On le fait côté docker-compose ! Je trouve ça bien plus pratique. Et comme je l’ai fait, j’y touche plus, je change juste la variable APACHE_PORT et et c’est tout.

network_mode: « container:gluetun » C’est une instruction explicite qui force le container à utiliser le stack réseau de Gluetun. Résultat : tout le trafic passe obligatoirement par le VPN, pas d’échappatoire possible.
APACHE_PORT=8083 Les ports 80 et 443 étant déjà utilisés par NPM, on assigne des ports alternatifs (8083, 8084, etc.) à nos services. NPM se charge ensuite de rediriger le trafic vers ces ports internes.
WORDPRESS_CONFIG_EXTRA Une zone flexible pour définir des constantes WordPress personnalisées. C’est comme un fichier de configuration dynamique où on peut ajouter autant de définitions que nécessaire.
command Une approche élégante pour modifier les ports à la volée, directement dans le docker-compose. Au lieu de :
- Créer des images customisées
- Modifier les Dockerfiles
- Gérer plusieurs versions d’images
- On change simplement la variable APACHE_PORT dans le docker-compose, et la commande s’occupe de reconfigurer automatiquement. C’est plus maintenable et plus flexible.

Et voilà ! Vous avez maintenant un environnement de développement local qui ferait pâlir Tony Stark lui-même ! 🚀 Un VPN qui protège vos arrières, un proxy manager qui jongle avec vos domaines comme un artiste, et une flexibilité qui rendrait jaloux un contorsionniste.

Certes, la mise en place peut sembler un brin complexe au premier abord – un peu comme apprendre à faire du vélo avec des stabilisateurs en feu 🔥 – mais une fois en place, c’est un véritable game-changer. Plus de jonglage avec les ports, plus de « ça marche chez moi », et surtout, la satisfaction de voir tous vos projets alignés comme des dominos bien ordonnés.