Hvad er LINK-LOCAL ADRESSE? Hvad betyder LINK-LOCAL ADRESSE? LINK-LOCAL ADRESSE betydning

Jeg har konsul som navneserver, der løser adresse fra to tilfælde af en tjeneste. DNS-info 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 skifter mellem begge adresser:

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. 

Krølle eller wget skifter dog ikke mellem disse to IP'er. Jeg tjekkede DNS-anmodningerne:

De foretrækker altid det "mere lokale" mål under flere curl-opkald:

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) 

Så DNS-svaret har enten 10.0.0.85 eller 10.0.1.22 som første A-post. Men krøller bruger altid 10.0.1.22, aldrig 10.0.0.85.

Maskinen, hvor jeg kører curl, har 10.0.1.10 som IP-adresse. Det ser også ud til, at dette påvirker nginx-proxy-passmekanismen.

Her mit spørgsmål: Kontrollerer http-klienter IP'en, og vælger en IP, der ser tættere ud? Kan jeg deaktivere en sådan adfærd?

redigeringer

Fordi du spurgte, er det sådan, jeg tester krølle og 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 

Output af wget fra en vært med IP 10.0.1.10 er altid

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

Output af wget fra en vært med IP 10.0.0.10 er altid

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

Så wget viser faktisk en sortering af A-poster baseret på "afstand". Hvem er ansvarlig for det, og hvordan kan jeg deaktivere dette?

Jeg ser også adgangslogfiler på begge HTTP-servere bag IP'erne 10.0.0.85 og 10.0.1.22

DNS-serveren er dnsmasq, som har et gennembrud til konsulens DNS-server. Dette er min lokale 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 

Dette er den lokale resolv.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 --- 

Der er ingen relevant post i / etc / hosts. Hele DNS-serverkonfigurationen skal være irrelevant, fordi jeg kan se, at identiske DNS-anmodninger udføres, enten ved ping, wget eller curl. Men hvorfor foretrækker curl og wget altid at gennemse 10.0.1.22, når de køres fra en vært med 10.0.1.10,

  • Du viser, hvordan du tester ping men ikke hvordan du tester curl/wget. Alle applikationer skal styres af indstillinger i /etc/resolv.conf der kan have konsekvenser for, hvilken IP der bruges (som f.eks sortlist mulighed). Men det ville påvirke ping så godt, så jeg ved det ikke (men nogle applikationer gør DNS selv, men bruger ikke operativsystemet). Afhængigt af hvordan de forespørger om operativsystemet, får applikationerne muligvis kun én IP tilbage (som bestemt af OS), så intet at basere et valg fra. Du kan også prøve at teste med midlertidige poster i /etc/hosts. Og se /etc/nsswitch.conf også. Bruger du nscd?
  • Fra deres dokumentation: wget ser ud til at bruge operativsystemet, men curl ser ud til at gøre DNS af sig selv.

Da wget og curl skal bruge getaddrinfo (Jeg ved ikke om ping), kontrollerede mandsiden på min archlinux (BSD-mandsiden viste ikke dette):

Der er flere grunde til, at den linkede liste kan have mere end en addrinfo-struktur, herunder: netværksværten er multihomed, tilgængelig via flere protokoller (f.eks. Begge AF_INET og AF_INET6); eller den samme service er tilgængelig fra flere stikkontakter (en SOCK_STREAM adresse og en anden SOCK_DGRAM adresse, for eksempel). Normalt skal applikationen prøve at bruge adresserne i den rækkefølge, de returneres i. Sorteringsfunktionen, der anvendes inden for getaddrinfo() er defineret i RFC 3484; ordren kan finjusteres for et bestemt system ved redigering /etc/gai.conf (tilgængelig siden glibc 2.5).

Jeg er nødt til at gå dybere ... læs RFC 3484 og rediger /etc/gai.conf

arbejdet for dig: Charles Robertson | Ønsker du at kontakte os?

nyttige oplysninger