Имам консул като сървър на имена, който разрешава адреса от два екземпляра на услуга. DNS информация чрез 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 ще се редува между двата адреса:

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. 

Curl или wget обаче няма да се редуват между тези два IP адреса. Проверих DNS заявките:

Те винаги предпочитат "по-локалната" цел по време на многократни повиквания:

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) 

Така че DNS отговорът има или 10.0.0.85 или 10.0.1.22 като първи A запис. Но curl винаги използва 10.0.1.22, никога 10.0.0.85.

Машината, в която пускам curl, има 10.0.1.10 като IP адрес. Изглежда също така, че това засяга механизма за преминаване на прокси nginx.

Тук моят въпрос: HTTP клиентите проверяват ли IP и избират ли IP, който изглежда по-близо? Мога ли да деактивирам подобно поведение?

редакции

Тъй като попитахте, ето как тествам curl и 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 

Изходът на wget от хост с IP 10.0.1.10 е винаги

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

Изходът на wget от хост с IP 10.0.0.10 е винаги

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

Така че wget наистина показва сортиране на записи A въз основа на "разстояние". Кой е отговорен за това и как мога да деактивирам това?

Също така гледам регистрационните файлове за достъп на двата HTTP сървъра зад IP 10.0.0.85 и 10.0.1.22

DNS сървърът е dnsmasq, който има пробив до DNS сървъра на консул. Това е моят местен nsswitch:

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 

Това е локалният Resov.conf

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 --- 

В / etc / hosts няма подходящ запис. Цялата конфигурация на DNS сървъра трябва да е без значение, защото виждам, че се изпълняват идентични DNS заявки, или чрез ping, wget или curl. Но защо curl и wget винаги предпочитат да разглеждат 10.0.1.22, когато се изпълняват от хост с 10.0.1.10,

• Показвате как тествате ping но не и как тествате curl/wget. Всички приложения трябва да се регулират от опциите в /etc/resolv.conf това може да има последици, върху които се използва IP (като sortlist опция). Но това би повлияло ping също така, така че не знам (но някои приложения правят DNS сами, без да използват операционната система). В зависимост от начина, по който те правят заявка за операционната система, приложенията могат да получат обратно само един IP (според решението на операционната система), така че няма от какво да се основава избор. Можете също да опитате да тествате с временни записи в /etc/hosts. И гледайте /etc/nsswitch.conf също. Използваш ли nscd?
• От тяхната документация: wget изглежда използва операционната система, но curl изглежда прави DNS от само себе си.

Тъй като трябва да се използва wget и curl getaddrinfo (Не знам за ping), проверих ръководството на моя архив Linux (страницата за ръководство на BSD не показва това):

Има няколко причини, поради които свързаният списък може да има повече от една addrinfo структура, включително: мрежовият хост е многокомпонентен, достъпен през множество протоколи (напр. И двата AF_INET и AF_INET6); или една и съща услуга се предлага от множество типове гнезда (един SOCK_STREAM адрес и друг SOCK_DGRAM адрес, например). Обикновено приложението трябва да опита да използва адресите в реда, в който са върнати. Функцията за сортиране, използвана в рамките на getaddrinfo() е дефиниран в RFC 3484; поръчката може да бъде променена за конкретна система чрез редактиране /etc/gai.conf (на разположение от glibc 2.5).

Трябва да отида по-дълбоко ... прочетете RFC 3484 и променете /etc/gai.conf