Cet article a été publié il y a 15 ans 4 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.Après m’être fait suer quelques heures sur un problème débile de conf de proxy Firefox, j’ai décidé d’en faire part dans ce billet. Ca fera peut-être gagner du temps à certains. Vu que la litterature sur le sujet est assez éparpillée (voir à la fin de l’article). La seule vraie information semble être un bugzilla de Mozilla, daté de 2001 et toujours en cours de discussion ! (au moins jusqu’à mi 2008)
L’histoire est la suivante
Vous utilisez un proxy, mais vous ne voulez pas l’utiliser pour les adresses locales (genre : vos intranets). C’est un choix raisonnable.
Bien sûr, vous voulez utiliser les noms de hosts et pas les FQDN, exemple : http://serveur/ et pas http://serveur.masociete.net/
Raisonnable là aussi
Le constat d’échec
– Sous IE, lorsque vous cochez « ne pas utiliser de proxy pour les adresses locales », ça fait ce qu’on veut (waaa, m’enfin, il y a d’autres travers avec IE)
– Sous firefox, c’est moins simple :
- Si vous indiquez « .masociete.net » dans les adresses à exclure (notez le « . »), alors les adresses du genre http://serveur.masociete.net/ sont bien traitées en direct (bypass du proxy) et les adresses courtes « peuvent » marcher :
- Ca marche si : par exemple avec Squid, vous avez ajouté le paramètre « append_domain » contenant votre « societe.net ». MAIS : vous passez par le proxy même pour ces sites locaux. C’est débile ! (mais ça marche, on est d’accord)
- Ca ne marche pas sinon, Firefox commence à chercher sur google ce que pourrait être votre nom de host… Et pas la peine de vous exciter sur la conf DNS de votre PC windows pour lui faire ajouter des suffixes DNS partout, ça ne change rien
- Si vous ne mettez aucune exclusion, ça revient au même. Les syntaxes genre » *.masociete.net » ne sont pas reconnues (silencieusement)
- Enfin, si vous vous limitez à exclure des plages d’IP, genre 192.168.x.y/m ça ne suffit pas. Firefox se gourre (de mon point de vue) car il raisonne sur le nom et pas sur l’IP. Donc le filtre marchera bien si vous tapez « http://une.adr.esse.ip/ » mais fera comme expliqué ci-dessus avec les noms de machines
La seule solution (il me semble) industrialisable
En passant par un fichier « PAC » (voir mon article sur le sujet), alors ça marche.
Le secret ? ce mécanisme force à résoudre l’IP associée au nom avant de commencer à réfléchir, via la fonction isInNet par exemple (isPlainHostName doit pouvoir marcher aussi) ; de là, si on voit qu’on est sur telle plage d’IP, on fait sans le proxy, en DIRECT.
Exemple ultra-simple de conf :
function FindProxyForURL(url, host)
{
if (isInNet(host, "192.168.0.0", "255.255.0.0")) {
return "DIRECT";
}
else
return "PROXY mon_proxy:3128";
}
Reste à déployer ce script et modifier les conf des navigateurs. A vos GPO, scripts Samba, registrie etc.
Quelques références
https://bugzilla.mozilla.org/show_bug.cgi?id=72444
https://bugzilla.mozilla.org/show_bug.cgi?id=91587
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q303650
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q262981
Bonne lecture, surtout pour le premier…
Si vous avez une meilleure solution je suis preneur…
Notez que je n’ai pas testé depuis un firefox sous Linux ; mon propos étant dans une entreprise avec des postes Windows.
Voir aussi l’autodetection :
Cela évite la configuration de chaque client. et en cas de mobilité éviter de switcher entre les diverses configuration de proxy. Bien sur il faudrait que toutes les entreprises, lieux etc. fasse un effort de configuration local.
Le problème du fichier .pac, c’est qu’il est sans cesse réévalué pour chaque truc à charger et en pratique, ça ralentit un peu la navigation. Peut-être que sur un navigateur à JavaScript ultra-rapide, c’est mieux…
@Ze :
Pour le WPAD, c’est bien beau, mais une fois que le DHCP m’aura renseigné, il m’indiquera l’adresse du proxy. Ca ne changera rien au problème des adresses locales si ?
Pour ce qui est de la conf, en passant par un .PAC ou par WPAD, il faudra bien répandre la bonne conf (cocher la case ou taper une ligne). Dans tous les cas on scriptera.
C’est juste enbêtant pour les portables, en effet (rare dans mon cas actuellement 🙂
@AP :
Pour la lenteur, entre ça et forcer le passage inutile par un proxy pour l’intranet, y’a pas photo. Pour le reste, résoudre un nom/IP ne coûte rien face à n’importe quel processus qui contribue à afficher la page non ? (décompression jpeg, lancement du lecteur flash-machin etc). In if-then-else, même pour chaque ressource de page, franchement, c’est léger je trouve 🙂
Regarde du côté de l’extension FoxyProxy. L’apprentissage est un peu déroutant, mais une fois le principe acquis, c’est assez redoutable.
je vois le genre
maintenant, pour l’utilsiateur lambda et pour généraliser dans une société…. ça risque d’être moins simple
Néanmoins merci pour l’info, j’aurais sûrement eu besoin de ça à l’époque où j’étais consultant navigant de boite en boite…
Oula, WPAD pointera vers un fichier pac, ca permet juste d’éviter d’avoir à configurer manuellement l’adresse. Ce qui en contexte nomade est vraiment un gain de temps.
Pour la découverte elle se fait soit via le DHCP soit via le DNS (plus simple à mon gout). si le poste client est pc.department.branch.example.com, le navigateur va tester successivement :
– http://wpad.department.branch.example.com/wpad.dat
– http://wpad.branch.example.com/wpad.dat
– http://wpad.example.com/wpad.dat
– http://wpad.com/wpad.dat
Le fichier wpad contiendra la même chose que ton proxy.pac et tiendra donc compte des exceptions. Ca ne remplace pas le proxy.pac mais automatise sa découverte. Ca sera pas un mal le jour ou les applications auront moins besoin d’avoir des configuration manuelle ou des URL de configuration automatique du proxy.
http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol
Dans ce cas OK
Je ne savais pas que ça pouvait pointer vers un .pac
Je suppose que lorsqu’il ne trouve rien (ou à défaut la 4è entrée), alors il laissera tomber – pratique donc en contexte nomade. Pour le coup, on ne risque pas de perdre du temps à ne PAS trouver le wpad (et donc ralentir la perf) lorsqu’on sera en nomade hors de la société ?
(En effet, par le DNS, ce sera plus rapide/immédiat)
merci pour la précision
ah, de ce que j’en teste, le wpad.dat est chargé au démarrage de firefox, ensuite plus rien ; c’est nickel !
A voir pour IE
« Vous utilisez un proxy, mais vous ne voulez pas l’utiliser pour les adresses locales (genre : vos intranets). C’est un choix raisonnable. »
Pourquoi est-ce un choix raisonnable de ne pas vouloir passer par un proxy pour des adresses locales ? La simple volonté n’est pas suffisante si elle n’est pas appuyée par des raisons pragmatiques 😉
Blague à part, j’imagine bien que ce choix est certainement raisonnable dans le cas qui est évoqué, mais sans être décrit malheureusement.
rooo le pointilleux
Dans mon cas, je me fous de savoir ce qui passe sur les intranets, mon proxy étant là pour optimiser l’accès web et faire des stats d’utilisation
OK comme ça ? 😀
Même pas pointilleux, juste un peu vacciné car passé par là il y a quelque temps dans un environnement assez complexe. Pour faire court, la solution mise en place avait été d’utiliser WPAD aussi.
Je développe un peu la partie qui m’a fait réagir :
L’important est de ne pas perdre de vue les besoins. Dans le cas qui est présenté, éviter le proxy pour accéder aux sites de l’intranet parcequ’une information est inutile dans les logs me semble, un peu léger. Je soupçonne un a priori supplémentaire, qui n’est pas exprimé, concernant l’inutilité d’un proxy pour des intranets. En effet, il faut toujours mesurer précisément l’impact d’un proxy pour confirmer ou bien infirmer son utilité avec des intranets (on peut avoir des bonnes surprises, en particulier sur les ratios de {cache,byte,mem}/hit).
Pour le besoin d’accepter des noms de sites qui ne sont pas FQDN, là aussi il faut voir où est le gain réel. Pour l’utilisateur final ? Pas sûr qu’il tape les adresses, il utilise probablement la page d’accueil préconfigurée d’où il peut atteindre les autres intranets d’un simple clic. Il tape les addresses ? Du coup c’est plutôt un utilisateur un peu « avancé » qui ajoutera le domaine s’il rencontre une « 404 » (l’erreur, pas la voiture :-D).
Donc, s’il n’est pas si contre-productif que ça de passer par un proxy « tout le temps », beaucoup de problèmes n’en sont plus vraiment.Le proxy peut aussi être configuré pour ajouter le nom de domaine lors de la résolution quand il est utilisé.
D’où aussi ma question précédement, droit au but, concernant le « pourquoi » 😉
‘chuis d’accord
Ben là j’ai pas envie de proxyfier les intranets
Mais après pourquoi pas
Et en fait, la solution WPAD règle tous les soucis, même si la saisie des fqdn ne concerne pas grand monde 🙂