Hva er LINK-LOCAL ADRESSE? Hva betyr LINK-LOKAL ADRESSE? LINK-LOKAL ADRESSE betydning

Jeg har konsul som navneserver som løser adresse fra to forekomster av en tjeneste. DNS-info via dig-grensesnitt. 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 vil veksle mellom begge adressene:

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øll eller wget vil imidlertid ikke veksle mellom disse to IP-ene. Jeg sjekket DNS-forespørslene:

De foretrekker alltid det "mer lokale" målet under flere curl-samtaler:

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-responsen har enten 10.0.0.85 eller 10.0.1.22 som første A-post. Men curl bruker alltid 10.0.1.22, aldri 10.0.0.85.

Maskinen der jeg kjører curl har 10.0.1.10 som IP-adresse. Det ser også ut til at dette påvirker nginx proxy pass-mekanismen.

Her spørsmålet mitt: Sjekker http-klienter IP-en, og velger en IP som ser nærmere ut? Kan jeg deaktivere en slik oppførsel?

redigeringer

Fordi du spurte, så tester jeg curl 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 

Produksjonen av wget fra en vert med IP 10.0.1.10 er alltid

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

Produksjonen av wget fra en vert med IP 10.0.0.10 er alltid

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

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

Jeg ser også tilgangsloggene på begge HTTP-serverne bak IP-ene 10.0.0.85 og 10.0.1.22

DNS-serveren er dnsmasq, som har et gjennombrudd 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 --- 

Det er ingen relevant oppføring i / etc / hosts. Hele DNS-serverkonfigurasjonen skal være irrelevant, fordi jeg kan se at identiske DNS-forespørsler utføres, enten ved ping, wget eller curl. Men hvorfor foretrekker curl og wget alltid å bla gjennom 10.0.1.22 når de kjøres fra en vert med 10.0.1.10,

  • Du viser hvordan du tester ping men ikke hvordan du tester curl/wget. Alle applikasjoner skal styres av alternativene i /etc/resolv.conf som kan ha konsekvenser for hvilken IP som brukes (som sortlist alternativ). Men det ville påvirke ping også, så jeg vet ikke (men noen applikasjoner gjør DNS selv, bruker ikke operativsystemet). Avhengig av hvordan de spør OS, kan programmene bare få tilbake en IP (som bestemt av OS), så ingenting å basere et utvalg fra. Du kan også prøve å teste med midlertidige poster i /etc/hosts. Og se på /etc/nsswitch.conf også. Bruker du nscd?
  • Fra dokumentasjonen deres: wget ser ut til å bruke operativsystemet, men curl ser ut til å gjøre DNS av seg selv.

Siden wget og curl skal bruke getaddrinfo (Jeg vet ikke om ping), sjekket mansiden på min archlinux (BSD-mansiden viste ikke dette):

Det er flere grunner til at den koblede listen kan ha mer enn en addrinfo-struktur, inkludert: nettverksverten er multihomed, tilgjengelig via flere protokoller (f.eks. Begge AF_INET og AF_INET6); eller den samme tjenesten er tilgjengelig fra flere kontakttyper (en SOCK_STREAM adresse og en annen SOCK_DGRAM adresse, for eksempel). Normalt bør applikasjonen prøve å bruke adressene i den rekkefølgen de returneres. Sorteringsfunksjonen som brukes i getaddrinfo() er definert i RFC 3484; ordren kan finjusteres for et bestemt system ved redigering /etc/gai.conf (tilgjengelig siden glibc 2.5).

Jeg må gå dypere ... lese RFC 3484 og endre /etc/gai.conf

fungert for deg: Charles Robertson | Ønsker du å kontakte oss?