web-dev-qa-db-fra.com

nslookup trouve l'ip, mais le ping ne le fait pas

Je sais que cela ressemble à toutes les autres questions "je peux cingler via ip mais pas dns", mais cela ne m'a pas vraiment aidé du tout.

De plus, il n’est pas faisable d’avoir des fichiers hôtes sur toutes les machines, car ce serveur gérera éventuellement de nombreux ordinateurs qui se connectent à ce dernier.

J'ai un ensemble de serveurs LDAP + DNS et je veux que les ordinateurs de mon réseau s'authentifient sur le serveur LDAP.

La partie LDAP fonctionne très bien et je peux SSH dans le serveur LDAP avec les informations d'identification LDAP très bien.

Le problème vient des machines clientes, le client est configuré pour utiliser le serveur DNS (dans ce cas 192.168.0.243) et si je reçois dans le terminal et que je fais un nslookup, il trouve le serveur LDAP parfaitement.

fernando@desktest:~$ nslookup ldap.mynet.local
Server:     192.168.0.243
Address:    192.168.0.243#53

Name:   ldap.mynet.local
Address: 192.168.0.243

Mais quand je le cingle, il ne trouve pas l'adresse IP. Il est juste joli jusqu'à ce que je le touche CTRL-C.

Bien sûr, le ping par adresse IP fonctionne très bien.

Voici les fichiers de zone pour le serveur DNS:

fernando@ldap:~$ cat /etc/bind/named.conf.local
zone "mynet.local" {
    type master;
    file "/etc/bind/db.mynet.local";
};

zone "0.168.192.in-addr.arpa" {
    type master;
    notify no;
    file "/etc/bind/db.192";
};
fernando@ldap:~$ cat /etc/bind/db.mynet.local 
;
; BIND data file for local loopback interface
;
$TTL    604800
@   IN  SOA ns.mynet.local. root.mynet.local. (
                  7     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
         604800 )   ; Negative Cache TTL
;
@   IN  NS  ns.mynet.local.
ns  IN  A   192.168.0.243
server  IN  A   192.168.0.250
desktest    IN  A   192.168.0.249
remote  IN  A   192.168.0.248
winserver   IN  A   192.168.0.247
web         IN  A   192.168.0.246
tempfs  IN  A   192.168.0.245
ldap    IN  A   192.168.0.243
antenarfb   IN  A   192.168.0.253
antenapan   IN  A   10.82.223.7
adslgvt IN  A   192.168.0.1
fernando@ldap:~$ cat /etc/bind/db.192 
;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@   IN  SOA mynet.local. root.mynet.local. (
                  6     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
;
@   IN  NS  ns.
1   IN  PTR ns.mynet.local.
2   IN  PTR server.mynet.local.
3   IN  PTR desktest.mynet.local.
4   IN  PTR remote.mynet.local.
5   IN  PTR winserver.mynet.local.
6   IN  PTR web.mynet.local.
7   IN  PTR tempfs.mynet.local.
8   IN  PTR ldap.mynet.local.
9   IN  PTR antenarfb.mynet.local.
10  IN  PTR antenapan.mynet.local.
11  IN  PTR adslgvt.mynet.local.
fernando@ldap:~$

Je ne sais vraiment pas quoi faire et toute aide sera grandement appréciée.

---- modifier ----

avant que quiconque demande, oui le serveur est en marche :)

root@ldap:/etc/bind# rndc status
version: 9.7.0-P1
CPUs found: 1
worker threads: 1
number of zones: 16
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

---- fin éditer ----

dnsauthenticationldapping
53
Fernando

Je crois que cela est causé par mdns - multicast dns, pour la configuration automatique du domaine .local.

Si vous enregistrez /etc/nsswitch.conf, vous verrez probablement:

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

mdns4 est ce qui fait DNS multicast. Essayez de changer ceci pour:

hosts: files dns

Et voyez si cela fait une différence. Si cela fonctionne, vous pouvez supprimer mdns de manière permanente avec:

Essayez apt-get remove libnss-mdns

Ce qui changera aussi le nsswitch.conf pour vous.

Sinon, n'utilisez pas .local - utilisez plutôt .lan ou autre.

87
Caesium

Juste pour compléter les choses:

  1. nslookup demande simplement au serveur DNS donné l'enregistrement A attribué, il ne garantit PAS que le périphérique se trouvant derrière cet enregistrement ait réellement cette adresse IP.

  2. Même lorsque le périphérique dispose de la bonne adresse IP (par exemple, l'adresse IP fixe du périphérique correspond à celle fournie par DNS), cela ne garantit pas que le périphérique est configuré pour répondre aux pings. C'est un point commun de frustration. (Je parle de vous, pare-feu Windows)

  3. Lorsque vous traversez des sous-réseaux, le routeur/passerelle/pare-feu peut également restreindre le trafic ICMP (c’est ce que c’est un ping).

Vous devez donc toujours vérifier toute la chaîne de services, de l'expéditeur au destinataire, et inversement. Dans le troisième cas, il peut y avoir des paramètres tels que a) passerelle par défaut ou b) routes (par défaut) impliquées. Alors ajoutez-les à votre liste de contrôle.

Désolé pour avoir déterré cet ancien, mais vu l'en-tête, cela semblait être un peu d'information, quelqu'un pourrait en tirer profit.

Greetz.

3
Kay Urbach

Une autre chose que j'ai vu interférer avec DNS est l'installation de winbind. Il semble mettre une entrée wins avant [NOTFOUND=return] dans /etc/nsswitch.conf, ce qui entraîne l'échec de DNS, mais peut être corrigé en déplaçant wins après la partie "NOTFOUND", de préférence après DNS afin que la recherche DNS se produise en premier, voir ceci:

http://ubuntuforums.org/showthread.php?t=1496488

(Vous ne savez pas pourquoi cela se produit par défaut; les commentaires sont les bienvenus!)

2
Latanius