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/

Répondre à