DNS-fel i en HTTP-proxykedja: vilket led löser upp namnet?
Skilj på att nå den lokala proxyn, att lösa upp föräldern och att lösa upp webbplatsen när du diagnostiserar en kedjad forward-proxy.
client → local forward proxy → HTTP parent → websiteBörja med namnet som misslyckas i stället för att säga att all DNS tillhör «proxyn»:
| Nödvändigt namn | Led som måste nå det |
|---|---|
| Slutpunkt för lokal proxy | Klienten |
| Slutpunkt för HTTP-föräldern | Den lokala forward-proxyn |
| Slutpunkt för webbplatsen | Föräldern när den öppnar den slutliga anslutningen |
Dessa led kan använda olika resolvers när slutpunkterna är värdnamn. För HTTPS kan en forward-proxy skicka CONNECT:s målvärd och -port vidare till föräldern, som upprättar den slutliga anslutningen. Den ursprungliga klienten behöver inte först lösa upp webbplatsen. Vanlig HTTP-vidarebefordran bär också destinationsinformation vidare.
Detta är inget löfte om att exakt en maskin frågar efter varje namn. ACL-utvärdering, cachelagring, policy och implementeringsdetaljer kan orsaka extra uppslagningar.
Kontrollera reservpolicyn när föräldern inte är tillgänglig. Om direkt åtkomst tillåts kan den lokala proxyn bli det led som vetter mot webbplatsen, med egna beslut om resolver och källadress. Bara att konfigurera en förälder bevisar inte att varje begäran använde den.
Vid ett fel: identifiera namnet och den process som försöker lösa upp det innan du redigerar en hosts-fil. En ändring på klientsidan kan inte reparera varje efterföljande beslut. Den slutliga offentliga källan tillhör det led som öppnar webbplatsanslutningen; att observera den källan är inte samma sak som att mäta var DNS ägde rum.