Salut à tous   ,
(je sais pas du tout si je l'ai mis dans la bonne sous catégorie   )
Pour un projet j'ai décidé de me lancer dans une sorcellerie, la redondance des mes rôles Windows Serveur dans des conteneurs Docker. Je bosse dessus depuis un peu plus d'un mois.  
Actuellement j'ai réussi à créer une images viable et stable, pour faire tourner la redondance de mon Active Directory, et ça fonctionne nickel.
 
Cependant j'aurai besoin d'aide pour plusieurs choses. Actuellement je déploie avec vagrant-libvirt, avec un réseau en 192.168.121.X dédié aux "VM" du conteneurs, ainsi je dois faire des iptables pour faire ressortir les flux. En vient donc deux problèmes, le DNS natif reconnait l'ip en 192.168.121.X et non l'IP de mon LAN, j'ai essayé de me renseigner depuis une bonne semaine sur la doc mais je trouve rien qui permettrait de me faire directement utiliser mon LAN.  
 
Second problème, qui je pense est lié. Impossible de faire fonctionner le rôle DHCP, quand je fais un Wireshark je vois bien passer les requêtes DISCOVER des clients, mais aucune OFFER de mon DHCP dans mon conteneurs.
 
Pour le réseau de mon conteneur, j'utilise un réseau IPvlan "tronqué" :
 
docker network create \
-d ipvlan \
--subnet=172.16.100.0/24 \
--ip-range=172.16.100.240/29 \
--gateway=172.16.100.254 \
-o parent=ens160 \
-o "com.docker.network.bridge.enable_ip_masquerade"="true" \
ipvlan
 
Et pour les iptables que j'utilise dans mon conteneur :  
 
iptables -A FORWARD -i eth0 -o virbr1 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -i virbr1 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -j DNAT --to-destination 192.168.121.235
iptables -t nat -A POSTROUTING -o virbr1 -d 192.168.121.235 -j SNAT --to-source 192.168.121.1
iptables -D FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
iptables -D FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
iptables -D FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
iptables -D FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
 
Si des gens auraient des petites idées pour me dépatouiller de ce bourbier je suis preneur, j'aimerai bien faire fonctionner ce DHCP au moins  

Hello, avant tout je connais mal Docker.
 
Quand tu dis "pour faire tourner la redondance de mon Active Directory", ça veut dire quoi ? Car Microsoft ne recommande absolument pas les configs AD impliquant du NAT : https://learn.microsoft.com/en-us/t [...] y-over-nat (il n'y a qu'un seul scénario testé et ta config ici ne semble pas être celle là)
 
Pour utiliser directement le plan d'adressage du LAN public il semble que l'option macvlan serait une meilleure solution : https://docs.docker.com/network/macvlan/
 
Je ne parle pas du tout le iptables mais dans une configuration NAT je ne sais pas si tu peux de manière fiable forwarder les requêtes des clients vers un DHCP derrière un NAT sans agent de relai. Le broadcast, par définition, n'a pas de destination (donc d'un point de vue NAT rien à traduire), ça envoie tout azimuts sur le réseau local et attend qu'une bonne âme éventuellement présente intercepte le paquet (dans ton cas l'agent de relai ou le serveur DHCP).
 
Peut être que iptables sait forwarder le trafic de broadcast (genre ce qui est destiné à 255.255.255.255) vers une destination particulière. Il faudrait que tu canalises ce genre de trafic venant de UDP/67 vers le port UDP/68 de ton serveur DHCP.

Hello merci de ta réponse !
En gros j'ai un Active Directory "principal", et un serveur de secours ( celui dans le conteneur ) qui prend la relève si il tombe, ce qui fonctionne tip top par ailleurs  
 
Je vais try tout ça, puisse le sort me soit favorable

 
Principal, secours, c'est pas des termes applicables à des DC. Les deux répliquent ? C'est une machine de stand by que tu restores avec les backups de l'autre DC ?
 
En mode actif/actif je vois pas comment ça peut fonctionner tip top à travers un NAT. Le DC derrière le NAT va publier son IP réelle dans le DNS et le DC sur le réseau public ne saura jamais le contacter (puisqu'il aurait besoin de connaitre l'IP publique pour ça). L'inverse en revanche (le DC derrière le NAT contacte le DC sur le résau public) est possible. Donc ça fait une config bancale ou ta réplication fonctionne dans un sens, mais pas l'autre. L'AD n'aime pas du tout ça.
 
En plus tes clients ne sauront pas non plus joindre le DC derrière le NAT si c'est le seul survivant, puisqu'encore une fois, il faudrait qu'ils connaissent l'IP publique. A la limite tu peux leur donner l'IP publique en tant que serveur DNS, mais c'est après que ça va se compliquer.

Yes j'avoue j'ai raccourci le délire haha.  
 
Actuellement les deux sont en modes actif/actif, et je publie dans mon DHCP les deux IP, le 172.16.100.1 et le 172.16.100.240, puis en tertiaire mon pfSense sur mes clients.
 
J'ai remplacé le DNS par l'IP en 172.16.100.240 et tout est fonctionnel. Maintent, je cherchais et cherche toujours comment utiliser sur une VM QEMU une interface hôte, ce qui me semble pas gagner d'après mes recherches

Bon toujours pas fonctionnel, je commence à désespérer, je vois pas ce qui bloquerait dans le fonctionnement des mes iptables (si c'est ça)

C'est juste pas supporté ça le sera jamais et ça ne sert à rien

Merci de l'info