web-dev-qa-db-fra.com

Adresse IP locale préférée après la résolution DNS?

J'ai consul en tant que serveur de noms qui résout l'adresse de deux instances d'un service. Informations DNS via Dig interface.http.service.consul:

...
interface.http.service.consul. 0    IN A    10.0.0.85
interface.http.service.consul. 0    IN A    10.0.1.22
...

ping alternera entre les deux adresses:

while true; do ping -c 1 interface.http.service.consul | grep PING; sleep 1; done
PING interface.http.service.consul (10.0.0.85) 56(84) bytes of data.
PING interface.http.service.consul (10.0.0.85) 56(84) bytes of data.
PING interface.http.service.consul (10.0.0.85) 56(84) bytes of data.
PING interface.http.service.consul (10.0.1.22) 56(84) bytes of data.
PING interface.http.service.consul (10.0.0.85) 56(84) bytes of data.
PING interface.http.service.consul (10.0.1.22) 56(84) bytes of data.
PING interface.http.service.consul (10.0.0.85) 56(84) bytes of data.

Toutefois, curl ou wget ne seront pas alternés entre ces deux adresses IP. J'ai vérifié les requêtes DNS:

Ils préfèrent toujours la cible "plus locale" lors de plusieurs appels curl:

19:43:17.979701 IP nginx.stage.35800 > dns01.node.staging.consul.domain: 49288+ A? interface.http.service.consul. (54)
19:43:17.980586 IP dns01.node.staging.consul.domain > nginx.stage.35800: 49288* 2/0/0 A 10.0.1.22, A 10.0.0.85 (86)
19:43:19.056563 IP nginx.stage.56584 > dns01.node.staging.consul.domain: 44478+ A? interface.http.service.consul. (54)
19:43:19.057605 IP dns01.node.staging.consul.domain > nginx.stage.56584: 44478* 2/0/0 A 10.0.0.85, A 10.0.1.22 (86)
19:43:34.873807 IP nginx.facemantest.36293 > dns01.node.staging.consul.domain: 43958+ A? interface.http.service.consul. (54)
19:43:34.875065 IP dns01.node.staging.consul.domain > nginx.stage.36293: 43958* 2/0/0 A 10.0.0.85, A 10.0.1.22 (86)

Ainsi, les réponses DNS ont soit 10.0.0.85 ou 10.0.1.22 comme premier enregistrement. Mais curl utilise toujours 10.0.1.22, jamais 10.0.0.85.

La machine sur laquelle je lance curl a pour adresse IP 10.0.1.10. Il semble également que cela affecte le mécanisme de transmission du proxy nginx.

Voici ma question: les clients http vérifient-ils l’adresse IP et choisissent-ils une adresse IP plus proche? Puis-je désactiver un tel comportement?

modifications

Parce que vous avez demandé, voici comment je teste curl et wget:

while true; do wget -O - -4 -q interface.http.service.consul > /dev/null; sleep 1 ; done
while true; do curl -4 -s interface.http.service.consul > /dev/null; sleep 1 ; done

La sortie de wget d'un hôte avec l'IP 10.0.1.1 est toujours

...
Resolving interface.http.service.consul (interface.http.service.consul)... 10.0.1.22, 10.0.0.85
...

La sortie de wget d'un hôte avec l'IP 10.0.0.1 est toujours

...
Resolving interface.http.service.consul (interface.http.service.consul)... 10.0.0.85, 10.0.1.22
...

Donc, wget montre en effet un tri des enregistrements A en fonction de la "distance". Qui est responsable de cela et comment puis-je le désactiver?

Je regarde également les journaux d'accès sur les deux serveurs HTTP derrière les adresses IP 10.0.0.85 et 10.0.1.22.

Le serveur DNS est Dnsmasq, qui a un impact sur le serveur DNS de consul. Ceci est mon nsswitch local:

cat /etc/nsswitch.conf 
passwd:         compat
group:          compat
shadow:         compat
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

C'est le resolv.conf local

cat /etc/resolv.conf 
# --- BEGIN PVE ---
search test
nameserver 10.0.1.2
nameserver 192.168.155.1
nameserver 8.8.8.8
# --- END PVE ---

Il n'y a pas d'entrée pertinente dans/etc/hosts. Toute la configuration du serveur DNS devrait être sans importance, car je peux voir que des requêtes DNS identiques sont effectuées, que ce soit par ping, wget ou curl. Mais pourquoi curl et wget préfèrent-ils toujours parcourir 10.0.1.22 lorsqu’ils sont exécutés à partir d’un hôte avec 10.0.1.10,

dnsip-address
2
user1283043

Puisque wget et curl devraient utiliser getaddrinfo (je ne connais pas le ping), vérifiez la page de manuel de mon archlinux (la page de manuel de BSD ne montre pas ceci):

Il existe plusieurs raisons pour lesquelles la liste chaînée peut avoir plusieurs structures addrinfo, notamment: l'hôte réseau est multi-hôte, accessible via plusieurs protocoles (par exemple, AF_INET et AF_INET6); ou le même service est disponible à partir de plusieurs types de socket (une adresse SOCK_STREAM et une autre adresse SOCK_DGRAM, par exemple). Normalement, l'application doit essayer d'utiliser les adresses dans l'ordre dans lequel elles ont été renvoyées. La fonction de tri utilisée dans getaddrinfo() est définie dans le document RFC 3484; la commande peut être modifiée pour un système particulier en modifiant / etc/gai.conf (disponible depuis (glibc 2.5).

J'ai besoin d'aller plus loin ... lisez la RFC 3484 et modifiez / etc/gai.conf

1
user1283043