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 demande 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 demandes 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.

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

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

1. L'utilisateur tape une adresse

2. IE vérifie l'adresse pour une correspondance de chaîne par rapport à la liste des exceptions de proxy IE (c'est-à-dire "Contourner le proxy pour ces adresses:")

   une. S'il correspond à une entrée de la liste de contournement , le client utilise son propre DNS pour résoudre le nom, puis 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 demande du formulaire:

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

   Factoid bonus: cette utilisation du nom de domaine complet dans l'URL est un moyen de savoir qu'un client pense qu'il parle à un proxy plutôt qu'à 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. Le client télécharge le fichier wpad.dat / autoproxy.js / .pac actuel à partir de son emplacement configuré

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

4. Le script Autoproxy traite le nom d'hôte et l' URL . Il s'agit d'un fichier javascript à fonctions limitées, mais beaucoup de choses sont encore possibles:

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

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

   c. cela peut inclure le comptage jusqu'à un million (i ++)

   ré. cela peut inclure des messages contextuels 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 ensuite résoudre le nom lui-même et se connecter directement, conformément au 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 d'obtenir l'URL complète et le proxy effectue la résolution de nom .

   • Par exemple : si la fonction de script a renvoyé "PROXY yourProxy: 8080; DIRECT" qui indique au client de se connecter à votre proxy sur le port TCP 8080 pour demander cette URL, et si cette connexion ne peut pas être établie, essayez d'aller directement. Notez que l'échec de la configuration de la session TCP n'est pas exactement rapide, donc cela ne sera probablement pas une expérience de basculement agréable pour un utilisateur, mais ne vaut rien. Peut être.

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.

Client proxy WinSock / pare-feu ISA / client TMG :

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:

Une dernière remarque : 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 , le 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.

Une note finale sur les zones et les fichiers PAC

IE traite les sites qui sont connectés DIRECTEMENT - même s'ils ont des points dans l'URL - pour faire partie de la zone Intranet local (par défaut - paramétrable dans les propriétés de la zone), et fera ainsi des choses comme permettre l'authentification Windows intégrée à ces sites (c'est-à-dire Authentification Kerberos et / ou NTLM, de manière transparente). Donc, 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.

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 fine en utilisant un proxy.

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.

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.