web-dev-qa-db-fra.com

Fonctionnement des recherches DNS lors de l'utilisation (ou non) d'un proxy HTTP dans IE

J'ai récemment participé à une discussion sur ce qui se passe lorsqu'un client demande une page à un serveur proxy. Je voulais juste m'assurer que ma compréhension de cette séquence d'événements était correcte dans le cas général:

  1. Site de demandes des utilisateurs
  2. Une requête DNS est envoyée par le client, à son serveur DNS configuré pour résoudre l'adresse IP de destination (ceci est fait en premier afin de prendre en charge les requêtes HTTP configurées pour contourner le proxy)
  3. Une fois l'IP de destination reçue du DNS et juste avant l'envoi de la demande HTTP, la demande est vérifiée par rapport à la liste d'exceptions
  4. Si le serveur de destination ne figure pas dans la liste d'exceptions, la demande est transmise au serveur proxy.
  5. Si le serveur de destination figure sur la liste des exceptions, la demande est transmise conformément à la table de routage de la machine client.

Toute rétroaction serait très appréciée.

domain-name-systemproxyhttp
20
orange_aurelius

Pas exactement: cela dépend de la configuration du client. Prenons IE comme exemple de base.

Si vous configurez IE avec un proxy explicite : par exemple aucune autre option cochée, proxy mis à quelque chose: 8080.

  1. L'utilisateur tape une adresse

  2. IE vérifie l'adresse pour un correspondance de chaîne avec la IE (c'est-à-dire "Contourner le proxy pour ces adresses:"))

    une. S'il correspond à une entrée de la liste Contournement , le client utilise son propre DNS pour résoudre le nom, puis le le client se connecte directement à l'adresse IP cible sur le port 80 (supposé), puis envoie une demande comme:

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

    b. Si aucune entrée de liste de contournement ne correspond, continuez:

  3. IE se connecte à son proxy configuré, et envoie une requête du formulaire:

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

    Factoid bonus: cette utilisation du FQDN dans l'URL est une façon de dire qu'un client pense c'est parler à un proxy au lieu d'un vrai serveur web

  4. Le proxy résout ce nom d'hôte en utilisant son propre DNS, puis se connecte au site cible (agit comme le client à l'étape 2 ci-dessus), etc., etc.

Lors de l'utilisation de WPAD/PAC:

Dans le cas de l'utilisation d'un script Web Proxy Auto Discovery (WPAD) ou Proxy Auto Configuration (PAC ou Autoconfig), tels que ceux fournis par ISA/TMG lorsque l'autoconfiguration est activée, c'est différent:

  1. L'utilisateur tape une adresse

  2. Client téléchargements le fichier wpad.dat/autoproxy.js/.pac actuel depuis son emplacement configuré

  3. Le client recherche la fonction "FindProxyForUrl" dans le fichier js et l'exécute

  4. Le script Autoproxy traite les hostname et URL . Il s'agit d'un fichier javascript à fonctions limitées, mais beaucoup de choses sont encore possibles:

    une. cela peut inclure résolution de nom (IsInNet, DnsResolve)

    b. cela peut inclure correspondance de chaîne (ShExpMatch)

    c. cela peut inclure en comptant jusqu'à un million (i ++)

    ré. cela peut inclure messages popup d'alerte narky si l'administrateur est un imbécile

    • (ou tout simplement drôle)
    • ((ou débogage))

  5. La fonction FindProxyForUrl renvoie au moins une chaîne: une liste ordonnée des meilleurs proxys à utiliser (séparés par des points-virgules)

    une. soit "DIRECT", auquel cas le client doit alors résoudre le nom lui-même et se connecter directement, comme dans le cas de contournement ci-dessus

    b. ou "PROXY proxyname: 8080" ou similaire, auquel cas le client se connecte à ce port sur ce proxy, lui indique GET l'URL complète, et le le proxy effectue la résolution des noms.

    • Comme exemple: si la fonction de script a renvoyé "PROXY yourProxy: 8080; DIRECT" qui indique au client de se connecter à votre proxy on TCP port 8080 pour demander cette URL, et si que la connexion ne peut pas être établie, essayez d'aller directement. Remarque que TCP n'est pas exactement rapide, donc ce n'est probablement pas une expérience de basculement agréable pour un utilisateur, mais ne bat rien.

Il y a parfois des problèmes, des subtilités et des comportements inexpliqués, mais pour la plupart lorsque les choses ne sont pas brisées de manière étrange et intéressante, ce qui précède est la façon dont je l'ai vu fonctionner pendant de nombreuses années. Les nouveaux navigateurs optimisent le comportement, parallélisent les choses et essaient constamment des choses intéressantes, alors consultez les documents les plus récents de votre navigateur pour comprendre les détails.

WinSock Proxy/ISA Firewall Client/TMG Client:

Si vous êtes intéressé par le client proxy Winsock (de TMG/ISA Server), c'est une autre histoire, avec plus de flexibilité et de pièces mobiles. Trop de détails ici, mais il existe des documents qui décrivent comment cela fonctionne. En bref: il se connecte aux sockets Windows et peut intercepter à la fois le trafic basé sur TCP/UDP et les demandes de résolution de noms par application et par utilisateur. Très puissant, mais aussi obsolète maintenant, et n'a pas été mis à jour depuis plusieurs années.

Les clients peuvent être vraiment collants:

One note finale: Une fois qu'un client HTTP a décidé de parler à un proxy pour un site/URL donné, il n'y a aucun moyen pour le proxy de lui dire de ne pas le faire.

Il n'y a pas de code d'état HTTP ni d'en-tête pour "Je ne sers pas cela, vous devriez simplement y aller directement à la place" ...

Une fois que le client décide qu'une URL particulière est servie par proxy, proxy-death-grip s'ensuit.

La seule façon de l'éviter est d'obtenir la logique de sélection juste avant que le client ne se connecte, dans la liste PAC ou Bypass.

ne note finale sur les zones et les fichiers PAC

IE traite les sites qui sont [~ # ~] directs [~ # ~] connectés - même s'ils ont des points dans l'URL - pour faire partie du Zone Intranet locale (par défaut - paramétrable dans les propriétés de la zone), et ainsi fera des choses comme permettre l'authentification Windows intégrée à ces sites (c'est-à-dire l'authentification Kerberos et/ou NTLM, de manière transparente). Ainsi, contrôler si quelque chose se trouve dans la zone Intranet local définit la fiabilité de l'authentification en termes d'authentification automatique. Encore une fois, au moins, par défaut.

22
TristanK

Je ne pense pas que ce soit le cas - si vous tapez l'IP et les domaines dans la liste d'exceptions, ou le domaine, et que l'IP est dans la liste d'exceptions, cela passera probablement toujours par le proxy.

Il est possible qu'un proxy.pac/wpad.dat vous permette de vous éloigner de ce comportement.

0
Tom Newton

Je ne suis pas sûr que votre partie DNS soit correcte. J'ai vu une machine sans serveur DNS valide récupérer des pages dans IE très bien en utilisant un proxy.

0
JamesRyan

J'essaie dans Ubuntu 10.04, Wine, IE 6.0 et Squid 2.7 (le système a un DNS et Squid a un autre serveur DNS)

  1. L'utilisateur envoie des demandes au proxy
  2. Squid envoie une requête DNS au serveur DNS
  3. Squid reçoit une réponse DNS. Si nxdomain ou autre erreur, envoyez la page d'erreur à IE. Si le nom est résolu, récupérez la page et donnez-la à IE.

IE 6.0 ne résout pas le nom DNS.

0
bindbn