Come funzionano le ricerche DNS quando si utilizza (o no) un proxy HTTP in IE


20

Di recente ho partecipato a una discussione su cosa succede quando un client richiede una pagina da un server proxy. Volevo solo assicurarmi che la mia comprensione di questa sequenza di eventi fosse corretta nel caso generale:

  1. L'utente richiede il sito
  2. Una richiesta DNS viene inviata dal client al suo server DNS configurato per risolvere l'indirizzo IP di destinazione (questo viene fatto per soddisfare le richieste HTTP configurate per bypassare il proxy)
  3. Una volta ricevuto l'IP di destinazione dal DNS e subito prima dell'invio della richiesta HTTP, la richiesta viene verificata rispetto all'elenco delle eccezioni
  4. Se il server di destinazione non si trova nell'elenco delle eccezioni, la richiesta viene inoltrata al server proxy.
  5. Se il server di destinazione si trova nell'elenco delle eccezioni, la richiesta viene inoltrata in base alla tabella di routing del computer client.

Qualsiasi feedback sarebbe molto apprezzato.

Risposte:


21

Non esattamente: dipende da come è configurato il client. Usiamo IE come esempio di base.

Se si configura IE con un proxy esplicito : ad es. Nessuna altra opzione selezionata, il proxy è impostato su qualcosa: 8080.

  1. L'utente digita un indirizzo

  2. IE controlla l'indirizzo per una corrispondenza di stringa con l'elenco delle eccezioni del proxy IE (ovvero "Ignora proxy per questi indirizzi:")

    un. Se corrisponde a una voce dell'elenco Bypass , il client utilizza il proprio DNS per risolvere il nome, quindi il client si collega direttamente all'indirizzo IP di destinazione sulla porta 80 (presupposto), quindi invia una richiesta come:

    GET /something.htm HTTP/1.1
    Host: fulldomainame.example.com

    b. Se nessuna voce dell'elenco bypass corrisponde , continua:

  3. IE si collega al proxy configurato e invia una richiesta del modulo:

    GET http://fulldomainname.example.com/something.htm HTTP/1.1

    Bonus factoid: questo uso dell'FQDN nell'URL è un modo in cui puoi dire che un client pensa che stia parlando con un proxy invece che con un vero web server

  4. Il proxy risolve il nome host utilizzando il proprio DNS, quindi si connette al sito di destinazione (si comporta come il client nel passaggio 2 sopra), ecc., Ecc.

Quando si utilizza WPAD / PAC:

Nel caso di utilizzo di uno script Web Proxy Auto Discovery (WPAD) o Proxy Auto Configuration (PAC o Autoconfig), come quelli forniti da ISA / TMG quando la configurazione automatica è abilitata, è diverso:

  1. L'utente digita un indirizzo

  2. Il client scarica il file wpad.dat / autoproxy.js / .pac corrente dalla posizione configurata

  3. Il client cerca la funzione " FindProxyForUrl " nel file js e la esegue

  4. Lo script Autoproxy elabora il nome host e l' URL . Questo è un file javascript con funzioni limitate, ma molte cose sono ancora possibili:

    un. questo può includere la risoluzione dei nomi (IsInNet, DnsResolve)

    b. questo può includere la corrispondenza delle stringhe (ShExpMatch)

    c. questo può includere il conteggio fino a un milione (i ++)

    d. questo può includere messaggi popup di avviso narky se l'amministratore è un coglione

    • (o semplicemente divertente)
    • ((o debug))
  5. La funzione FindProxyForUrl restituisce almeno una stringa : un elenco ordinato dei migliori proxy da utilizzare (punto e virgola separati)

    un. o "DIRECT" , nel qual caso il cliente quindi ha la necessità di risolvere il nome stesso e collegarsi direttamente, come per il caso di esclusione di cui sopra

    b. o "PROXY proxyname: 8080" o simile, nel qual caso il client si connette a quella porta su quel proxy, gli dice di OTTENERE l'URL completo e il proxy esegue la risoluzione dei nomi .

    • Ad esempio : se la funzione di script ha restituito "PROXY yourProxy: 8080; DIRECT" che dice al client di connettersi al tuo proxy sulla porta TCP 8080 per richiedere questo URL e se tale connessione non può essere stabilita, prova ad andare direttamente. Si noti che l'errore di configurazione della sessione TCP non è esattamente rapido, quindi non è probabile che si tratti di un'esperienza piacevole di failover per un utente, ma non batte nulla. Può essere.

Occasionalmente ci sono anomalie, sottigliezze e comportamenti inspiegabili, ma per la maggior parte quando le cose non sono rotte in modi strani e interessanti, quanto sopra è come l'ho visto funzionare per molti anni. I browser più recenti ottimizzano il comportamento, parallelizzano le cose e provano sempre cose interessanti, quindi dai un'occhiata ai documenti più recenti per il tuo browser per capire i dettagli.

WinSock Proxy / ISA Firewall Client / TMG Client :

Se sei interessato al client proxy Winsock (da TMG / ISA Server), questa è una storia diversa, con maggiore flessibilità e parti mobili. Troppo da approfondire qui, ma ci sono dei documenti che descrivono come funziona. In breve: si collega a Windows Socket e può intercettare sia il traffico basato su TCP / UDP sia le richieste di risoluzione dei nomi su base per app e per utente. Molto potente, ma ora deprecato, e non è stato aggiornato da diversi anni.

I clienti possono essere davvero appiccicosi:

Un'ultima nota : una volta che un client HTTP ha deciso di parlare con un proxy per un determinato sito / url, non è possibile per il proxy dirgli di non farlo .

Non esiste un codice di stato HTTP o un'intestazione per "Non lo servo, dovresti semplicemente andare direttamente ad esso" ...

Una volta che il client decide che un determinato URL viene servito dal proxy , ne deriva il proxy-death-grip .

L'unico modo per evitarlo è ottenere la logica di selezione prima che il client effettui la connessione, nell'elenco PAC o Bypass.

Un'ultima nota su zone e file PAC

IE tratta i siti che sono connessi DIRETTO - anche se hanno punti nell'URL - per far parte della Zona Intranet locale (per impostazione predefinita - impostabile nelle proprietà della Zona), e quindi farà cose come consentire l'autenticazione integrata di Windows a quei siti (es. Autenticazione Kerberos e / o NTLM, in modo trasparente). Quindi controllare se qualcosa si trova nella Zona Intranet locale definisce quanto è affidabile in termini di autenticazione automatica. Ancora una volta, almeno, per impostazione predefinita.


Esiste uno standard o parte di un RFC che afferma che i client non devono eseguire la risoluzione DNS prima di connettersi tramite un proxy?
Wheeler

Solo convenzione e / o efficienza, per quanto ne capisco. Il vecchio client proxy Microsoft Winsock ti consentiva di giocare con le opzioni di risoluzione dei nomi. E non c'è niente che ti impedisca di scrivere un PAC che fa la risoluzione dei nomi e quindi usa un proxy ... non è come all'inizio è stato fatto.
TristanK,

0

Non sono sicuro che la tua parte DNS sia corretta. Ho visto una macchina senza server DNS validi recuperare pagine in IE bene usando un proxy.


So che un client proxy Web ISA Server utilizza il DNS del server ISA per risolvere gli indirizzi di destinazione, ma sono abbastanza sicuro che un proxy HTTP di base impostato in Opzioni Internet di una macchina XP / Win7 si risolva come indicato sopra ...
orange_aurelius

... e oops. Ho appena fatto un test che si è rivelato sbagliato, almeno in IE. Quindi, suppongo che la mia prossima domanda sarebbe: come viene risolto il DNS per gli indirizzi che si trovano nell'elenco delle eccezioni proxy? Forse è tempo di uscire dallo sniffer.
orange_aurelius,

0

Provo in ubuntu 10.04, wine, IE 6.0 e squid 2.7 (il sistema ha un dns e un calamaro ha un altro server dns)

  1. L'utente invia richieste al proxy
  2. Squid invia la richiesta DNS al server DNS
  3. Squid riceve la risposta DNS. Se nxdomain o altro errore, inviare la pagina di errore a IE. Se il nome si risolve, recuperare la pagina e consegnarla a IE.

Internet Explorer 6.0 non risolve il nome DNS.


0

Non credo che lo sia - se si digita l'IP e il dominio nell'elenco delle eccezioni o il dominio e l'IP si trova nell'elenco delle eccezioni, probabilmente passerà comunque tramite il proxy.

È possibile che un proxy.pac / wpad.dat ti consenta di uscire da questo comportamento.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.