Puncte:0

De ce IP-ul nu poate fi utilizat direct atunci când IP-ul mapat la numele gazdei ca intrare de gazdă funcționează?

drapel ru

Mi s-a dat un API pentru un serviciu prin care am încercat să trimit un mesaj post de pe serverul A, dar conexiunea nu se poate construi. Apoi dau ping la numele domeniului în API. Nu funcționează, așa că m-am gândit că numele de domeniu nu a fost mapat public pe site.

Pentru a găsi IP-ul site-ului, am făcut ping-ul în intranet de la clientul meu B, apoi am folosit IP-ul afișat în mesaj pentru a înlocui numele domeniului și am reîncercat postarea pe serverul A. Nu a funcționat. Apoi am mapat IP-ul la numele de domeniu în /etc/hosts ca intrare gazdă în serverul A și a folosit numele de domeniu ca post uri și a funcționat.

Mă întreb de ce nu a funcționat când am înlocuit numele de domeniu cu adresa IP în API? Funcționează doar prin adăugarea unei intrări gazdă?

Sunt nou în serverfault, atunci dacă această întrebare este dublată (cred că ar fi foarte posibil), vă rog să-mi spuneți. Mulțumiri.

Patrick Mevzek avatar
drapel cn
`ping` nu este aproape niciodată un instrument relevant de depanare. Dacă trebuie doar să rezolvați un nume, puteți utiliza orice client DNS, cum ar fi `dig`, `host` sau `nslookup`.
dave_thompson_085 avatar
drapel jp
DACĂ folosiți `curl`, puteți utiliza opțiunea din linia de comandă `--resolve`, în loc de o intrare `/etc/hosts` (sau alte operațiuni DNS precum dnsmasq); vezi pagina de manual. Și orice lucru construit pe libcurl poate avea o opțiune similară.
Puncte:0
drapel in

Multe servere web folosesc numele de gazdă care este trimis în cerere pentru a determina ce site ar trebui utilizat. Acest lucru permite mai multe site-uri pe același IP.

Deci da, este adesea necesar un nume de gazdă corect.

Patrick Mevzek avatar
drapel cn
Chiar și „mai rău” decât atât: dacă HTTPS, numele de gazdă trebuie cunoscut chiar înainte de traficul HTTP, adică cu extensia SNI în interiorul strângerii de mână TLS. Serverul trebuie să obțină aceste informații de la client pentru a putea expune certificatul corespunzător, fără de care HTTPS nu va fi la fel de util.
drapel in
@PatrickMevzek adevărat, browserul trimite întotdeauna numele de gazdă (dacă browserul acceptă SNI și este solicitat de server), dar numele de gazdă trimis va fi adresa IP.
Patrick Mevzek avatar
drapel cn
„dar numele de gazdă trimis va fi apoi adresa IP. â" Nu, nu va fi, `N` în `SNI` înseamnă nume... Consultați §3 din RFC6066, explică clar extensia trebuie să fie folosit pentru nume de gazdă, nimic altceva. Scrie: „Adresele IPv4 și IPv6 literale nu sunt permise în „Nume gazdă”.”
Patrick Mevzek avatar
drapel cn
Și asta dintr-un motiv simplu: serverul ar trebui să știe deja pe ce adresă IP a fost contactat de client, nu are nevoie ca clientul să trimită aceste informații într-un alt nivel. Pe de altă parte, serverul nu poate ști că rezoluția numelui a fost făcută pentru a ajunge la acea adresă IP specifică, așa că clientul trebuie să trimită **numele** care a fost la începutul procesului într-o extensie TLS la începutul strângerii de mână pentru serverul să facă alegerile potrivite pe baza acestui lucru, cum ar fi ce certificat să prezinte.
drapel in
Mulțumesc, am învățat ceva nou astăzi în ceea ce privește SNI. Antetul standard HTTP/1.1 se aplică în continuare pentru gazdă unde partea gazdă a adresei URL este trimisă, indiferent. Deci puteți avea în continuare vhost-uri pe IP (nu prea are sens, dar este posibil)
Patrick Mevzek avatar
drapel cn
Nu am spus niciodată că nu poți avea găzduire virtuală pe adrese IP, bineînțeles că poți, vezi https://1.1.1.1/ pentru un exemplu celebru cu un certificat perfect valabil. Cu toate acestea, acestea sunt cazuri de margine (la fel ca și certificatele pentru adrese IP, cel puțin în lumea HTTP, ele sunt mult mai „mainstream” în altă parte, cum ar fi RPKI) și, în general, adresele URL HTTPS cu adrese IP în loc de nume de gazdă sunt o idee proastă/un semn al o problemă undeva (cum ar fi mai târziu niciun certificat sau certificat invalid, care ar trebui să oprească clientul să se conecteze).

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.