Aller au contenu

Messages recommandés

Posté(e)

@.Shad.

Petite question car je ne sais pas trop dans quelle cas je suis :
Je ne crois pas avoir de serveur DNS local. Mais je ne suis déjà pas sur de comprendre correctement la notion.
Est-ce que c'est la mise en place d'un serveur DNS avec DNS Serveur sur le NAS ou mon routeur synology ?
Je n'ai pas fait ça.
Actuellement, j'ai ça comme configuration dans le routeur :image.png.96000a075d3b49fb45d70f05327890f9.png

(je rappelle que mon but est d'adapter ton tuto à l'utilisation de Adguard Home en macvlan, actuellement c'est en mode HOST).

L'IP 192.168.2.200 est l'adresse de mon AdGuard-Home (enfin du NAS, sur lequel j'ai le conteneur).
L'objectif est donc de faire une nouvelle adresse pour le conteneur adguard en macvlan, genre 192.168.2.210, cette adresse rempalcera celle du DNS principal dans le routeur.

Dans mon Adguard, c'est configuré comme ça :

xTodcxN.png

Donc normalement, ni le routeur ni la Livebox4 ne sont interrogées pour une requête DNS. C'est bien ça ?

Du coup, je me trouve dans quel cas de figure par rapport à ton tuto ?

 

En plus, j'ai du mal à saisir quand l'interface virtuelle donc mode bridge est créée... Est-ce que c'est lors de l'exécution du script mac0-interface.sh ?
Comment spécifie-ton les ports ?

Je t'avoue que mes rudiments de notions sur docker ne couvrent pas le macvlan même si j'ai commencé à comprendre certaines choses...

Merci de ton aide 🙂

 

Posté(e)

@MrLiink49

Question qui ne résoudra pas le problème, mais que dit ce nslookup depuis le NAS en SSH :

nslookup www.google.fr 192.168.1.101

J'imagine que le ping du NAS (IP physique) depuis ton PC ne renverra rien, mais histoire de voir si on a un timeout ou une destination inaccessible :

ping 192.168.1.86
ping 192.168.1.200

Pour le fait que l'IP virtuelle n'apparaisse pas dans la liste des périphériques DHCP c'est tout à fait normal, vu que l'IP du conteneur est attribuée de manière statique, il n'y aucun bail DHCP relative à 192.168.1.200
Mais Pi-hole doit nécessairement la voir dans ses requêtes, si le fichier /etc/resolv.conf est correctement renseigné. Ca on peut le vérifier facilement depuis le NAS en SSH :

cat /etc/resolv.conf

Tu dois au minimum avoir :

nameserver 192.168.1.101

La résolution DNS est commune à toutes les interfaces par défaut.

@MilesTEG1

il y a une heure, MilesTEG1 a dit :

Donc normalement, ni le routeur ni la Livebox4 ne sont interrogées pour une requête DNS. C'est bien ça ?

Pas en primaire, mais en secondaire, tu envoies l'IP de ton routeur a priori. Donc en cas d'indisponibilité de Adguard, ça passe par le routeur. Lui a normalement sa propre résolution DNS (il n'est pas soumis au DHCP et a donc ses DNS encodés en dur).

il y a une heure, MilesTEG1 a dit :

Du coup, je me trouve dans quel cas de figure par rapport à ton tuto ?

Tu n'as pas de zone DNS locale, donc tu comptes a priori sur le loopback pour accéder à tes périphériques localement avec des noms de domaine. Ou alors tu y accèdes seulement par leur IP.
Pi-hole permet en plus de filtrer les publicités de créer une zone DNS locale. Adguard aucune idée.

il y a une heure, MilesTEG1 a dit :

En plus, j'ai du mal à saisir quand l'interface virtuelle donc mode bridge est créée... Est-ce que c'est lors de l'exécution du script mac0-interface.sh ?
Comment spécifie-ton les ports ?

Là c'est moi qui ne comprends pas où tu souhaites en venir.
L'interface est effectivement créée lors de l'exécution de ce script. Plus précisément, elle est créée, routée et activée.
Les ports n'interviennent pas à ce niveau.

L'interface physique (eth0, ovs_eth0, etc...) c'est par exemple ton nom + prénom, l'interface virtuelle serait ton pseudonyme, on parle de la même personne mais pas avec la même appellation (adresses IP différentes, même cible), les ports ce sont les portes, fenêtres, etc... pour entrer ou sortir de chez toi.

Posté(e)
il y a 33 minutes, .Shad. a dit :

Pas en primaire, mais en secondaire, tu envoies l'IP de ton routeur a priori. Donc en cas d'indisponibilité de Adguard, ça passe par le routeur. Lui a normalement sa propre résolution DNS (il n'est pas soumis au DHCP et a donc ses DNS encodés en dur).

Ok, merci pour ces précisions.

il y a 33 minutes, .Shad. a dit :

Tu n'as pas de zone DNS locale, donc tu comptes a priori sur le loopback pour accéder à tes périphériques localement avec des noms de domaine. Ou alors tu y accèdes seulement par leur IP.
Pi-hole permet en plus de filtrer les publicités de créer une zone DNS locale. Adguard aucune idée.

Oui j'utilise le loopback de la livebox ou bien je passe par les adresses IP LAN.
Du coup je suis dans le cas de figure : "Pi-hole en tant que serveur DNS local" si ce n'est que moi ce sera Adguard 🙂 

Pour la création de la zone locale, je pense que Adguard doit pouvoir faire la même chose :
OuIUIUH.png

Non ?

 

il y a 37 minutes, .Shad. a dit :

Là c'est moi qui ne comprends pas où tu souhaites en venir.
L'interface est effectivement créée lors de l'exécution de ce script. Plus précisément, elle est créée, routée et activée.
Les ports n'interviennent pas à ce niveau.

L'interface physique (eth0, ovs_eth0, etc...) c'est par exemple ton nom + prénom, l'interface virtuelle serait ton pseudonyme, on parle de la même personne mais pas avec la même appellation (adresses IP différentes, même cible), les ports ce sont les portes, fenêtres, etc... pour entrer ou sortir de chez toi.

Et bien sur l'adresse macvlan, les ports sont déjà disponible puisque c'est comme une nouvelle machine. Mais pour le réseau bridge, ne faut-il pas spécifier des ports ?
J'avais (il y a pas mal de mois), tenté un pi-hole en macvlan, mais ça ne fonctionnait pas correctement, je pense parce que je n'avais pas de script comme mac0-interface.sh.

Si tu veux j'ai conservé le docker-compose de l'époque (j'y avais spécifié tous les ports pour le mode bridge, en plus d'avoir un réseau macvlan. J'avais bricolé sans trop comprendre vraiment à partir de différentes sources).

Demain je tenterais quelque chose pour voir.

En tout cas, merci de ton aide.

Posté(e)

@.Shad.
Merci de ton retour 🙂 J'ai contourné le problème en définissant une Ip manuelle depuis mon NAS :

- J'ai configuré son dns vers 1.1.1.1 au cas où mon pihole aurait un soucis

- J'ai restreint la plage du Dhcp pihole pour ne pas inclure l'ip de mon NAS (192.168.1.86 donc la plage se termine à 85)

Si jamais ça peut servir aux prochains 🙂

Posté(e)
il y a 45 minutes, MrLiink49 a dit :

J'ai contourné le problème en définissant une Ip manuelle depuis mon NAS

C'est dommage car c'est contourné comme tu dis, pas résolu. 🙂

il y a une heure, MilesTEG1 a dit :

Et bien sur l'adresse macvlan, les ports sont déjà disponible puisque c'est comme une nouvelle machine.

Oui, c'est ça.

il y a une heure, MilesTEG1 a dit :

Et bien sur l'adresse macvlan, les ports sont déjà disponible puisque c'est comme une nouvelle machine. Mais pour le réseau bridge, ne faut-il pas spécifier des ports ?

En bridge (version Docker, pas VMM), il faut translater les ports si tu souhaites y accéder depuis l'extérieur en utilisant l'IP du NAS.
Par exemple, j'utilise le conteneur SWAG comme proxy inversé, je m'arrange pour que tout ce qui a besoin d'être "reverse proxié" soit dans le même réseau bridge que SWAG, et là je n'expose rien sur le NAS. SWAG directement au port du conteneur dont il a besoin dans son réseau.
Depuis le NAS tu n'en aurais pas besoin, tu aurais juste à taper l'IP du conteneur en bridge suivi du port.

Posté(e)

@.Shad. Merci pour tes réponses.

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

En bridge (version Docker, pas VMM), il faut translater les ports si tu souhaites y accéder depuis l'extérieur en utilisant l'IP du NAS.
Par exemple, j'utilise le conteneur SWAG comme proxy inversé, je m'arrange pour que tout ce qui a besoin d'être "reverse proxié" soit dans le même réseau bridge que SWAG, et là je n'expose rien sur le NAS. SWAG directement au port du conteneur dont il a besoin dans son réseau.
Depuis le NAS tu n'en aurais pas besoin, tu aurais juste à taper l'IP du conteneur en bridge suivi du port.

Ok pour le principe de fonctionnement.
Donc, en gros, quand je vais devoir contacter mon conteneur, je prends l'IP macvlan, et là tout ira bien.
Mais si le NAS doit contacter le conteneur pour une résolution de DNS, s'il passe par l'ip macvlan, ça ne fonctionnera pas, j'ai bien compris ? Il faudra le faire passer par l'ip du bridge, donc sa propre IP suivie du port de connexion, le port 53 ou les autres si c'est du DNSsec, c'est ça ?

Parce que l'objectif de faire un conteneur avec réseau macvlan, c'est pour avoir accès aux ports 443 et autres qui sont déjà pris par le Syno , et donc activer ce genre de chose :
yyQseeA.png


Mais du coup, autre que le port DNS 53, le nas ne pourra jamais faire du DNS-over-HTTPS, ou TLS, non ?

Posté(e)
Il y a 15 heures, MilesTEG1 a dit :

Mais si le NAS doit contacter le conteneur pour une résolution de DNS, s'il passe par l'ip macvlan, ça ne fonctionnera pas, j'ai bien compris ? Il faudra le faire passer par l'ip du bridge, donc sa propre IP suivie du port de connexion, le port 53 ou les autres si c'est du DNSsec, c'est ça ?

Pas du tout. 😄
Est-ce que tu as essayé un ping de l'un vers l'autre pour répondre à ta propre question ?

DoT et DoH n'ont aucun impact ici, c'est Adguard qui utilisera le port 443 ou 853 (par défaut) en sortie pour contacter un DNS upstream qui prend ces protocoles en charge.

Posté(e)
Le 06/02/2021 à 19:04, .Shad. a dit :

Les IP :

  • de l'interface physique du NAS : 192.168.100.100
  • de l'interface virtuelle du NAS : 192.168.100.200
  • du conteneur pi-hole : 192.168.100.161
  • de la passerelle du réseau (votre box ou votre routeur) : 192.168.100.1
  • de votre serveur DNS local (si vous n'en avez pas mis en place, c'est l'IP de votre passerelle) : 192.168.100.120

 

Le 06/02/2021 à 19:04, .Shad. a dit :

Création de l'interface virtuelle

On va créer un second script dans le dossier courant :


nano mac0-interface.sh

Le contenu du script :


ip link add mac0 link ovs_eth0 type macvlan mode bridge
ip addr add 192.168.100.200/32 dev mac0
ip link set dev mac0 address 5E:11:4F:AF:D6:D2
ip link set mac0 up
ip route add 192.168.100.160/28 dev mac0

@.Shad. Hello 🙂

Je continue petit à petit à suivre ton tuto et d'essayer de l'adapater à mon besoin d'AdguardHome (j'y consacre pas assez de temps chaque jour 😅).

Et je bute sur la compréhension d'un truc. J'ai cité ci-dessus les parties qui me posent soucis : ça concerne ce que tu appelles l'interface virtuelle du NAS avec l'ip 192.168.100.200.
C'est quoi exactement ? Je la choisie au hasard parmis des IP libres de mon réseau ? Ou bien c'est une IP déjà définie par le NAS ou docker ?

Merci d'avance 😉

 

edit : je croyais qu'une interface virtuelle serait via un réseau bridge...

Posté(e)
Il y a 1 heure, MilesTEG1 a dit :

C'est quoi exactement ? Je la choisie au hasard parmis des IP libres de mon réseau ? Ou bien c'est une IP déjà définie par le NAS ou docker ?

C'est une IP qui doit juste être libre sur le réseau et en dehors de la plage DHCP du serveur DHCP (je pourrais effectivement ajouter une remarque à ce propos).
C'est la porte par laquelle le NAS peut communiquer avec le conteneur, vu que l'IP physique ne le permet pas.

Posté(e)
il y a 14 minutes, .Shad. a dit :

C'est une IP qui doit juste être libre sur le réseau et en dehors de la plage DHCP du serveur DHCP (je pourrais effectivement ajouter une remarque à ce propos).
C'est la porte par laquelle le NAS peut communiquer avec le conteneur, vu que l'IP physique ne le permet pas.

OOOkkkk !!
Je comprends mieux 🙂 J'avais beau relire tout ce que tu avais écrit, pour moi je pensais qu'on créer un réseau bridge pour le conteneur, et une adresse bridge, c'est pour moi dans le style 172.XX.0.1.

Tu me confirmes qu'il n'y aura pas d'adresse de ce type pour le conteneur ? Et que c'est l'IP "virtuelle" qui fera office de bridge ? Mais est-ce un vrai réseau bridge ?

Posté(e) (modifié)

J'ai fait quelques petites améliorations cosmétiques des scripts 😉  avec quelques commentaires supplémentaire.

Après, ça plaira peut-être pas à tout le monde...
Mais j'aime bien que ça affiche ce qui est fait...
Du coup j'ai ajouté des echo verbose 😛 
Ça me permet surtout de bien comprendre ce que je fais, et ce que ces scripts font.
@.Shad. En tout cas, merci bien de ta patience et de ta bienveillance 🥰

Script macvlan-netwoork.sh (bon OK sur celui là, c'est pas indispensable ^^)

#!/bin/bash

# Script de création d'un réseau macvlan pour docker
# La ligne --ip-range=192.168.2.130/28 \ va permettre la création
# d'une plage de 12 IP macvlan pour docker
# Voir tuto : https://www.nas-forum.com/forum/topic/69319-tuto-docker-macvlan-pi-hole/

echo "$(date "+%D - %R:%S - LOG - ") Script de création de réseau macvlan pour DOCKER"
echo "$(date "+%D - %R:%S - LOG - ") Un réseau macvlan-network sera créé avec une plage de 12 IP macvlan disponibles"
echo "$(date "+%D - %R:%S - LOG - ") avec la commande suivante :"
echo "$(date "+%D - %R:%S - LOG - ")    docker network create -d macvlan \ "
echo "$(date "+%D - %R:%S - LOG - ")    --subnet=192.168.2.0/24 \ "
echo "$(date "+%D - %R:%S - LOG - ")    --ip-range=192.168.2.131/28 \ "
echo "$(date "+%D - %R:%S - LOG - ")    --gateway=192.168.2.1 \ "
echo "$(date "+%D - %R:%S - LOG - ")    -o parent=ovs_eth0 \ "
echo "$(date "+%D - %R:%S - LOG - ")    macvlan-network"
echo

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


echo
echo 
echo "$(date "+%D - %R:%S - LOG - ") Liste des réseaux docker : docker network ls"

docker network ls
echo
echo "$(date "+%D - %R:%S - LOG - ") Script terminé"
echo
exit

Script mac0-interface.sh : (Je récupère la sortie du script en email, comme c'est aussi le cas pour celui du media-player pour le décodage HW)
 

#!/bin/bash

# Script de création d'interface virtuelle pour le conteneur AdGuardHome_macvlan
# La ligne --ip-range=192.168.2.130/28 \ va permettre la création
# d'une plage de 12 IP macvlan pour docker
# Voir tuto : https://www.nas-forum.com/forum/topic/69319-tuto-docker-macvlan-pi-hole/


echo "$(date "+%D - %R:%S - LOG - ") Script de création d'une interface virtuelle pour le NAS"
echo "Les commandes exécutées sont :"
echo "$(date "+%D - %R:%S - LOG - ")    ip link add mac0 link ovs_eth0 type macvlan mode bridge"
echo "$(date "+%D - %R:%S - LOG - ")    ip addr add 192.168.2.200/32 dev mac0"
echo "$(date "+%D - %R:%S - LOG - ")    ip link set dev mac0 address 5E:11:01:23:45:67"
echo "$(date "+%D - %R:%S - LOG - ")    ip link set mac0 up"
echo "$(date "+%D - %R:%S - LOG - ")    ip route add 192.168.2.130/28 dev mac0"

ip link add mac0 link ovs_eth0 type macvlan mode bridge     # Création du lien entre l'interface virtuelle mac0 et la carte réseau du NAS ovs_eth0 (voir tuto)
ip addr add 192.168.2.200/32 dev mac0                       # On utilise ici l'adresse IP réelle de la carte réseau du NAS.
ip link set dev mac0 address 5E:11:01:23:45:67              # On associe une adresse MAC à l'interface virtuelle mac0 (voir tuto car le 1er bloc doit être une valeur paire !)
ip link set mac0 up
ip route add 192.168.2.130/28 dev mac0                      # On spécifie ici une adresse IP non utilisée sur le LAN et non présente dans le DHCP du routeur
                                                            # Cette adresse IP sera une IP virtuelle pour l'interface vituelle mac0.
echo
echo "$(date "+%D - %R:%S - LOG - ") Script terminé"
echo

exit

 

@.Shad. Bon j'ai un soucis sur le script mac0-interface : 
La dernière commande retourne une erreur :

FG45g4L.png

Pour les autres, pas de soucis. Même si en la relançant une à une pour savoir laquelle générait l'erreur, j'ai eu droit à ceci :
ezyH4nF.png

Est ce que tu saurais pourquoi j'ai cette erreur et comment la contourner ? (sachant que je ne peux pas rebooter le NAS pour le moment... j'ai un test badblocks en cours).

 

Modifié par MilesTEG1
Posté(e)

Hmmm, je viens de voir quelques erreurs dans le deuxième script...
J'ai pas mis les bonnes IP.
Version corrigée :
 

#!/bin/bash

# Script de création d'interface virtuelle pour le conteneur AdGuardHome_macvlan
# Voir tuto : https://www.nas-forum.com/forum/topic/69319-tuto-docker-macvlan-pi-hole/


echo "$(date "+%D - %R:%S - LOG - ") Script de création d'une interface virtuelle pour le NAS"
echo "$(date "+%D - %R:%S - LOG - ") Exécution des commandes :"

echo "$(date "+%D - %R:%S - LOG - ")    ip link add mac0 link ovs_eth0 type macvlan mode bridge"

ip link add mac0 link ovs_eth0 type macvlan mode bridge     # Création du lien entre l'interface virtuelle mac0 et la carte réseau du NAS ovs_eth0 (voir tuto)


echo "$(date "+%D - %R:%S - LOG - ")    ip addr add 192.168.2.130/32 dev mac0"

ip addr add 192.168.2.130/32 dev mac0                       # On spécifie ici une adresse IP non utilisée sur le LAN et non présente dans le DHCP du routeur
                                                            # Cette adresse IP sera l'IP virtuelle pour l'interface vituelle mac0.

echo "$(date "+%D - %R:%S - LOG - ")    ip link set dev mac0 address 5E:11:87:C5:A1:D5"

ip link set dev mac0 address 5E:11:87:C5:A1:D5              # On associe une adresse MAC à l'interface virtuelle mac0 (voir tuto car le 1er bloc doit être une valeur paire !)


echo "$(date "+%D - %R:%S - LOG - ")    ip link set mac0 up"

ip link set mac0 up


echo "$(date "+%D - %R:%S - LOG - ")    ip route add 192.168.2.131/28 dev mac0"

ip route add 192.168.2.131/28 dev mac0                      # On spécifie ici la plage d'adresse du réseau macvlan créé précédemment (script macvlan-network.sh)

echo
echo "$(date "+%D - %R:%S - LOG - ") Script terminé"
echo

exit

Bon ben la dernière commande retourne toujours la même erreur...

Posté(e) (modifié)
Il y a 2 heures, MilesTEG1 a dit :

Tu me confirmes qu'il n'y aura pas d'adresse de ce type pour le conteneur ? Et que c'est l'IP "virtuelle" qui fera office de bridge ? Mais est-ce un vrai réseau bridge ?

Ca n'a rien à voir avec un réseau bridge au sens Docker. C'est un réseau macvlan.
C'est l'interface mac0 qui est en bridge sur l'interface physique eth0 (ovs_eth0).

Ton conteneur a la propriété d'être considéré comme une machine physique à part entière, comme le permet un hyperviseur en plaçant une machine virtuelle dans un réseau bridge (ne pas confondre avec le réseau bridge de Docker). Et donc si tu lui donnes une IP sur réseau local, il sera en broadcast sur ton réseau (ce qui facilite la détection des et par les autres périphériques, typiquement mon contrôleur unifi est en macvlan, ça m'évite de translater une papardelle de ports ou de le mettre en mode host et squatter de nombreux ports de son hôte).

Pour ton problème tu n'aurais pas déjà une interface mac0 ? C'est bien ovs_eth0 le nom de ton interface physique ?

Au passage :

echo
echo "coucou"
echo

peut s'écrire beaucoup plus simplement :

echo -e "\ncoucou\n"
Modifié par .Shad.
Posté(e)
il y a une heure, .Shad. a dit :

Ca n'a rien à voir avec un réseau bridge au sens Docker. C'est un réseau macvlan.
C'est l'interface mac0 qui est en bridge sur l'interface physique eth0 (ovs_eth0).

Tu confirmes ce que je pensais ^^
Pour le reste des précisions/explications, je savais certaines choses, mais tu m'as expliqué d'autres que je n'avais pas bien saisi.

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

Pour ton problème tu n'aurais pas déjà une interface mac0 ? C'est bien ovs_eth0 le nom de ton interface physique ?

Je redémarre le NAS, et je regarde pour mac0... Et pour ovs_eth0 oui c'est normalement bien mon interface physique, je regarde à nouveau après le reboot, mon dernier badblocks s'est terminé.

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

peut s'écrire beaucoup plus simplement :


echo -e "\ncoucou\n"

Ha bah oui, pourquoi je ne l'ai pas fait... Ok, merci, ça raccourci un peu mes scripts ^^

Posté(e)

@.Shad. Me revoilà, après reboot du NAS, et installation de la dernière version de DSM (il a fallu que je subisse la MAJ de plein de paquets, donc Docker !).

Pour mon interface physique, c'est bien ovs_eth0 :
1WkWFwv.png

Sans avoir lancé le script mac0-interface.sh, pour le mac0, lorsque je lance la commande suivante, j'ai rien :
wGwRy8A.png

 

Avant de lancer les commandes du c-fichier macv0-interface.sh (j'ai renommé le mac0 en macv0 au cas où...), j'ai voulu vérifier un truc. La plage d'adresse réellement prise pour le réseau macvlan :

avec 192.168.2.130/28 j'ai ceci d'après Calculateur de Masque IPv4 (cnrs.fr) :
syvYdFy.png 

Ou avec Calculatrice de sous-réseau | Calculatrice de masque de sous-réseau IP pour IPv4 – Site24x7 :
1IYOKXk.png

Ce qui voudrait dire qu'il y a un peu plus que 14 IP dans le lot 192.168.2.130/28 ?!

Or ce matin, lorsque je testais avec 192.168.2.131/28 en voulant mettre l'IP virtuelle en 192.168.2.130, (j'ai les même résultat que les captures) ce n'était pas possible puisqu'elle était déjà dans le réseau macvlan.
Du coup, je passe le réseau macvlan en 192.168.2.130/28, et je choisi une IP virtuelle en 192.168.2.210 (là je serais tranquille).
Je vais voir ce que donne les commandes une à une.
Je posterais les résultats après.

Posté(e)

Bon j'ai pu réussir en créant non pas une plage d'IP-macvlan, mais en créant une seule IP macvlan 192.168.2.130/32 (je n'ai pas tester avec un intermédiaire /31 /30 /29 ) :
3UIRumK.png

Du coup je vais rebooter le NAS pour virer ces personnalisations d'ip virtuelle et choisir une IP macvlan et une IP virtuelle autrement 😉

Posté(e)

@MilesTEG1, heu ... je n'ai pas tout suivi, mais pourquoi l'adresse du dev macv0 ne se trouve t'elle pas dans le même sous réseau 192.168.2.130/28 ?

Ai-je raté une explication ?

 

Posté(e)
il y a 1 minute, bruno78 a dit :

@MilesTEG1, heu ... je n'ai pas tout suivi, mais pourquoi l'adresse du dev macv0 ne se trouve t'elle pas dans le même sous réseau 192.168.2.130/28 ?

Ai-je raté une explication ?

J'ai pas tout compris... Tu parles de quelle commande ? 
Car en suivant le tuto (sans me gourré comme j'avais commencé à faire), la dernière commande ne fonctionne pas, sauf si je spécifie une IP unique avec 192.168.2.130/32.
Si je mets 192.168.2.130/28 comme ça a été utilisé pour créer le réseau macvlan, la dernière commande retourne une erreur.

Posté(e)

@MilesTEG1

ce qui me choque (mais après je n'ai pas forcement compris ta configuration), c'est d'avoir d'un côté

ip addr add 192.168.2.210/32 dev macv0

et de l'autre

ip route add 192.168.2.130/28 dev macv0

Sachant que le 192.168.2.210/32 n'appartient pas à la plage définie par 192.168.2.130/28

Posté(e)

  @bruno78 En fait si on reprend le tuto de @.Shad. :

Le 06/02/2021 à 19:04, .Shad. a dit :

Création de l'interface virtuelle

On va créer un second script dans le dossier courant :


nano mac0-interface.sh

Le contenu du script :


ip link add mac0 link ovs_eth0 type macvlan mode bridge
ip addr add 192.168.100.200/32 dev mac0
ip link set dev mac0 address 5E:11:4F:AF:D6:D2
ip link set mac0 up
ip route add 192.168.100.160/28 dev mac0

 

Son adresse virtuelle (pas macvlan) pour son conteneur est 192.168.100.200/32, et moi ce sera 192.168.2.210/32.
Sa plage d'adresses macvlan est 192.168.100.160/28 , et moi ce sera 192.168.2.130/28.
Je n'ai pas mal compris ce qu'il a fait je pense. Mais ça ne fonctionne quand même pas sur la dernière commande.
Sauf si au lieu de la plage d'IP macvlan, je mets une seule IP macvlan.

Après, je ne connais pas ces commandes, je ne les maitrise pas du tout...

Mais du coup, ça m'arrange de prendre comme IP virtuelle 192.168.2.221, et une IP macvlan 192.168.2.220. C'est comme ça que je fais faire mes réseau pour ce conteneur. Je n'ai pas vraiment besoin de plein d'IP macvlan en fait.

Posté(e)

@bruno78 Pour ma part je n'ai jamais mis l'IP de l'interface virtuelle dans la plage du sous-réseau macvlan. Et ça ne pose aucun problème de communication. J'arrive très bien à ping mon IP virtuelle depuis un de mes conteneurs en macvlan. Si tu vois un biais dans cette manière de faire, n'hésite pas à m'expliquer.

@MilesTEG1 Essaie de faire sauter l'étape avec l'adresse MAC pour voir :

ip link set dev ...

 

Posté(e)

@.Shad. Ok, je tente une dernière fois avec une plage d'IP macvlan. Mais les IP vont changer, car j'ai déjà changé dans mes fichiers 😅

Bon ben pareil :
TEqhIf6.png
Je précise que 192.168.2.230/32 c'est l'IP virtuelle, et que 192.168.2.210/28 c'est la plage d'IP du réseau macvlan que j'ai créé avec la commande adéquat (pas d'erreur là-dessus).

Avant que je reboot, si vous êtes plus rapide, y a moyen de défaire ce que viennent de faire ces commandes (les 3 dernières) sans que j'ai besoin de rebooter ?

 

Posté(e)
il y a 37 minutes, .Shad. a dit :

Pour ma part je n'ai jamais mis l'IP de l'interface virtuelle dans la plage du sous-réseau macvlan. Et ça ne pose aucun problème de communication. J'arrive très bien à ping mon IP virtuelle depuis un de mes conteneurs en macvlan. Si tu vois un biais dans cette manière de faire, n'hésite pas à m'expliquer.

@.Shad. Non non pas de problème, moi je mets cette adresse dans la plage et je n'ai aucun soucis, mais je n'ai pas essayé de la mettre en dehors pour vérifier ... .  C'était juste une piste. Mais si ce n'est pas cela, .... je continue à regarder .....

Mon script de demarrage (testé et validé !)

#!/bin/sh
# 
#Set timeout to wait host network is up and running
sleep 60
#sleep 90

#Host macvlan bridge recreate

ip link add bridgemacvlan link ovs_eth0 type macvlan  mode bridge
ip addr add 192.168.1.251/32 dev bridgemacvlan

ip link set dev bridgemacvlan address 0:1:2:3:4:5
ip link set bridgemacvlan up

ip route add 192.168.1.248/29 dev bridgemacvlan

 

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.