firefox, les proxy et les adresses locales

closeCet article a été publié il y a 9 ans 5 mois 2 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.

12 réflexions au sujet de « firefox, les proxy et les adresses locales »

  1. Ze

    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.

    Répondre
  2. AP

    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…

    Répondre
  3. michauko Auteur de l’article

    @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 🙂

    Répondre
  4. Chamac'h

    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.

    Répondre
  5. michauko Auteur de l’article

    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…

    Répondre
  6. Ze

    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

    Répondre
  7. michauko Auteur de l’article

    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

    Répondre
  8. michauko Auteur de l’article

    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

    Répondre
  9. Philippe

    « 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.

    Répondre
  10. michauko Auteur de l’article

    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 ? 😀

    Répondre
  11. Philippe

    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 » 😉

    Répondre
  12. michauko Auteur de l’article

    ‘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 🙂

    Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.