Perso je fais avec les listes de bases, pour justement éviter le blocage à outrance et les faux-positifs.

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

Perso je fais avec les listes de bases, pour justement éviter le blocage à outrance et les faux-positifs.

Oui, bonne idée,
Tu complètes avec les blacklists/whitelists ?

@.Shad. 
Petite question : je suis en train d'envisager le test du Link Aggregation entre mon NAS et mon switch. 
Est-ce que ça va poser un problème pour le reseau macvlan et l'IP virtuelle du NAS (faite avec le script) ?

@.Shad. Je m'autorépond 🙂

Il faut changer un truc :

#ip link add macv0 link ovs_eth0 type macvlan mode bridge   # Avec le Link Agrgegation, il faut changer ovs_eth0
ip link add macv0 link ovs_bond0 type macvlan mode bridge   # par ovs_bond0

Et en faisant ifconfig je m'aperçois que j'ai une IPv6 sur cette interface :

Est-ce qu'il est possible de la supprimer ? Voir de ne pas l'avoir à la création de cette interface virtuelle ?

 

edit : haha, j'avais autre chose à modifier ! Le réseau macvlan lui-même... Le script de création du réseau macvlan doit être modifié de la même manière en replaçant ovs_eth0 par ovs_bond0.

Modifié le 21 avril 20214 a par MilesTEG1

Bon et bien je n'arrive pas à faire fonctionner le réseau macvlan.
L'ip macvlan ne fonctionne pas. Et je ne sais pas pourquoi.

Oui, tu dois identifier le bon0 dans l'interface

il y a 39 minutes, Dimebag Darrell a dit :

Oui, tu dois identifier le bon0 dans l'interface

J'ai essayé en mettant ovs_bond0, mais ça n'a pas fonctionné... Du coup, sauf si on trouve pourquoi ça ne fonctionnait pas, je suis revenu en arrière et enlevé l'aggrégation.

Je n'ai encore jamais essayé de mettre un bond sur mon NAS (pas l'utilité), mais pour faire ça proprement je dirais :

- Suppression de l'interface virtuelle :

ip link delete mac0

- Arrêt (voir suppression) des conteneurs sur le réseau macvlan.
- Suppression du réseau macvlan.
- Changer dans le script de l'interface virtuelle, dans le script du réseau macvlan, et dans le fichier docker-compose de pihole (ovs_)eth0 par (ovs_)bond0.
- Recréation du réseau macvlan.
- Recréation de l'interface virtuelle.
- Recréation des conteneurs présent sur le réseau macvlan.

@.Shad.
C'est bien ce que j'ai fait. Mais ça n'a pas fonctionné...

Ca veut rien dire ça n'a pas fonctionné, y a bien une erreur quelque part.
Dans /var/log/messages, /var/log/syslog, etc...

j'ai pas regardé les logs... mais la page internet ne se chargeait pas.

Je retenterais demain pour voir.

@.Shad. Faut que je regarde quoi d'autres comme log ?

 

Aucune idée, je ne comprends déjà pas ce que veut dire ça ne marche pas.
Commence déjà par ces deux-là, une fois tout remis au propre.

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

Aucune idée, je ne comprends déjà pas ce que veut dire ça ne marche pas.

Page web inaccessible.

J'ai fait mon réseau macvlan avec ça :

docker network create -d macvlan \
--subnet=192.168.2.0/24 \
--ip-range=192.168.2.208/28 \
--gateway=192.168.2.1 \
-o parent=ovs_bond0 \
macvlan-network

Et le lien avec l'ip virtuelle avec ça :

ip link add macv0 link ovs_bond0 type macvlan  mode bridge
ip addr add 192.168.2.230/32 dev macv0
ip link set dev macv0 address 5E:00:01:02:03:04
ip link set macv0 up
ip route add 192.168.2.208/28 dev macv0

Sachant que 192.168.2.230 est l'ip virtuelle que j'ai choisie pour mon conteneur, en dehors du DHCP du routeur,
L'IP macvlan du conteneur lui-même est 192.168.2.210.
Le réseau macvlan contenant les IP de .2.209 à .2.222 (car vu qu'on ne peut faire qu'un seul réseau macvlan, autant se laisser la possibilité d'avoir plusieurs IP.

Et bien, le conteneur se lance, mais n'est pas accessible sur son IP 192.168.2.210...

Modifié le 21 avril 20214 a par MilesTEG1

Mais que disent les logs du conteneur Pi-hole ? faut chercher partout où tu peux. Page inaccessible ne veut pas dire que le conteneur lui-même est planté.
Est-ce que l'interface virtuelle fonctionne correctement ? est-ce que tu sais la ping depuis un pc ?

Il y a pléthore de manière de diagnostiquer d'où vient le problème. Et je ne peux pas t'aider plus que te donner des idées. 😛 

Modifié le 22 avril 20214 a par .Shad.

Je me suis commandé un nouveau switch (fallait que je change car je vais avoir besoin de plus de port dans mon bureau). Je teste demain dès réception à nouveau l'agrégation de lien.

J'avais pas pingé l'IP virtuelle hier, mais ni elle ni l'ip macvlan de mon AdGuard ne répondait dans le navigateur. Je crois que j'avais "page introuvable".
Le conteneur lui-même était lancé, et les log me disait qu'il fonctionnait.

Je regarde plus en détail demain. Voir s'il faut, refaire une installation propore de AdGuard, sans conserver mes données de paramétrage, avec un autre nom de conteneur.

Tu as testé comment l'IP virtuelle ? tu as tapé quoi dans ton navigateur ?

@.Shad.

j’ai lancé la connexion sur l’IP définie dans mon docker-compose : 192.168.2.210.

Aucune réponse via cet url.

Et même chose avec l’ip virtuelle.

Là, quand tout fonctionne bien , l’ip du conteneur m’amène bien sur adguard et l’iPad virtuelle sur ce message :

Web Station has been enabled. To finish setting up your website, please see the "Web Service" section of DSM Help.

Oui normal, ok c'est déjà plus clair.
Dans le script de création de l'IP virtuelle, commente la partie où tu attribues une adresse MAC à l'interface virtuelle.

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

Dans le script de création de l'IP virtuelle, commente la partie où tu attribues une adresse MAC à l'interface virtuelle.

@.Shad. Tu penses que le soucis pourrait venir de l'adresse MAC affectée à l'IP virtuelle ?
Demain je tenterais ça quand j'aurais le nouveau switch.
Sinon, sans préciser une adresse MAC, elle sera automatiquement fournie ? Ou il n'y en aura pas ?

Autre question : est-il possible de faire en sorte de ne pas avoir d'IPv6 avec cette IP virtuelle ?

Pour l'adresse MAC si tu n'en donnes pas, il y en aura une attribuée automatiquement.

J'y vais à tâtons, comme toi, je ne sais pas. Dans les logs dont je t'ai parlé s'il y a des problèmes de connectivité normalement on en a des traces.

Pour l'IPv6 aucune idée, est-ce gênant ?

Bonjour @shad

J’ai testé pihole en docker macvlan et vous fait un petit retour d’expérience.

 

L’installation par docker-compose se relançait dans une boucle infinie.

Le log indiquait une erreur dans le fichier pihole,conf mais l’examen de la ligne incriminée ne montrait pas d’anomalie évidente.

J’ai trouvé l’origine de l’anomalie au niveau du conditionnal forwarding qui n’accepte que des LAN en /8, /16, /24 ou /32 alors que mon Lan était en /25.

 

Vous jugerez s’il est nécessaire d’inclure cette précision dans votre tutoriel car la quasi totalité des membres du forum semble utiliser des réseaux en 192.168.X.0/24.

 

Bonne journée

Bonjour @PPJP,

Merci de ce retour, je vais évidemment le préciser car le cas est suffisamment rare pour qu'on ne retombe pas de sitôt dessus (pas évident de trouver la cause surtout).

@.Shad.

Je reposte ici ce que j'ai mis par erreur ailleurs 😛

 J'ai vu que les variables d'environnement - DNS1= et - DNS1= sont dépréciées elles aussi, voir pi-hole/docker-pi-hole: Pi-hole in a docker container (github.com)  et donc à remplacer par PIHOLE_DNS_, comme dans mon exemple ci-dessous :

      #- DNS1=80.67.169.12 # IP des serveurs DNS FdN
      #- DNS2=9.9.9.9 # IP Quad9
      - PIHOLE_DNS_=80.67.169.12;9.9.9.9

 

😇

J'avais bien noté, je n'avais juste pas encore pris la peine d'éditer. 🙂