[TUTO] Certificat SSL & reverse proxy via Docker

[.Shad.]

 

1. Qu'est-ce qu'un proxy inversé ?

Un proxy inversé (reverse proxy) est un type de serveur, habituellement placé en frontal de serveurs web. Contrairement au serveur proxy qui permet à un utilisateur d'accéder à un environnement depuis un point unique, le proxy inversé permet à un utilisateur d'accéder depuis un environnement à des serveurs internes via un point d'entrée unique. Un proxy inversé écoute sur un port donné, sécurisé ou pas, toutes les requêtes à destination de ces services. Au lieu donc d'avoir de multiples portes (les ports des applications auxquelles ont souhaite accéder depuis l'extérieur), on en a une seule qui s'occupera de rediriger les requêtes vers le bon service.

2. Prérequis

 - Comprendre le fonctionnement de Docker (voir tutoriel introductif)
 - Savoir se connecter en SSH à son hôte
 - Savoir rediriger un port depuis sa box
 - Être un peu curieux

Difficulté : Moyenne

3. Pourquoi ?

Des solutions de proxy inversé, il en existe des tas, toutes ont leurs avantages et inconvénients. DSM utilise Nginx, mais il existe aussi entre autres HAProxy, Apache, Squid, etc...
Dans notre cas ce sera également Nginx, mais via l'image Docker linuxserver/swag, car elle embarque tout un ensemble de fonctionnalités supplémentaires qui agissent en synergie.

Cette solution comprend notamment :

• Certbot : utilitaire permettant l'obtention et le renouvellement automatique de certificats Let's Encrypt.
• Fail2ban : Script permettant le bannissement d'IP ayant réalisé un nombre donné de tentatives de log infructueuses.
• Authelia (fichiers de configuration seulement) : Logiciel d'authentification deux facteurs hautement personnalisable et applicable à n'importe quelle application.
• Nginx : Serveur web qu'on utilise ici pour faire office de proxy inversé.

L'intérêt majeur est de pouvoir appliquer des fonctionnalités existantes dans DSM mais réservées à celui-ci, à n'importe quelle application.
Et de disposer d'un serveur Nginx entièrement paramétrable a contrario de celui intégré à DSM.

ATTENTION : Cette image ne permet pas de déployer automatiquement le certificat obtenu dans DSM à la manière dont le fait acme.sh (voir tutoriel de @Einsteinium pour une utilisation via Docker ou le tutoriel de @oracle7 pour les NAS incompatibles).
Vous devrez l'installer manuellement dans DSM si vous souhaitez l'utiliser et le faire tous les 3 mois.

Pour ma part je ne m'embête pas, j'utilise l'interface DSM pour obtenir un certificat wildcard avec le nom de domaine Synology qui se renouvelle tout seul tous les 2 mois.
Ainsi, j'utilise le nom de domaine Synology pour les services comme Hyper Backup, Drive, etc... tout ce qui est intrinsèquement lié à DSM et qui n'est pas gérable au travers d'un proxy inversé.
Tout le reste passe par le certificat OVH que ce conteneur va générer.

4. Hypothèses

Pour mieux illustrer le propos, je conviendrai d'un certain nombre d'adresses qui faciliteront l'identification des consignes à l'application du tutoriel :

• Adressage réseau "physique" : 192.168.1.0/255.255.255.0 (/24 en notation CIDR)
• Le serveur DHCP ne couvre qu'une partie de la plage 192.168.1.0/24, par exemple 192.168.1.1 à 192.168.1.99
• Passerelle (routeur ou modem) : 192.168.1.254
• IP (physique, pour utilisation avec réseau macvlan) du conteneur swag : 192.168.1.145 (voir plus loin).
• IP de l'hôte (le NAS ici, mais ça pourrait être une autre périphérique) : 192.168.1.100 (Je pars du principe que votre hôte a une IP définie en dehors de la plage d'attribution du serveur DHCP, ce n'est pas obligatoire (mais conseillé)).
• IP virtuelle de l'hôte (voir plus loin) : 192.168.1.200
• eth0 est le nom de mon interface physique.

5. Principe

L'idée générale de ce que l'on s'apprête à mettre en place peut être résumée de la sorte :

Le port 443/tcp (par défaut) est le port d'écoute du proxy inversé. Le port 80 est le port utilisé par Let's Encrypt pour renouveler les certificats si on choisit la méthode de validation HTTP-01 et/ou pour faire une redirection HTTP -> HTTPS.

Deux cas de figure se présentent, soit les ports sont libres sur l'hôte, soit ils ne le sont pas :

• S'ils sont libres, ce qui est le cas si vous décidez d'utiliser SWAG sur une autre machine que le NAS (un Raspberry Pi fait tout à fait le job), alors on peut créer notre conteneur sur un réseau bridge. Dans ce cas-là, la lecture du tutoriel introductif devrait suffire pour la mise en place de swag.
• S'ils ne le sont pas, ce qui est très probablement le cas sur votre NAS (Webstation installé, Nginx en sous-main) on le rattachera à un réseau macvlan. Un réseau macvlan permet de donner une adresse IP au conteneur sur le réseau physique, par exemple ici 192.168.1.150
  Il s'émancipe d'une certaine manière de l'hôte et se comporte globalement comme un périphérique à part entière relié à votre routeur. Il pourra donc utiliser tous les ports dont il a besoin. Au prix d'une impossibilité de communication avec l'IP de l'hôte (limitation intrinsèque au pilote macvlan).

Mais il existe une manière de contourner le problème de communication via une interface virtuelle du NAS, vous trouverez plus de détail dans le tutoriel introductif.
C'est la méthode que j'ai décidé de privilégier ici, car plus difficile d'accès que via le réseau bridge, et qu'elle permet de ne pas toucher à la configuration du NAS.
Je reprendrai principalement ce qu'on peut trouver dans mon tutoriel sur Docker, en l'appliquant à notre cas d'utilisation.

En parallèle; n'hésitez pas à parcourir ce magnifique guide, dont ce tutoriel est un bon complément, sur la mise en route de ce conteneur.
Vous y trouverez notamment beaucoup plus d'informations sur la partie hébergement de sites, la configuration d'Nginx ; des thèmes que je n'aborderai pas dans le présent tutoriel.

6. Création du réseau macvlan

Note :

• Si vous avez déjà créé un réseau macvlan, rendez-vous au paragraphe 7.
• Si en plus vous avez déjà créé une interface virtuelle pour la communication NAS <-> conteneur(s) en macvlan, rendez-vous au paragraphe 8.

Pour créer le réseau macvlan, il faut définir une portion libre de l'adressage du réseau physique de notre LAN dans laquelle nous pourrons adresser notre (et éventuellement nos futurs) conteneurs. Cet outil est très pratique pour calculer des plages IP, je vois par exemple que si je choisis 192.168.1.144/28, je dispose d'un pool d'IP allant de 192.168.1.145 à 158, ce qui est je pense amplement suffisant, on peut passer le masque à /29 à la place de /28 pour réduire cette plage à 150 au lieu de 158. On peut également décider que ce sera notre seul conteneur en macvlan, pour réduire l'espace à une seule IP il suffit d'utiliser le masque /32.
Ici pour couvrir le cas d'utilisation le plus général, on choisira le masque /29.

Afin de garder une trace de la configuration du réseau, je vous conseille de créer un fichier macvlan_net.sh.
On se rend dans le dossier de notre choix, par exemple chez moi j'ai un dossier networks dans mon dossier partagé docker :

cd /volume1/docker/networks
touch macvlan_net.sh
nano macvlan_net.sh

La commande nano est disponible sur vos NAS via les excellents paquets SynoCLI de Synocommunity, en l'occurence SynoCLI Files ici.
On entre le script suivant :

docker network create -d macvlan \
--subnet=192.168.1.0/24 \
--ip-range=192.168.1.144/29 \
--gateway=192.168.1.254 \
-o parent=eth0 \
macvlan_net

On le rend exécutable et l'exécute :

chmod u+x macvlan_net.sh
./macvlan_net.sh

Une série de caractères s'affiche si tout s'est correctement déroulé.

Notes :

• Pensez à utiliser sudo devant les commandes docker (valable pour toute la suite du tutoriel) si vous n'êtes pas connecté avec l'utilisateur root.
• ip-range correspond à la plage qu'on a choisie ci-avant.
• Sur le NAS, si on a activé open vswitch (automatique si par exemple on utilise Virtual Machine Manager), l'interface parente n'est plus eth0 (ou eth1, eth2, ..., ethX) mais ovs_eth0 (respectivement ovs_eth1, etc...).
• Pour connaître le nom de l'interface physique de sa machine (il varie suivant les machines), en SSH on peut taper :

  ifconfig | grep -C 3 192.168.1.100

  ou

  ip addr | grep -C 3 192.168.1.100

  Il suffit alors de repérer l'interface ayant pour adresse IP l'adresse physique du NAS (ici 192.168.1.100).

On peut maintenant vérifier que le réseau existe bien en tapant :

docker network ls

7. Création de l'interface virtuelle

7-A. Création du script

Comme dit en introduction, il y a un inconvénient majeur à utiliser le réseau macvlan car il n'est plus possible de communiquer entre l'IP de l'hôte, 192.168.1.100 et le conteneur swag dont l'IP sera sur le réseau macvlan. Pour pallier ce défaut, on va créer une interface virtuelle, un autre chemin par lequel le NAS pourra communiquer avec le(s) conteneur(s) sur le réseau macvlan. Cette interface disparaîtra à chaque redémarrage du NAS, on créera donc une tâche planifiée pour la monter automatiquement.

__________________

ATTENTION (merci @EVOTk) :
L'interface disparaît également lorsque vous :

• arrêtez
• désinstallez
• mettez à jour

le paquet Docker.
Il faudra donc exécuter ce script manuellement depuis l'interface DSM si cela se produit.

__________________

Toute cette procédure est explicitée dans le tutoriel introductif, mais on la reprendra pas à pas ici en personnalisant les commandes à notre besoin.
On peut se placer dans un dossier interfaces dans le dossier partagé docker :

cd /volume1/docker/interfaces
touch mac0.sh
nano mac0.sh

Puis de manière similaire à ce qu'on a fait pour le script du réseau macvlan, on crée un script pour la création de l'interface :

#!/bin/sh

# Script permettant la communication entre
# un conteneur appartenant a un reseau macvlan et son hote
# A lancer au demarrage de l'hote

# Temporisation
#sleep 60

# Creation de l interface macvlan sur l hote
ip link add mac0 link eth0 type macvlan mode bridge

# Configuration de l interface avec l adresse reservee
ip addr add 192.168.1.200/32 dev mac0
ip link set dev mac0 address AA:BB:CC:DD:11:45
ip link set mac0 up

# On fait une route entre les IPv4 du reseau mac0 et l'interface
ip route add 192.168.1.144/29 dev mac0

Notes :

• L'adresse 192.168.1.200/32 correspond à l'IP virtuelle du NAS, le NAS sera accessible et visible également avec cette nouvelle adresse comme avec son IP réelle 192.168.1.100. Mais a contrario de cette dernière, le conteneur peut tout à fait communiquer avec.
• Vous noterez la présence d'une temporisation commentée de 60 secondes. Si vous rencontrez des problèmes de création de l'interface au démarrage du NAS, n'hésitez pas à décommentez, le script sera décalé d'une minute (ce qui peut permettre d'initialiser la connexion réseau, etc...).

On rend le script exécutable et on l'exécute :

chmod u+x mac0.sh
./mac0.sh

On vérifie maintenant que l'interface est bien active :

ifconfig | grep -A 5 mac0

7-A. Création de la tâche

On va maintenant créer une tâche planifiée dans DSM pour exécuter ce script à chaque redémarrage du NAS.
Direction Panneau de configuration -> Tâches planifiées -> Créer -> Tâche déclenchée -> Script défini par l'utilisateur 

On est maintenant prêt à passer à la création du conteneur.

8. Création du conteneur

8-A. Fichier docker-compose

Il ne reste plus qu'à créer le conteneur, on passera par un fichier docker-compose.

La documentation très complète de Linuxserver est disponible à l'adresse : https://github.com/linuxserver/docker-swag

Hypothèses :

• Utilisation d'un nom de domaine OVH
• Délivrance du certificat par DNS-01

La méthode DNS-01 implique que votre certificat sera validé au niveau de votre hébergeur de zone DNS (OVH par défaut) et non votre NAS comme avec la méthode HTTP-01.
DNS-01 est obligatoire en cas de demande d'un certificat wildcard.
Si vous souhaitez utiliser la méthode HTTP-01, il faudra prévoir une redirection (NAT) du port 80 de votre box vers l'IP du conteneur.

Plus d'information à cette adresse : https://github.com/linuxserver/docker-swag

Dans le cadre de nos hypothèses, voici l'architecture du fichier docker-compose :

version: '2.1'
services:

   swag:
      image: linuxserver/swag
      container_name: swag
      networks:
         macvlan_net:
            ipv4_address: 192.168.1.145
      cap_add:
         - NET_ADMIN
      environment:
      	 - PUID=1026
         - PGID=100
      	 - TZ=Europe/Paris
         - URL=ndd.ovh
         - SUBDOMAINS=wildcard
         - VALIDATION=dns
         - DNSPLUGIN=ovh
         - DHLEVEL=2048
         - EMAIL=mail@ndd.tld
         - ONLY_SUBDOMAINS=false
         - STAGING=false
      volumes:
         - ./config:/config
      restart: unless-stopped

networks:

   macvlan_net:
      external: true

Notes :

• Vous remarquerez que je ne translate aucun port entre le NAS et le conteneur, pourquoi ? N'oubliez pas que ce conteneur sera une machine à part entière sur le réseau physique, dès lors elle n'a pas "d'hôte" à proprement parler. J'aurai simplement mon routeur ou mon modem qui redirigera son port public 443 vers le port 443 de l'adresse IP physique du conteneur (192.168.1.145), comme il le ferait vers n'importe quelle autre machine
• En amont, une translation de ports depuis le modem/routeur doit être faite pour les ports :
  • TCP 443 pour que le proxy inversé reçoive les requêtes.
  • TCP 80 si vous validez par HTTP-01 OU si vous souhaitez avoir une redirection HTTP -> HTTPS pour vos entrées de proxy inversé (si vous tapez exemple.ndd.tld dans votre navigateur, vous serez rediriger vers https://exemple.ndd.tld).
• Le PUID proposé correspond à mon utilisateur admin personnalisé, et le PGID de 100 correspond au groupe users par défaut. Vous pouvez définir un utilisateur et un groupe spécifiques qui ne possèderont des droits que sur les dossiers du conteneur.
• Le paramètre cap_add est utile seulement si vous souhaitez utiliser fail2ban (conseillé), car le conteneur devra modifier ses iptables (pas celles de l'hôte).

Notes (2) :

• Si vous avez utilisé la méthode réseau bridge, il faut penser dans ce cas à faire une redirection des ports sur l'hôte, ça se traduit par l'ajout du bloc "ports" suivant (par exemple entre les blocs "environment" et "volumes") :

  ports:
  
     - 443:443/tcp  # Ecoute proxy inverse
     - 80:80/tcp    # Redirection HTTP vers HTTPS

  8-B. API OVH

Je ne m'attarderai pas sur cette partie, tout est parfaitement décrit dans le tutoriel de @oracle7 sur la génération d'un certificat wildcard par acme.sh
J'ajouterai simplement une nuance sur les accès API à donner, ceux-ci me semblent plus restrictifs et préférables :

GET /domain/zone/
GET: /domain/zone/ndd.ovh/
GET /domain/zone/ndd.ovh/status
GET /domain/zone/ndd.ovh/record
GET /domain/zone/ndd.ovh/record/*
POST /domain/zone/ndd.ovh/record
POST /domain/zone/ndd.ovh/refresh
DELETE /domain/zone/ndd.ovh/record/*

Également, on peut limiter l'utilisation de l'API à une ou des IP prédéfinies, particulièrement pratique si on dispose d'une IP fixe.
En bout de chaîne vous obtiendrez 3 clés permettant un accès à l'API OVH : l'application key, l'application secret et la consumer key.

8-C. Création du fichier ovh.ini

Avant la création du conteneur, on va créer en amont le fichier ovh.ini et le préremplir avec vos accès OVH obtenus ci-avant.
Ainsi lorsqu'on créera le conteneur, on évitera le message d'erreur comme quoi le conteneur ne dispose pas des accès à l'API.
En SSH, connecté avec de préférence l'utilisateur dont on reprendra le PUID/PGID dans les variables d'environnement du fichier docker-compose.yml, on se place dans le dossier destiné à accueillir la configuration du conteneur :

cd /volume1/docker/swag

Ensuite :

mkdir -p config/dns-conf/
cd config/dns-conf/
curl -s https://raw.githubusercontent.com/linuxserver/docker-swag/master/root/defaults/dns-conf/ovh.ini -o ./ovh.ini

On édite ensuite le fichier, avec son éditeur préféré (vim, nano, WinSCP, File Station, etc...) et on remplit les champs avec les accès API d'OVH obtenus précédemment :

# Instructions: https://github.com/certbot/certbot/blob/master/certbot-dns-ovh/certbot_dns_ovh/__init__.py#L20
# Replace with your values
dns_ovh_endpoint = ovh-eu
dns_ovh_application_key = VALEUR_APPLICATION_KEY
dns_ovh_application_secret = VALEUR_APPLICATION_SECRET
dns_ovh_consumer_key = VALEUR_CONSUMER_KEY

Pour éviter un message lié aux permissions laxistes du fichier, on va le chmoder :

chmod 600 ovh.ini

Si en revanche vous obtenez plus tard un erreur due à un des permissions insuffisantes, exécutez de nouveau la commande en remplaçant 600 par 640.

8-D. Création du conteneur

Une fois le fichier ovh.ini correctement complété, on peut créer le conteneur, on se place dans le dossier où se trouve le fichier docker-compose et on écrit :

docker-compose up -d

On peut suivre l'évolution de l'initialisation du conteneur via :

docker-compose logs --follow

(CTRL+C pour arrêter le défilement des logs en direct).
Ou alors via le paquet Docker de DSM ou encore Portainer (voir tutoriel).

Normalement à ce stade vous disposez d'un certificat fonctionnel dans /volume1/docker/swag/config/keys/letsencrypt.
Il sera tout à fait possible des copier les fichiers ou de créer des liens symboliques pour d'autres applications vers ces fichiers. 🙂
Autre possibilité, monter ce dossier en tant que volume pour un service qui nécessiterait ses propres certificats, bref ils sont à vous, faites-en ce que bon vous semble !

Passons à la configuration du proxy inversé.

9. Configuration du proxy inversé

9-A. Configuration d'une entrée

Nginx est une application assez dense, et demande de comprendre les procédés à l'œuvre, le tutoriel sur la mise en place d'un VPS comme frontend de @Einsteinium entre plus en détail dans le sujet, dans notre cas, on a la chance que Linuxserver propose dans son image toute une liste d'applications grand public préconfigurées, dirigeons-nous pour cela dans le dossier suivant :

cd /volume1/docker/swag/config/nginx/proxy-confs

Et voyons ce qu'on y trouve :

ls -l

On voit tout un tas d'entrée préconfigurées, qui se classent en deux catégories : subdomain et subfolder. Le proxy inversé peut fonctionner soit en fonction du sous-domaine sollicité, soit du "path" (chemin) après le nom de domaine. Dans notre cas on s'intéressera aux entrées de type subdomain, exemple avec une entrée pour Resilio-sync :

Faisons un rapide tour des directives, les champs en vert sont ceux que vous êtes a priori susceptibles de modifier :

• server { => on commence la définition d'une entrée du proxy inversé
• listen 443 ssl; et listen [::]:443 ssl; => le proxy inversé va écouter sur le port 443 les requêtes en IPv4 et IPv6 de toutes les sources disponibles.
• server_name resilio-sync.*; => la condition pour que le proxy inversé réagisse est que l'adresse commence par resilio-sync, exemple -> resilio-sync.ndd.ovh.
• include /config/nginx/ssl.conf; => à l'exécution, nginx va importer tous les paramètres définis dans le fichier ssl.conf, entre autre le chemin du certificat à utiliser, les algorithmes de chiffrement, etc...
• #include /config/nginx/ldap.conf; => pour ceux qui souhaitent s'authentifier au travers du proxy à partir d'un serveur d'authentification LDAP. Cette image n'embarque pas de serveur LDAP, elle permet juste de l'intégrer facilement au proxy inversé. Commenté par défaut.
• #include /config/nginx/authelia-server.conf; => permet d'intégrer une authentification deux facteurs ou simple facteur conditionnelle, fera l'objet d'un autre tutoriel.
  Cette image n'embarque pas de serveur Authelia, elle permet juste de l'intégrer facilement au proxy inversé. Commenté par défaut.
• location / { : on définit le comportement de Nginx pour la racine ("/") du sous-domaine.
• Viennent ensuite trois blocs (de la ligne 21 à 30) affiliés respectivement à une authentification http (l'explorateur demandera un identifiant et un mot de passe au chargement de la page), des paramètres liés à l'authentification par LDAP, et des paramètres liés à Authelia. On n'y touchera pas ici.
• include /config/nginx/proxy.conf; => Importation d'en-têtes (timeouts, transmission des IP, gestion des cookies, etc...)
• include /config/nginx/resolver.conf; => Le résolveur DNS utilisé sera le résolveur Docker embarqué dans chaque conteneur.

La partie suivante est la partie la plus importante, elle définit comment le conteneur swag va accéder à l'application qu'on souhaite dissimuler derrière le proxy inversé.
Il faut garder à l'esprit que la façon dont le conteneur accède au réseau peut être bien différente de la façon dont vous, vous accédez à vos applications par le navigateur.
Dans notre cas, vu que le conteneur est sur le réseau macvlan, donc sur le réseau physique, comme la machine depuis laquelle vous tentez d'accéder à ces applications.

A une différence près, si vous avez bien suivi, c'est que le conteneur ne pourra pas accéder à son hôte via son IP physique, mais seulement par son IP virtuelle, donc dans notre cas 192.168.1.200 au lieu de 192.168.1.100.

Voyons la signification des trois champs :

9-A-1. $upstream_app

set $upstream_app resilio-sync;

Ici c'est très trompeur, ce que vous lisez là, "resilio-sync", c'est le nom du conteneur.
Cette résolution par nom de conteneur, donc ici que le conteneur de nom "swag" cherche à contacter le conteneur de nom "resilio-sync" ne peut s'opérer que si les deux conteneurs se trouvent dans le même réseau.

Dans notre cas, si on avait bien un conteneur resilio-sync, il serait probablement en bridge sur son hôte. Par défaut inaccessible au conteneur Let's Encrypt sauf si on a translaté le port du conteneur sur celui du NAS.
Dans ce dernier cas on peut tout à fait y accéder en entrant l'adresse IP ou le nom DNS du NAS : 192.168.1.200 (rappelez-vous, IP virtuelle).

9-A-2. $upstream_port

set $upstream_port 8888;

Il s'agit du port tel qu'il sera accessible pour le conteneur SWAG. Si par exemple sur votre NAS vous avez un conteneur Bitwarden, que par défaut l'interface est émise sur le port 8080 dans le conteneur, mais que vous avez décalé le port pour une raison qui vous appartient, disons vers 5080, il faudra alors utiliser 5080 et pas 8080.

9-A-3. $upstream_proto

set $upstream_proto http;

Le protocole lié au port, souvent http (on évite de chiffrer entre le NAS et lui-même), mais parfois https (certaines applications comme Unifi-controller n'expose leur interface que via HTTPS), à vous d'adapter en fonction du besoin.

9-A-4. Récapitulatif

Prenons le cas de l'application Resilio-sync qu'on aurait installé sur notre NAS, via le centre des paquets (sans Docker donc), j'utiliserai la configuration suivante :

set $upstream_app 192.168.1.200;
set $upstream_port 8888;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;

La ligne proxy_pass construit l'URL à partir des variables précédemment définies, on n'a pas à y toucher.

D'autres exemples :

• Moments

set $upstream_app 192.168.1.200;
set $upstream_port 10004; # Port personnalisé de Moments dans Portail des applications
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;

• Jeedom auquel j'accède via un nom de domaine local :

set $upstream_app raspberrypi.local;
set $upstream_port 8088;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;

• Mon routeur, dont l'interface émet sur le port sécurisé 8443 :

set $upstream_app 192.168.1.1;
set $upstream_port 8443;
set $upstream_proto https;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;

Une fois toutes nos entrées configurées, on redémarre le conteneur :

docker restart swag

Et normalement, tout devrait être fonctionnel.

9-B. Redirection HTTP -> HTTPS

Par défaut, SWAG écoute sur le port 80. Si vous souhaitez que SWAG fasse une redirection automatique 80 -> 443 pour les requêtes extérieures, il faut faire une redirection du port 80 depuis votre box vers le port 80 de l'IP (192.168.1.145) du conteneur.
Si vous aviez l'habitude de faire une demande de certificat depuis DSM via HTTP-01, vous risquez d'être embêté car une seule redirection simultanée du port 80 est possible.

9-C. Validation par HTTP-01

Il se peut que votre hébergeur DNS n'ait pas d'API pour permettre une validation du certificat à son niveau, dans ce cas-là vous pourriez vouloir utiliser un certificat délivré par HTTP-01.
Il faut dans ce cas-là rediriger le port 80 de votre box/routeur vers le port 80 de l'IP du conteneur 192.168.1.145
Un fichier docker-compose type pour un renouvellement HTTP-01 pourrait être le suivant :

version: '2.1'
services:

   swag:
       image: linuxserver/swag
       container_name: swag
       networks:
          macvlan_net:
             ipv4_address: 192.168.1.145
       cap_add:
          - NET_ADMIN
       environment:
      	  - PUID=1026
          - PGID=100
      	  - TZ=Europe/Paris
          - URL=ndd.ovh
          - SUBDOMAINS=plex,bitwarden,wordpress,dsm, # on liste les sous-domaine, attention à la virgule finale
          - VALIDATION=http # on remplace dns par http et on supprime la variable DNSPLUGIN
          - DHLEVEL=2048
          - EMAIL=mail@ndd.tld
          - ONLY_SUBDOMAINS=false
          - STAGING=false
       volumes:
          - ./config:/config
       restart: unless-stopped

networks:

   macvlan_net:
      external: true

Remarque :

• Si notre certificat racine (ndd.ovh) est déjà géré ailleurs, mais qu'on souhaite avoir un deuxième proxy inversé sur une autre machine (un VPS par exemple) avec le même domaine, on peut passer la variable ONLY_SUBDOMAINS à true. Ainsi le certificat ne sera généré que pour les sous-domaines.

10. Fail2ban

10-A. Configuration

Fail2ban est une application très pratique qu'on retrouve dans DSM, c'est le service qui permet de bannir une personne tentant de se logger plusieurs fois d'affilée de manière infructueuse à un service Synology. Ici, on va pouvoir l'appliquer à ce qu'on veut. Dans DSM c'est configurable dans l'onglet "Blocage".
Il y a cependant une condition, fail2ban se base sur la lecture de logs, et en les analysant il va identifier des IP et des résultats de login : échec ou succès. La plupart des logs d'accès sont lisibles par fail2ban, car il embarque tout un set d'expressions régulières lui permettant d'analyser les logs, mais c'est un point à vérifier en amont.

Fail2ban se base sur ce qu'on appelle des prisons, ou "jails" en anglais. Allons donc dans le dossier de fail2ban :

cd /volume1/docker/swag/config/fail2ban && ls -l $_

• filter.d comprend les fichiers de configuration permettant d'analyser et filtrer le contenu des logs en extrayant les informations utiles au moyen d'expressions régulières.
• action.d comprend les actions à entreprendre quand une analyse répond à un critère de filtrage. Ces dossiers comprennent un grand nombre de fichiers de configuration prédéfinis propres à tout un ensemble d'applications.
  Remarque : Si l'application que vous souhaitez protéger n'est pas incluse, il faudra alors créer vos propres filtres.
• fail2ban.sqlite3 est la base de données embarquée.
• jail.local est le fichier qui nous intéresse en particulier :

1. La section [DEFAULT] définit le comportement global, il peut être écrasé au sein des sections suivantes qui définissent chaque service qu'on souhaite surveiller (maxretry, etc...).
2. Intéressant, et qui n'apparaît pas dans l'impression d'écran, il est possible d'ajouter une directive ignoreip qui permet de whitelister des plages d'IP :

   ignoreip = 172.16.0.0/12 192.168.0.0/16 10.0.0.0/8

   Ici je whitelist les IP pivées qui peuvent vouloir se connecter, pas de risque de me verrouiller du coup.
3. Le fichier jail.local surveille par défaut les 4 services Nginx. On a également un bloc ssh désactivé par défaut. Pour l'activer c'est assez simple :

[ssh]

enabled = true
port    = ssh
filter  = sshd
logpath = /log/host_ssh_auth.log

Notes :

• port : ssh représente ici le port SSH par défaut (22), dans les faits si vous avez changé le port SSH sur votre hôte, mettez directement son numéro.
• filter : cela correspond au nom du fichier .conf qu'on trouvera dans le dossier filter.d, ici on appellera donc le fichier sshd.conf
• logpath : normalement le contenu des logs SSH se trouve dans /var/log/auth.log, pourquoi ne pas mettre ça ?

Si vous écrivez /var/log/auth.log, vous allez surveiller le log d'accès SSH ... au conteneur. A priori ça ne nous intéresse pas, on cherche à lire les logs SSH de l'hôte. Pour que le conteneur y ait accès, il faut les monter via un volume. Il suffit pour cela d'éditer le fichier docker-compose.yml et d'y monter les logs de l'hôte dans un fichier à l'intérieur du conteneur, qu'on définit arbitrairement :

version: '2.1'
services:

   swag:
       image: linuxserver/swag
       container_name: swag
       networks:
          macvlan_net:
             ipv4_address: 192.168.1.145
       cap_add:
          - NET_ADMIN
       environment:
      	  - PUID=1026
          - PGID=100
      	  - TZ=Europe/Paris
          - URL=ndd.ovh
          - SUBDOMAINS=wildcard
          - VALIDATION=dns
          - DNSPLUGIN=ovh
          - DHLEVEL=2048
          - EMAIL=mail@ndd.tld
          - ONLY_SUBDOMAINS=false
          - STAGING=false
       volumes:
          - ./config:/config
          - /var/log/auth.log:/log/host_ssh_auth.log:ro # on ajoute ro pour read-only (lecture seule)
       restart: unless-stopped

networks:

   macvlan_net:
      external: true

On recrée le conteneur :

docker-compose down && docker-compose up -d

On aura maintenant fail2ban qui pourra analyser les connexions SSH sur l'hôte.

Quelques commandes utiles pour vérifier le bon fonctionnement des prisons :

• Pour renvoyer la liste des prisons :

  docker exec -it swag fail2ban-client status

• Pour afficher le statut d'une prison en particulier, ici ssh :

  docker exec -it swag fail2ban-client status ssh

• le terme swag dans les commandes précédentes correspond au nom que vous avez donné au conteneur SWAG.

10-B. Proxy fiable

Par défaut, DSM empêche l'identification de l'IP source, sauf si on a précisément ajouter à la liste des proxy fiables l'IP de notre conteneur swag.
Pour cela, Panneau de configuration -> Sécurité -> Proxies fiables et on ajoute l'IP du conteneur:

On valide, maintenant ce sera l'IP source qui sera lue et non plus l'IP du conteneur SWAG.
Ce qui revêt son importance pour fail2ban, sinon vous allez simplement bannir votre proxy inversé, ce serait bête non ? 🙂 

Pour ceux qui souhaitent pousser la configuration de fail2ban plus en profondeur :

https://www.linode.com/docs/guides/using-fail2ban-to-secure-your-server-a-tutorial/
https://manpages.debian.org/testing/fail2ban/jail.conf.5.en.html (très intéressant)
https://github.com/linuxserver/docker-swag#using-fail2ban (commandes utiles)

11. Conclusion

Ce conteneur est un package tout-en-un pour la gestion de vos certificats de vos accès externes et internes. Et il est assez facile à manipuler une fois qu'on a compris le principe.
Il a surtout l'avantage de ne pas toucher au système, qu'il s'agisse de DSM ou d'une distribution Linux autre. Dans le cas de DSM particulièrement, il est possible de réaliser ce genre de manipulations car DSM utilise Nginx pour son proxy inversé, mais chaque mise à jour de paquet ou d'OS supprimera toutes vos modifications. Il existe un ancien tutoriel de @CoolRaoul pour proxy inversé sur le forum qui explorait justement une solution à ce problème, mais à l'époque le portail des applications DSM n'existait pas encore. 😉 
Enfin c'est tout à fait portable, le jour où vous souhaitez héberger le proxy inversé sur un Raspberry Pi, un VPS, ou tout autre périphérique, il n'y aura qu'à copier vos fichiers de configuration d'une machine à l'autre, et faire les quelques adaptations nécessaires (adresses des services internes + redirection des ports).

Màj : 22/07/2021

Modifié le 6 août 2022 par .Shad.
Ajout précisions

[oracle7]

@.Shad.

Excellent TUTO, bien écrit et parfaitement clair, il devrait en satisfaire plus d'un ...👍 😃

Cordialement

oracle7😏

[Einsteinium]

il y a une heure, .Shad. a dit :

Je n'ai jamais utilisé Plex dont je découvre en même temps que vous, on voit que c'est commenté, ce qui est déjà une bonne chose.
Je n'y connais quasiment rien en Nginx

Attention alors, car la configuration nginx ne ce fait pas par défaut... Je te recommande de faire un tour sur mon tutoriel VPS/4G pour agrémenté ton tutoriel 😉

@Mic13710 Tu as eu la validation un peu rapide 😉

[.Shad.]

Ok je peux très bien faire un lien vers ton sujet, qui rentre dans le détail de la configuration d'Nginx.
Je ne dis pas que la configuration d'Nginx se fait par défaut d'ailleurs, simplement que Linuxserver intègre par défaut des configurations adaptées pour toutes les images qu'ils maintiennent, et ça représente un spectre important des images utilisées par les particuliers qui se servent de Docker.
Je ne compte pas m'attarder sur ce sujet, pour plusieurs raisons :

- Il faudrait que je m'y plonge pour être sûr que je comprends bien tout ce qui est à l'oeuvre, ce qui est sur la liste des prochaines choses à faire. 🙂 
- Tu l'as visiblement déjà très bien fait de ton côté.
- J'utilise cette image sur mon VPS, avec une vingtaine de conteneurs, je n'ai jamais eu à modifier quoique ce soit, quand l'application n'existe pas je récupère une config minimale, et ça a toujours fonctionné.

Donc ce que je vais faire c'est que pour ne pas dire de bêtise, je vais renvoyer vers ton tutoriel pour plus de détail et pour les curieux, si ça te convient. 😉 

Modifié le 14 juillet 2020 par .Shad.

[.Shad.]

J'ai répercuté dans le tutoriel le changement de nom de l'image (linuxserver/letsencrypt ->linuxserver/swag).
Si vous avez mis en place cette solution, il suffit de changer le nom de l'image dans le fichier docker-compose et de recréer le conteneur :

docker-compose pull

puis :

docker-compose up -d

 

[MilesTEG1]

Je me dis que ce tuto pourrais me faciliter la vie quand je crée de nouveaux services via docker et que je veux les rendre dispo en dehors de mon LAN.
Mais j'ai peur que ce soit trop technique pour moi. Et surtout que certains services ne fonctionnent plus, notemment plex.
@.Shad. tu parlais de plex plus haut, c'est compliqué de le faire fonctionner avec ce tuto ?

Actuellement tout fonctionne parfaitement avec le reverse-proxy du NAS. J'avoue que j'ai pas envie de tout casser 😅

[.Shad.]

Cette image couvre surtout un ensemble d'applications, pas seulement le proxy inversé : renouvellement automatique des certificats, hébergement de sites web, fail2ban, authentification deux facteurs, etc...

Et surtout étendre ces fonctionnalités à toutes tes applications, pas seulement Synology.
Maintenant la prise en main est plus complexe surtout pour la partie fail2ban et authentification deux facteurs.
Deux aspects que je n'aborde pas dans le tutoriel. J'essaierai d'ici peu de décrire leur mise en place.

Au départ je ne m'en servais que pour la partie création et renouvellement de certificats et proxy inversé, après avoir testé HAProxy sur pfSense, très bon logiciel mais surdimensionné par rapport à mon besoin. Depuis j'ai testé authelia (2FA) et je trouve cette image vraiment très bien pensée et réalisée, tout s'imbrique parfaitement. Je devrais pouvoir écrire un petit guide maintenant que j'ai un peu pratiqué ces aspects-là.

[Einsteinium]

Question pourquoi ne pas mettre directement en bridge sur le nas port 443 ? sans webstation ce port est libre, voir en mettant un port plus exotique le cas échéant, le pare-feu du routeur fessant le travail 🙂

Avec la transformation swag, je penses que tu devrais aller un peu plus loin, surtout avec fail2ban.

[.Shad.]

Il y a 9 heures, Einsteinium a dit :

Question pourquoi ne pas mettre directement en bridge sur le nas port 443 ? sans webstation ce port est libre, voir en mettant un port plus exotique le cas échéant, le pare-feu du routeur fessant le travail 🙂

Si je mets un port plus exotique, ça casse la possibilité d'utiliser le même FQDN en local qu'à distance. A distance ça marchera car j'aurai la chaine 443 (routeur) -> x443 (NAS) -> 443 (conteneur). En local ce sera directement x443 (NAS) -> 443 (conteneur). Il me faudrait donc une adresse toto.ndd.tld:x443 en local et toto.ndd.tld:443 à distance. Je trouve ça beaucoup moins pratique.

Ok pour Webstation, je suis toujours frileux pour arrêter des processus du NAS, je ne sais pas à quel point Nginx sur DSM ne s'imbrique pas dans d'autres process.
Reste qu'ici on a l'avantage du macvlan sans en avoir les inconvénients (pas besoin de créer d'interface virtuelle).
Mais je vais l'ajouter comme possibilité effectivement, pour ceux qui veulent aller au plus rapide et qui n'utilisent pas Webstation par ailleurs.

Il y a 9 heures, Einsteinium a dit :

Avec la transformation swag, je penses que tu devrais aller un peu plus loin, surtout avec fail2ban.

Oui c'est prévu comme je disais dans le post juste avant, ajouter fail2ban et authelia, ça fait quelques temps que je m'en sers mais je n'ai pas encore eu le temps de rentrer plus dans le détail. Juste l'activation d'authelia dans nginx, sa configuration fera l'objet d'un tutoriel à part entière, si je l'ajoute ici ça va faire trop. 😉 

Modifié le 3 décembre 2020 par .Shad.
grammaire

[Einsteinium]

L’utilisation du même domaine localement... du loopback quoi, c’est le routeur qui gère le loopback, donc niveau port cela ne dérange pas qu’il soit exotique. (En tout cas pas avec le RT2600)

Fail2ban fessant parti du docker, tu peux le rajouté dans ce tutoriel, les notifications, les réglages à faire ou a rajouter 😉

[.Shad.]

Oui mais pour ceux qui n'ont pas de routeur dédié et une box qui ne gère pas le loopback ?
Des box de geek comme les Freebox ce n'est pas la norme, la plupart ne tolèrent que très peu de personnalisation. Quand tu peux personnaliser ton serveur DHCP tu es déjà content.

Et sauf erreur de ma part, ceux qui utilisent un serveur DNS avec une zone locale ne vont pas faire appel au loopback, la box/routeur ne sera même pas sollicitée.

De toute façon je t'ai dit j'ajouterai l'alternative que tu proposes quand j'ai un créneau pour m'y atteler, au moins ça couvrira l'ensemble des infrastructures possibles. 👌

Et pour fail2ban, j'ai bien dit que je l'intègrerai à ce tutoriel, c'est assez basique, et je mettrai le lien vers le guide de Linuxserver qui est bien foutu pour ceux que la langue de Shakespeare ne rebute pas. C'est Authelia pour lequel je compte faire un tutoriel dédié, c'est autrement plus touffu que fail2ban.

[MilesTEG1]

il y a 49 minutes, Einsteinium a dit :

L’utilisation du même domaine localement... du loopback quoi, c’est le routeur qui gère le loopback, donc niveau port cela ne dérange pas qu’il soit exotique. (En tout cas pas avec le RT2600)

Fail2ban fessant parti du docker, tu peux le rajouté dans ce tutoriel, les notifications, les réglages à faire ou a rajouter 😉

Il y a des routeurs qui ne gèrent pas le loopback... Par exemple certaines livebox4 et 5 ne le gère pas... (me demande pas pourquoi 😅)

Sinon on écrit "faisant" pas fessant 😛 qui n'a pas du tout la même signification 🤪 je vois mal Fail2ban fesser docker (def dans le lien).

edit : grillé par @.Shad. pour le loopback 😅

[.Shad.]

Ajout d'un guide succinct pour fail2ban et de remarques suite à celles de @Einsteinium

[Invité]

Après avoir installé SWAG aujourd'hui, je tombe sur ton tuto ce soir !! Belle rédaction !

J'en est commencé une, mais au final, cela ne vaut peut être pas le coup 😄

Je me permet une question par rapport au proxy, tu n'a pas de soucis pour remonter l'ip réel d'acces ?

Par exemple pour moi, l'adresse indiquée par un conteneur avec lequel j’accède via SWAG sera toujours celle du proxy swag et non la véritable adresse ip de la personne qui se connecte !  Et donc, impossible d'utiliser fail2ban, forcément.

J'ai demandé support sur le discord Linuxserver, ils m'ont indiqué que c'était une limitation de DSM/Synology qu'il n'y avait pas moyen facile de régler ceci.

j'ai vu ceci dans le panneau de config > Securité

J'ai mis l'ip de mon proxy ( qui est en bridge ), mais cela ne change rien.

 

Exemple : ( 192.168.32.1 étant l'ip du conteneur SWAG )

Log d’accès de Gotify depuis mon tel en 4G :

Log d’accès de Jellyfin depuis une connexion ADSL extérieur :

 

[.Shad.]

Alors le fail2ban je ne l'ai pas installé sur le NAS, car je me connecte en SSH chez moi depuis l'extérieur uniquement via mon serveur debian, qui n'accepte qu'une clé publique. Et lui possède les clés pour mes différents NAS et périphériques du réseau.

Par contre je l'utilise sur mon VPS, et là en faisant une configuration identique :

On voit bien les IP publiques qui sont bannies dans les logs remontés par Loki.

Pour les applications, où tu passes par le proxy inversé, normalement /config/nginx/proxy.conf contient :

proxy_set_header X-Real-IP $remote_addr;

Et les fichiers de configuration dans /config/nginx/proxy-confs/ y font appel via un include :

# for Synology DSM GUI

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name dsm-ds918.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    # enable for Authelia
    include /config/nginx/authelia-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /ldaplogin;

        # enable for Authelia
        include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app ds918.ndd.tld;
        set $upstream_port 5000;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
}

Si je regarde les logs d'Emby, en me connectant en 4G avec mon smartphone :

2020-12-10 22:42:53.392 Info Server: http/1.1 Response 200 to 178.144.167.69. Time: 4ms. http://emby.ndd.tld/Items/49541/Images/Thumb?maxWidth=509&tag=29287fdde9c02f68f2e9d1928219d32a&quality=90
2020-12-10 22:42:53.468 Debug ImageProcessor: Image encoding to /config/cache/images/resized-images/1/14c9ca76-8074-cb88-71f7-6d6f09060a08.webp took 75ms for /config/metadata/library/df/df0881c61686b56c0fd4a14516bb68f8/landscape.jpg
2020-12-10 22:42:53.468 Info Server: http/1.1 Response 200 to 178.144.167.69. Time: 76ms. http://emby.ndd.tld/Items/49525/Images/Thumb?maxWidth=509&tag=dd3e4629b2a834901fc1372408ed0966&quality=90

Les logs de pfSense :

Dec 10 23:55:24	php-fpm	43363	/index.php: Successful login for user 'username' from: 192.168.100.105[178.144.167.69] (Local Database)

Dans tous les cas on voit l'IP réelle, vérifie donc déjà que tu inclus bien cette directive dans ta config Nginx, mais par défaut c'est le cas normalement.

J'avoue que je ne vois pas le rapport avec Synology, car ici tu translates directement depuis ton routeur vers ton conteneur swag, pour moi c'est transparent.

Modifié le 10 décembre 2020 par .Shad.

[Invité]

Il y a 16 heures, .Shad. a dit :

J'avoue que je ne vois pas le rapport avec Synology, car ici tu translates directement depuis ton routeur vers ton conteneur swag, pour moi c'est transparent.

Malheuresement, cela ne l'est pas et l'option "proxy fiable" dans DSM soit elle ne marche pas, soit je n'ai pas compris a quoi elle servait !

J'ai passé pas mal de temps dessus, et je n'arrive pas a voir une autre IP que celle du proxy. Les différents posts a ce sujet que j'ai pu trouver sont asser vieux, en anglais et ne propose pas de solution a cela.

 

[.Shad.]

Quand tu NAT vers d'autres périphériques que le NAS tu n'as pas ce problème ?

[Invité]

Il y a 4 heures, .Shad. a dit :

Quand tu NAT vers d'autres périphériques que le NAS tu n'as pas ce problème ?

Tu veut dire utiliser le reverse vers un service autre que sur le Syno ?

J'ai rien d'autre a part un raspberry avec adguard, mais je fait pas de reverse dessus.

[.Shad.]

Je pense que ça peut venir du fait que tu sois en bridge.
Essaie ce que je propose dans le tutoriel, tu mets swag en macvlan, et si tu n'as pas mis en place d'interface virtuelle pour communiquer avec le NAS, tu rejoins aussi un réseau bridge comme je le propose, et tu te serviras de l'IP passerelle de ce réseau pour communiquer avec tes applis Synology.

Parce que du coup moi quand je NAT depuis le routeur, c'est vers l'IP du conteneur dans son réseau macvlan, il n'y a pas de NAT hôte-conteneur nécessaire comme en bridge.
A mon avis le NAT hôte-conteneur n'y est pas pour rien.

Modifié le 11 décembre 2020 par .Shad.

[Invité]

Si j'ai le temps j'essayerai avec un macvlan alors.

 

Pour l'instant j'ai configurer comme recommandé par linuxserver :

version: "2"
services:
  swag:
    image: linuxserver/swag
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1030
      - PGID=100
      - TZ=Europe/Paris
      - URL=xxxxxx.fr
      - SUBDOMAINS=wildcard
      - VALIDATION=dns
      - DNSPLUGIN=ovh
      - EMAIL=xxxxxxx@gmail.com
    volumes:
      - /volume1/docker/swag/config:/config
    ports:
      - 443:443
      - 80:80
    restart: unless-stopped

 

[.Shad.]

Tu as raison, j'observe le même comportement pour DSM, c'est l'adresse de mon proxy inversé qui est détectée dans le journal des logs, pas le PC que j'utilise.

Comme toi, je ne trouve rien de probant, et effectivement ça ne me fait ça qu'avec Synology.

Je vais continuer de chercher.

[Invité]

Merci pour ton retour, comme dit ici : https://www.nas-forum.com/forum/topic/67311-tuto-certificat-ssl-reverse-proxy-via-docker/?tab=comments#comment-1319420244

Il y a dans DSM une options procy fiable, j'ai renseigné l'adresse de mon proxy qui est en bridge mais cela ne change rien.

Pense tu que si je passe en macvlan cela pourrai résoudre mon problème ?

 

[.Shad.]

Alors chez moi ça marche maintenant, mais mon conteneur SWAG est sur une autre machine physique.

Je pense que le fait d'utiliser un réseau macvlan peut potentiellement jouer un tour à DSM. 😉

A tester 🙂 mais dans ce cas-là il te faudra bien créer une interface virtuelle, pas comme dans mon tutoriel (que j'éditerai d'ailleurs, sinon fail2ban inutilisable pour tout ce qui est hébergé sur du Synology), et le backend ne sera plus l'IP physique actuelle mais l'IP virtuelle. Au cas où, je reprends la procédure à la fin de mon tutoriel introductif (voir signature).

Modifié le 12 décembre 2020 par .Shad.

[Invité]

D'accord, j'avais pour idée de faire un reseau comme ceci :

docker network create -d macvlan --subnet=192.168.0.0/24 --gateway=192.168.0.254 --ip-range=192.168.0.100/32 -o parent=eth0 macvlan-swag

Tu pense que je serais donc obliger de faire ceci aussi pour créer cette interface ?

ip link add macvlan-swag link eth0 type macvlan mode bridge
ip addr add 192.168.0.100/32 dev macvlan-swag
ip link set dev macvlan-swag address AA:BB:CC:DD:EE:FF
ip link set macvlan-swag up
ip route add 192.168.0.100/32 dev macvlan-swag

Si je comprend bien, cette interface, sera a scripter afin de la re-créer en cas de re-boot du nas ?

[.Shad.]

Pour le script de création du réseau, ça me semble pas mal, perso je n'ai réussi à créer qu'un seul réseau macvlan pour un port ethernet donné du NAS. Donc à ta place je ne ferais pas un /32 dans l'ip-range, histoire d'avoir quelques IP disponibles au cas où. Peut-être un /28 (13 IP dans ma config) ? vérifier avec un calculateur d'IP que tu ne chevauches rien.

Attention par contre dans le script de création de l'interface, tu as mis 192.168.0.100/32 pour l'IP virtuelle.
Dans le script de création du réseau macvlan, les IP dans ip-range sont les IP disponibles pour les conteneurs.
L'IP virtuelle sera une "deuxième" IP du NAS (que tu verras par exemple dans Synology Assistant). Elle ne doit donc pas être comprise dans l'ip-range.

J'ai une tâche planifiée qui exécute un script permettant de remonter effectivement l'interface à chaque redémarrage :

#!/bin/sh

# Script permettant la communication entre
# un conteneur appartenant a un reseau macvlan et son hote
# A lancer au demarrage de l'hote

# Creation de l interface macvlan sur l hote
ip link add mac0 link eno1 type macvlan mode bridge

# Configuration de l interface avec l adresse reservee
ip addr add 192.168.100.205/32 dev mac0
ip link set dev mac0 address 00:aa:bb:cc:dd:01
ip link set mac0 up

# On fait une route entre les IP du reseau macvdef et l'interface
ip route add 192.168.100.160/28 dev mac0

 

Modifié le 13 décembre 2020 par .Shad.