[TUTO] Certificat SSL & reverse proxy via Docker

[bruno78]

Bonjour, (à propos du script, pas de nginx)

j'utilise ce script depuis déjà un bon moment (pour le docker PiHole). Il est lancé au démarrage du NAS, moyennant un timer du 60secondes (sleep 60) pour être sûr que les interfaces réseau sont montées au moment de l’exécution du script. Or j'ai eu depuis quelques jour des déboires avec justement la résolution DNS, jusqu'à m’apercevoir que ce réseau n'était plus opérationel (link down et route absente). Il a suffit de le remettre up et recréer la route pour que cela reparte.

=> je ne sais pas pourquoi il était passer down, mais cela est concomitant dans le temps avec un reboot du NAS. J'ai donc passé le timer à 90sec, et rajouter via grafana une surveillance de l'accessibilité du docker Pihole (sinon tout le monde bascule sur le DNS secondaire et on ne se rend pas compte du problème tout de suite).

=> je vérifie cela au prochain reboot.

Bruno78

[MilesTEG1]

Hello,

Je n'ai pas tout compris (essentiellement parce que j'ai suivi de loin) vos derniers échanges, mais si vous avez une LiveBox4, méfiez vous de la dernière MAJ de firmware :

Le loopback de la LB4 semble ne fonctionne plus depuis la MAJ 3.103.16 (post sur HFR)

Infos sur les forums Orange aussi.

Y a probablement aucun lien avec votre soucis, mais sait-on jamais 🙂 

 

 

[Invité]

Donc je récapitule :

Macvlan :

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

Range : 192.168.0.100/28 , soit 192.168.0.96 à 192.168.0.111

 

Création de l'interface :

ip link add macvlan-swag link ovs_eth0 type macvlan mode bridge
ip addr add 192.168.0.112/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/28 dev macvlan-swag

Donc, au final, on choisi une adresse  hors plage, donc ici 192.168.0.112 sera l'adresse que j'utiliserai pour le conteneur swag

 

Dans ton tuto Docker, j'avoue ne pas comprendre cette phrase :

Citation

je pourrai créer une interface avec l'IP 192.168.0.140 tel que DSM sera également accessible à l'adresse 192.168.0.200:5000

 

Je ferais probablement cette mise en place Lundi, je vous tiendrais au jus 🙂

Modifié le 13 décembre 2020 par Invité
Correction /28

[bruno78]

@EVOTk bonjour,

je serais surpris que 192.168.0.100/24 représente 192.168.0.96 à 192.168.0.111 ....

Le /24 représente l'ensemble de la plage 192.168.1.0 à 192.168.1.255.

Si tu veux 16 adresses (14 adresses utilisables pour des hosts) de 192.168.0.96 à 192.168.0.111, il te faut un réseau en /28

[Invité]

Effectivement, merci, dans ma tête c'était /28 et j'ecris /24. .

J'ai édité mon message 

 

Edit :

Erreur, lors de la derniere ligne de commande :

Pourtant l'interface semble correctement créer. Suite demain !

Modifié le 13 décembre 2020 par Invité

[bruno78]

@EVOTk,

tu dois créer une route vers un réseau / subnet, pas vers une machine / host individuelle.

Sauf erreur de ma part, ta commande d'ajout de route devrait donc être a priori : ip route add 192.168.0.96/28 dev maclan-swag

@.Shad.

par ailleurs ce matin de bonne heure j'en ai profité pour regarder le problème de perte de connectivité avec le docker Pihole :

1. sur un reboot complet du NAS, les interfaces et les routes remontent bien avec le timer originel de 60s dans la tache planifiée au demarrage.
2. j'ai par contre reproduit le problème en faisant un stop / start du paquet Docker. Je ne sais pas si c'est réellement ce qui c'était passé pour moi à l'origine. Il y a peut-être d'autres cas dans lesquels cela arrive ? ... je continue le monitoring. Évidemment une solution pourrait être de relancer automatiquement la création de l'interface et du routage vers le docker PiHole en cas de détection de perte de connectivité, mais pour le moment je préfère laisser "en manuel" pour voir si cela se reproduit et en quelles circonstances.

Bruno78

[.Shad.]

Le 13/12/2020 à 09:51, EVOTk a dit :

Dans ton tuto Docker, j'avoue ne pas comprendre cette phrase :

Citation

je pourrai créer une interface avec l'IP 192.168.0.140 tel que DSM sera également accessible à l'adresse 192.168.0.200:5000

Tournure très maladroite, je voulais dire que que si l'IP de DSM est normalement 192.168.0.100, en créant une interface virtuelle, je pourrai avec un conteneur dans la plage d'IP spécifiée du réseau macvlan (dans mon cas par exemple 192.168.0.140) accéder à DSM via l'interface virtuelle à l'adresse 192.168.0.200
Je profite pour reformuler, merci @EVOTk👌

D'ailleurs j'y pense, mais je pense qu'on peut limiter l'accessibilité à cette interface aux seuls conteneurs sur réseau macvlan, histoire d'éviter d'avoir 2 NAS qui apparaissent dans Synology Assistant, dans l'explorateur Windows, etc... Il suffira de limiter les sources pour cette interface, j'ai un petite idée de comment faire mais il faut que je regarde plus en détail.

Pour ton problème, peux-tu remettre ton script de création de réseau macvlan, et ton script de création d'interface, qu'on ait toutes les cartes en main ? 😉 

@bruno78 : Pour moi ça paraît étrange qu'un redémarrage de Docker puisse entrainer quoique ce soit. En effet quand tu crées l'interface virtuelle, tu ne fais appel en rien à ce qui concerne Docker, hormis le sous-réseau macvlan :

ip link add macvlan-swag link ovs_eth0 type macvlan mode bridge
ip addr add 192.168.0.112/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/28 dev macvlan-swag

Or ce sous-réseau est recréé quand tu redémarres le paquet Docker.
Comme je le vois, une fois que l'interface est là elle ne bouge plus jusqu'au prochain redémarrage. Ce qui peut poser éventuellement problème, c'est que le sous-réseau macvlan ne soit pas encore initialisé quand le script de création de l'interface virtuelle s'exécute, le système pourrait te dire que le sous-réseau macvlan n'existe pas, et qu'il n'aille pas plus loin, dans ce cas-là, à moins de complexifier fort le script, je pense qu'il suffit d'allonger le timer (60s -> 120s par exemple).

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

[bruno78]

@.Shad. : je te confirme (je viens de le refaire), que stopper la package Docker a pour conséquence de supprimer le link macvlan-swag, et donc tout ce qui suit ....

[.Shad.]

Ouais donc il faut réexécuter la tâche depuis le planificateur quand par exemple on met à jour le paquet.

[Invité]

Bon, il y a quelques chose que je n'ai visiblement pas compris.

J'ai créé mon interface, sur ma box, le Nas est visible avec les 2 IPs

j'ai créer l'interface

Le NAS est joignable avec les 2 IPs, le créer mon conteneur, mais là impossible de le joindre si je tape l'ip 192.168.0.112 cela me redirige auto vers 192.168.0.112:5000 soit l'interface de DSM, alors que cela devrait affichier la racine de mon site web présent dans SWAG

[.Shad.]

Donc si tu veux essayer de joindre ce qui est hébergé sur le port 80 du NAS :

Tu tapes par exemple : https://site.ndd.tld avec site.ndd.tld pointant vers l'IP macvlan du conteneur SWAG (comprise dans ta plage 192.168.0.100/28).
Dans SWAG tu rediriges les requêtes site.* vers 192.168.0.112 et sur le port 80.

C'est bien ce que tu as ?

[Invité]

Salut @.Shad.Désolé pour cette réponse tardive, au final j'ai réussi a .... rien 😄

Mon IP 192.168.0.112 me redirigé bien sur l'interface de DSM, mais c'est tout. Impossible de joindre le port HTTP, ou autre cela me rediriger automatique sur le port personnalise de l'interface de DSM. 

Au final, cela ne marché pas, ce matin, le reverse ne fonctionne plus, impossible de le joindre, et pourtant aucune erreur dans les logs nulle part ... Le reboot a résolu le problème, mais je ne sais pas se que c'était ??

On m'a conseillé d'autre modifs que j'ai testé aujourd'hui mais cela ne fonctionne pas non plus. Je suis de plus en plus entrain de réfléchir a une autre organisation de mon réseau, je vais surement étudier pour mettre mon reverse sur une autre machine, cela résoudra le problème. En tout cas, dans l’immédiat, j'abandonne l'idée d'avoir la véritable ip dans les logs. Quand je voit les bidouilles qu'il faut faire, et en plus sa marche toujours pas, je me dit que même si je réussi, cela est loin d'être stable, ....

[.Shad.]

C'est ce vers quoi je m'orienterais également à ta place.

De mon côté je vais essayer de reproduire ton cas d'utilisation, et essayer de comprendre le pourquoi du comment. Je ne vois aucune limitation théorique qui génère ce problème chez toi.

Il faudra que j'adapte le tutoriel en conséquence.

Merci de ton retour. 😉

[Invité]

Désolé, de n'avoir pas plus de détails a te fournir. J'avoue que je me suis énervé un bon moment dessus, sans chose concluante ( voir même, pire ), ce qui est plutôt frustrant 😅

Au cas ou cela t’intéresse, on m'avais aussi donné une autre technique :

Editer dockerd.json > nano /var/packages/Docker/etc/dockerd.json

Pour ma part il contient ceci :

{
   "data-root" : "/var/packages/Docker/target/docker",
   "log-driver" : "db",
   "registry-mirrors" : [],
   "storage-driver" : "btrfs"
}

Il fallait l'éditer de la sorte :

{
   "data-root" : "/var/packages/Docker/target/docker",
   "log-driver" : "db",
   "registry-mirrors" : [],
   "storage-driver" : "btrfs",
   "iptables": true,
   "ip-forward": true,
   "ip-masq": true,
   "selinux-enabled": false,
   "userland-proxy": false
}

Ensuite, faire cette commande iptables pour retrouver ces accès au conteneur :

iptables -t nat -A PREROUTING ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER

Après cette commande, j'avais de nouveau accès a Portainer par exemple mais le proxy ( entre autre ) ne fonctionnai plus, enfin pour être exact, n'était pas joignable.

Enfin bref, j'ai pas réussi 😄

[.Shad.]

En fait j'y pense, le seul truc que je vois qui pourrait provoquer ce que tu as, c'est que les applications Synology ne s'exposent pas sur l'IP virtuelle.

De souvenir, quand on interroge un port non utilisé du NAS il te renvoie DSM...

[Invité]

Oui, mon reverse était sous 50080/50443 quand je taper les ip+port de l'interface virtuelle ( même en navigation privé pour etre sur ) j’étais systématiquement rebasculer sur l'interface de DSM !

Au vu de cela, j'ai modifié le conteneur SWAG pour le replacer en 80/443, mais cela n'a rien changé.

[.Shad.]

Refonte du tutoriel d'ici quelques jours/semaines, je trouve sa mise en place un peu trop complexe, elle marche très bien mais elle peut faire peur de prime abord, on privilégiera l'orientation donnée par @Einsteinium.

Ajout prochain d'un tutoriel (à part) pour Authelia, meilleure application 2020 pour moi.

[Einsteinium]

Garde dans un coin où fait un tutoriel la partie réseau (l’émancipation d’un dock avec son ip et communication avec l’hôte)

[.Shad.]

J'ai vérifié ce que tu disais, qu'en désinstallant Webstation on libérait le port 443 par la même occasion, c'est faux. il écoute toujours dessus, et il écoute sur bien d'autres ports également.
Il me semble donc peu recommandé de vouloir faire en sorte de libérer totalement ces deux ports sur le NAS, la solution du macvlan me semble toute indiquée.

@EVOTk : j'ai reproduit l'installation de swag sur le NAS, l'ajout à la liste des proxy fiables marche parfaitement. Que ce soit en full macvlan, ou en macvlan/bridge comme dans le tutoriel.

 

[MilesTEG1]

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

Ajout prochain d'un tutoriel (à part) pour Authelia, meilleure application 2020 pour moi.

Oh !!! J'attends ce tuto avec impatience 😉 Et je me lancerais dans la lecture (et l'application)  du nouveau dès qu'il sera dispo ^^

[.Shad.]

Tutoriel révisé.

[MilesTEG1]

Hello @.Shad.
Je suis en train de suivre le tuto, et je bloque sur l'étape de la création du réseau macvlan...
TU te rappelles peut-être qu'il y a un mois (je crois) j'ai suivi ton tuto pi-hole @ macvlan en l'adaptant pour AdGuard Home (qui fonctionne très bien d'ailleurs), mais j'ai eu alors un soucis, après la création du réseau macvlan, lors de l'exécution du script bridge-macvlan : ça n'a jamais fonctionné avec une plages d'ip... 192.168.2.210/28
J'ai du créer un réseau macvlan avec une seule IP avec 192.168.2.210/32 et le script bridge-macvlan a pu alors fonctionner.

Du coup je me dis que je vais procéder de la même manière : créer un nouveau réseau macvlan, puis faire la même modif dans le script bridge-macvlan de swag...
Mais ça ne passe pas :

Faut-il que je cherche vraiment à faire un réseau macvlan à plusieurs IP et donc chercher à faire un script bridge-macvlan qui fonctionne ?

Ou bien existe-t-il une astuce pour créer un second réseau macvlan ?

Merci par avance de ton aide 😇

Précisions : 
Je souhaite avoir 192.168.2.210 pour AdGuard, et 192.168.2.211 pour swag.
Et pour les IP Virtuelles : 192.168.2.230 pour AdGuard, et 192.168.2.231 pour swag.

Ces IP et celles qui les entourent ne sont pas dans la page d'IP du DHCP de mon routeur :

PS : Les calculateurs d'IP/masques, me changent systématiquement mon IP de départ en 192.168.2.208/28 si je tente 192.168.2.210/28.
Est-ce que ça fonctionnerait si je faisais ce réseau là ? (j'entends le script de bridge-macvlan)

J'ai du mal à comprendre comment ça fonctionne...
Pour 192.168.2.208/28 les adresses utilisables commencent à 192.168.2.209 ?? pourquoi pas 192.168.2.208 ? Et se finissent 192.168.2.222 et pas 192.168.2.223...
Je sais pas trop ce qu'est une adresse de broadcast...

Modifié le 24 mars 2021 par MilesTEG1

[.Shad.]

Il y a 3 heures, MilesTEG1 a dit :

Je suis en train de suivre le tuto, et je bloque sur l'étape de la création du réseau macvlan...
TU te rappelles peut-être qu'il y a un mois (je crois) j'ai suivi ton tuto pi-hole @ macvlan en l'adaptant pour AdGuard Home (qui fonctionne très bien d'ailleurs), mais j'ai eu alors un soucis, après la création du réseau macvlan, lors de l'exécution du script bridge-macvlan : ça n'a jamais fonctionné avec une plages d'ip... 192.168.2.210/28
J'ai du créer un réseau macvlan avec une seule IP avec 192.168.2.210/32 et le script bridge-macvlan a pu alors fonctionner.

Si tu as autorisé qu'une seule IP dans ton sous-réseau macvlan, c'est normal que tu ne puisses pas y ajouter un nouveau conteneur.

Tu peux essayer de supprimer ton réseau macvlan, et retenter de créer avec un /30 au lieu de /28 pour l'ip-range, voir si ça change quelque chose.

Il y a 4 heures, MilesTEG1 a dit :

Faut-il que je cherche vraiment à faire un réseau macvlan à plusieurs IP et donc chercher à faire un script bridge-macvlan qui fonctionne ?

Ou bien existe-t-il une astuce pour créer un second réseau macvlan ?

Une interface physique ne peut avoir qu'un seul réseau macvlan qui lui est rattaché.
Ou alors tu utilises un autre port RJ45 de ton NAS.

Il y a 4 heures, MilesTEG1 a dit :

Précisions : 
Je souhaite avoir 192.168.2.210 pour AdGuard, et 192.168.2.211 pour swag.
Et pour les IP Virtuelles : 192.168.2.230 pour AdGuard, et 192.168.2.231 pour swag.

Tu n'as pas une interface virtuelle par conteneur, tous les conteneurs macvlan utilisent la même IP virtuelle pour communiquer avec le NAS.

Il y a 4 heures, MilesTEG1 a dit :

J'ai du mal à comprendre comment ça fonctionne...
Pour 192.168.2.208/28 les adresses utilisables commencent à 192.168.2.209 ?? pourquoi pas 192.168.2.208 ? Et se finissent 192.168.2.222 et pas 192.168.2.223...
Je sais pas trop ce qu'est une adresse de broadcast...

Pour ça je te conseille de chercher sur Google, c'est pas spécialement ce qu'il y a de plus fun. C'est du calcul, et les calculateurs sont là pour ça. Fais-leur confiance.

Pour le broadcasting, pas sûr que ça t'aide, c'est l'adresse de diffusion réservée sur un sous-réseau. Dans ton réseau local, c'est 192.168.2.255
https://en.wikipedia.org/wiki/Broadcast_address

[.Shad.]

@MilesTEG1 Pour ton problème concernant l'erreur RTLINK, essaie justement comme tu le proposes avec 192.168.2.208/28, ça te donnera une range de 209 à ...
Chez moi, j'utilise la plage 192.168.100.160, ça commence aussi à 161 jusqu'à ...

Et du coup tu mettras 209 pour SWAG par exemple, pour ne pas laisser d'IP non utilisée en début de pool du sous-réseau macvlan.

[MilesTEG1]

@.Shad.
Merci pour tes réponses.
Je tente tout à l'heure la recréation du réseau macvlan, et aussi du coup le script bridge-macvlan avec les modifs de réseau.
J'espère que les clients de Adguard migreront sur le DNS secondaire le temps des manips ^^