DNS-fejl i en HTTP-proxykæde: hvilket led slår navnet op?
Adskil det at nå den lokale proxy, slå forælderen op og slå webstedet op, når du diagnosticerer en kædet forward-proxy.
client → local forward proxy → HTTP parent → websiteBegynd med det navn, der fejler, i stedet for at sige, at al DNS tilhører “proxyen”:
| Nødvendigt navn | Led der skal nå det |
|---|---|
| Lokal proxys endepunkt | Klienten |
| HTTP-forælderens endepunkt | Den lokale forward-proxy |
| Webstedets endepunkt | Forælderen, når den åbner den endelige forbindelse |
Disse led kan bruge forskellige resolvere, når endepunkterne er værtsnavne. For HTTPS kan en forward-proxy sende CONNECTs destinationsvært og -port videre til forælderen, som opretter den endelige forbindelse. Den oprindelige klient behøver ikke først at slå webstedet op. Almindelig HTTP-videresendelse bringer også destinationsoplysninger videre.
Det er ikke et løfte om, at præcis én maskine forespørger hvert navn. ACL-vurdering, cachelagring, politik og implementeringsdetaljer kan give ekstra opslag.
Kontroller fallback-politikken, når forælderen ikke er tilgængelig. Hvis direkte adgang er tilladt, kan den lokale proxy blive det led, der vender mod webstedet, med egne beslutninger om resolver og kildeadresse. Blot at konfigurere en forælder beviser ikke, at hver anmodning brugte den.
Ved en fejl skal du identificere navnet og den proces, der forsøger at slå det op, før du redigerer en hosts-fil. En ændring på klientsiden kan ikke reparere alle efterfølgende beslutninger. Den endelige offentlige kilde tilhører det led, der åbner webstedets forbindelse; at observere den kilde er ikke det samme som at måle, hvor DNS fandt sted.