Forum Linux.général Windows smarter than Unix ?

Posté par  (site web personnel) .
Étiquettes :
-4
14
mar.
2012

Bonjour,

j'ai des machines définies plusieurs fois dans mon DNS en fonction de leur VLAN.

Quand je fais un nslookup:

[gnumdk@arch ~]$ nslookup butters.in.*.fr
Server: 194.254..10
Address: 194.254.
.10#53

Name: butters.in.*.fr
Address: 192.168.128.2
Name: butters.in.*.fr
Address: 192.168.64.2

J'ai donc les deux réponses… Sous windows, c'est parfait, le choix de l'ip se fait en fonction des réseaux directement accessible par le client.

Sous Linux, c'est l'un ou l'autre aléatoirement…

On peut corriger cela facilement ?

  • # Ce n'est pas au client de choisir

    Posté par  . Évalué à 7.

    Ce n'est pas au client de faire le choix, d'ailleurs si ça marche sous Windows ce n'est peut être qu'un coup de bol.

    C'est le serveur DNS qui doit être configuré pour retourner la réponse en fonction du réseau d'où provient le client. Si tu utilises bind regarde du côté de la directive "view".

    • [^] # Re: Ce n'est pas au client de choisir

      Posté par  (site web personnel) . Évalué à -1. Dernière modification le 14 mars 2012 à 14:39.

      Je connais les vues mais cela ne fonctionne pas si les clients sont natés ce qui est mon cas…

      Le serveur DNS est en DMZ, il est hors de question de lui rajouter des pattes réseau.

      Et non, ca ne fonctionne pas sous windows par coup de bol, il choisit un résultat accessible…

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 1.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Ce n'est pas au client de choisir

          Posté par  (site web personnel) . Évalué à -2.

          Ca casse rien du tout, j'ai pas demandé à avoir un comportement débile…

          Windows ne casse par le round-robin, mais il privilégie les réseaux privés sur lequels il a un accés direct!

          Parce que sous Linux du coup, ben ca chie une fois du deux…

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 4.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Ce n'est pas au client de choisir

              Posté par  (site web personnel) . Évalué à -2. Dernière modification le 15 mars 2012 à 11:32.

              Si un client décide de prendre toujours le plus proche numériquement (ce qui ne signifie
              nullement que c'est le meilleur choix cfr. subnets, vlan trunk, tunnels et autres), il
              produit une situation de déséquilibre.

              Euh, tu m'expliques ? Quand t'as une patte sur un réseau, les paquets passent toujours par là et pas par ta passerelle par défaut… Pourquoi, parce que c'est le meilleur choix…

              Quand on te dit machine est sur réseau A et réseau B, que tu as un accès direct à réseau B alors que pour aller sur réseau A, faut passer par ta passerelle (avec la possibilité qu'elle ne sache pas aller sur réseau A), ca me semble logique de taper directement sur réseau B…

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 4.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Ce n'est pas au client de choisir

                  Posté par  (site web personnel) . Évalué à 1.

                  Ce n'est pas parce que 192.168.123.1 et 192.168.123.2 sont sur le même réseau qu'il n'y a pas
                  un tunnel entre les 2 avec des délais monstrueux. Par exemple, tu peux avoir un bon gros VPN
                  sur une connexion bien pourrie, tu peux avoir des vlans partagés entre des sites distants de
                  milliers de km

                  Oui et donc, avec Linux qui prend aléatoirement, je vois pas pourquoi il fait mieux…

  • # sortlist ?

    Posté par  . Évalué à 5.

    Je n’ai pas testé, mais je pense que la directive sortlist, dans le fichier de configuration du résolveur (resolv.conf(5)) devrait faire l’affaire.

    Je crois même comprendre, d’après ce chapitre (section 6.1.5), qu’elle est plus ou moins faite pour ça.

    • [^] # Re: sortlist ?

      Posté par  (site web personnel) . Évalué à 2.

      Merci ;)

      • [^] # Re: sortlist ?

        Posté par  . Évalué à 2.

        Effectivement, la solution fonctionne, mais ça oblige à renseigner l'entrée manuellement dans le fichier resolv.conf.
        Est-ce que quelqu'un voit une solution pour que le resolv.conf soit mis à jour automatiquement ? (paramétrage du client DHCP, de resolvconf, voire utilisation d'un cache DNS local)

        • [^] # Re: sortlist ?

          Posté par  (site web personnel) . Évalué à 3.

        • [^] # Re: sortlist ?

          Posté par  . Évalué à 2.

          Est-ce que quelqu'un voit une solution pour que le resolv.conf soit mis à jour automatiquement ? (paramétrage du client DHCP

          Ça peut effectivement se faire par un script exécuté automatiquement par le client DHCP — du moins avec dhcpcd, qui est fourni d’ailleurs avec une série de scripts s’occupant, entre autres, de mettre à jour resolv.conf. Il suffirait d’ajouter un script personnalisé rajoutant la directive sortlist appropriée.

        • [^] # Re: sortlist ?

          Posté par  . Évalué à 2.

          As-tu essayé de regarder du côté de /etc/gai.conf ?

        • [^] # Re: sortlist ?

          Posté par  . Évalué à 5.

          Est-ce que quelqu'un voit une solution pour que le resolv.conf soit mis à jour automatiquement ? (paramétrage du client DHCP, de resolvconf,

          ce ne serait pas plutot au serveur DHCP de proposer la bonne option à mettre dans le resolv.conf ?

          deja ce serveur DHCP devrait donner le bon DNS en fonction du LAN qu'il adresse.

          ensuite le serveur DNS aurait 2IPs (si si, c'est possible, meme avec une seule carte reseau) et il pourrait alors servir des "views" en fonction.

          et du coup tu ferais d'une pierre 2 coups, tu as une config bien propre, ET un DNS qui donne la bonne reponse suivant le LAN d'ou l'on vient.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.