Bonjour, En parlant de proxy ca m'a fait pensé a la fonction Turbo d'Opera.
Pour le filtrage http via le proxy du réseau c'est raté si on reste uniquement sur du filtrage d'URL. Certains on trouver comment rétablir l'ordre ? On a des étudiants malins sur des écoles qui ont pigeonné leur prof avec Opera Interdire les IP des serveurs proxy utilisé par Opéra pour "compresser" ? Je suis preneur d'autres idées bien passantes ou d'une liste d'IP à jour. Pas besoin de débat sur la neutralité du web ici, on n'a pas vraiment à y réfléchir. Merci et bonne journée Xavier -----Message d'origine----- De : Radu-Adrian Feurdean [mailto:fr...@radu-adrian.feurdean.net] Envoyé : mercredi 28 janvier 2015 12:13 À : Eugène Ngontang; frnog@frnog.org Objet : Re: [FRnOG] [TECH]Design et aspect protocolaire des Proxies On Wed, Jan 28, 2015, at 09:13, Eugène Ngontang wrote: > Ce que j'aimerais savoir : > - Peut-on se passer (le client, disons un wget par exemple) du proxy > si l'on connais l'url de destination? Pour un proxy cote client, il faut de toute facon connaitre l'URL destination. Et dans la plupart des cas, il n'y a pas vraiment de choix laisse a l'utilisateur. Pour un "reverse proxy" (cote serveur), si le backend est accessible a tout le monde, le RP ne sert pas a grand chose (lire a rien). > - le proxy est censé masquer l'existence du client sur le réseau pour > le serveur, seulement dans certains cas, même si une ACL est créée sur > le proxy pour autoriser l'url en question, ce dernier ne parvient pas > à établir la connexion pour le client, qui tombe en timeout. Et une > tentative de connexion directe sans passer par le proxy marche. Dans > ce cas qu'est ce qu'il ne fallait pas ou qu'est ce qu'il faut faire? Tu as un probleme la-bas. - soit il s'agit d'un proxy-cache a utilisation "volontaire", qui en plus semble mal-configure. - soit il s'agit d'un proxy "obligatoire" (pas d'acces a Internet pour les clients, uniquement sur le proxy), dans quel cas tu as plusieurs choses mal-configures. > - le point précédent m'emmène à poser la question de savoir si le > serveur auquel on tente de se connecter doit être configuré pour ou > pour ne pas recevoir des requêtes d'un proxy??? Generalement, je diai que non. De toute facon, si le serveur sait que les clients passent via un proxy, c'est que le proxy lui laisse cette indication, generalement en ajoutant des headers dans les requetes HTTP (pas HTTPS). > - On peut partir sur le cas concret qui m'a poussé à créer ce thread : > * J'ai autorisé une URL sur mon proxy pour un flux https, verx un > serveur > * En testant la connexion avec un wget sur l'url, après > avoir setté la variable https_proxy depuisma console, je ne réussi. Le > client tente indéfiniment et tombe en erreur, typiquement avec une > trace du genre : > " wget https://server_url > --2015-01-28 08:37:20-- https://server_url Resolving proxy_fqdn... > proxy_ip Connecting to proxy_fqdn|proxy_ip|:8000... connected. > Proxy tunneling failed: Service UnavailableUnable to establish SSL > connection. > " > * En unsettant le proxy et en réessayant j'y arrive bien. Est-ce que le proxy autorise la methode "CONNECT" (qui est normalement reserve aux proxys) ? Le HTTPS ne passe pas "en clair" sur les proxy, mais via "CONNECT" (tunnel HTTP, vois-la comme TCP over HTTP). Pour faire passer le SSL "en clair" c'est une toute autre usine a gas, associe plutot au hijacking qu'a la securite, et qu'il fout mieux eviter (je dirai meme "a tout prix"). > Alors > je vais sur mon proxy en question et refais la même requête, et je me > rend compte qu'effectivement le proxy n'est pas autorisé à parler en > SSL au serveur en question, sur les firewall, et je déduis que c'est > là le souci. Voila l'erreur. > - D'après ce dernier exemple, cela veut-il bien dire que le fait de > passer par un proxy ou non est un choix qui n'est pas obligatoire, et > que tout dépend des accès autorisés pour le proxy en question????? Generalement, si. Au niveau du navigateur il y a generalement 3 options: - pas de proxy, connexion directe a 100% du temps - proxy 100% du temps - fichier .pac qui definit vers quels URL il faut putiliser un proxy, et lequel. Le fichier est interprete par les navigateurs et DOIT etre disponible hors proxy (generalement en HTTP). > - Elles pilulent sur la toile, mais je suis preneur de toute bonne > doc couvrant en détail les différentes architectures et façon de > mettre en place les proxies. La meilleure : ne pas mettre de proxy. Des que les clients sont un minimum mobiles, ca devient source d'ennuis. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
