Bonjour,
 
Soit le contexte suivant :
 
Côté client, le navigateur est configuré pour rediriger les requêtes HTTP vers un serveur proxy/pare-feu situé sur le LAN et sur un port spécifique. Lorsque l'utilisateur valide une URL saisie dans le navigateur, une requête DNS est construite afin de connaître l'adresse IP de la machine distance située sur le WAN (mécanisme de résolution de noms). Le client établit alors une communication TCP/IP avec la machine distante (syn- syn/ack - ack). Une fois le handshake terminé, la commande GET est envoyée. L'échange des data se poursuit.
 
Mes questions sont :
 
1) Si je vide le cache du navigateur et que je capture les trames sur l'interface de la machine cliente connectée au réseau, pourquoi je ne vois pas passer les requêtes DNS ?  
2) Je place ma machine cliente derrière le serveur proxy/pare-feu A, le client instaure un dialogue avec machine distante. Je place la même machine derrière le serveur proxy/pare-feu B, le client instaure un dialogue TCP/IP uniquement avec le serveur proxy (NAT ?). Qu'est ce qui diffère dans la configuration de ces deux pare-feu ?
 
Merci pour votre entraide. J'apporterai des précisions si besoin.

1) Si utilisation d'un proxy, pas de résolution DNS, c'est le proxy qui s'en occupe.
 
2) Rien compris.
 
3) Mauvaise section.

 
Certes, c'est le proxy qui traite la requête et place le résultat en cache. Or si je ne configure pas le navigateur à rediriger les requêtes HTTP vers le serveur proxy, je vois les requêtes DNS passer.
Lorsque je configure le navigateur à rediriger les requêtes HTTP vers le serveur proxy, je ne m'occupe que du proto HTTP et des requêtes construites sur le port de destination 80. Je n'agis pas sur le DNS. Théoriquement le fait de forcer le navigateur à parser les requêtes HTTP et à les rediriger vers le port spécifique du proxy ne doit avoir aucune incidence sur le DNS. Or selon que j'active ou désactive la redirection, je vois ou ne vois pas les requêtes DNS et là je ne comprends plus rien !    
 

 
- [cas 1]L'utilisateur se trouve à l'adresse 192.168.1.2 veut consulter un site Web se trouvant à l'adresse 163.173.128.121. L'adresse 192.168.1.2 est derrière le proxy/pare-feu A dont l'adresse est 192.168.1.4. La gateway de 192.168.1.2 est l'adresse 192.168.1.4.
 
Requête capturée sur la machine 192.168.1.2  Source : 192.168.1.2 Destination : 163.173.128.121 Port source : 3555  Port de destination : 80
 
Le Firewall fait sa translation d'adresses avec son adresse publique en 193.48.44.35  
 
Réponse  capturée sur la machine 192.168.1.2 : Source : 163.173.128.121 Destination : 192.168.1.2 Port source : 80  Port de destination : 3555
 
- [cas 2]L'utilisateur se trouve à l'adresse 192.168.1.2 veut consulter un site Web se trouvant à l'adresse 163.173.128.121. L'adresse 192.168.1.2 est derrière le proxy/pare-feu B dont l'adresse est 192.168.1.5. La gateway de 192.168.1.2 est l'adresse 192.168.1.5
 
Requête capturée sur la machine 192.168.1.2  Source : 192.168.1.2 Destination : 192.168.1.5 Port source : 3555  Port de destination : 80
 
Le Firewall fait sa translation d'adresses avec son adresse publique en 193.48.44.35  
 
Réponse  capturée sur la machine 192.168.1.2 : Source : 192.168.1.5 Destination : 192.168.1.2 Port source : 80  Port de destination : 3555
 
A noter que le système et l'applicatif qui tourne sur les deux pare-feu sont quelques peu différents.  
 

(??) HTTP et DNS services applicatifs au dessus de la couche transport

Pk le client ferait une résolution DNS si il sait que ça lui servira à rien puisque c'est le proxy qui traitera sa demande ?
 
Et ton truc, dans le premier cas, c'est un firewall qui fait du NAT, dans le 2ème c'est un proxy

 
Certes mais en quoi le fait de configurer le navigateur à rediriger les requêtes HTTP vers le serveur proxy, lui fait dire qu'il n'a pas besoin de faire une requête DNS ? par quel mécanisme ? est-ce lié au code de développement du navigateur ?

Prenons un autre exemple.
Tu as besoin de pain.
Tu as ta mère.
 
Soit tu demandes à ta mère (ou ton père ou autre) l'adresse de la boulangerie, soit tu demandes à ta mère d'aller te chercher du pain.
 
Si tu demandes à ta mère d'aller te chercher du pain, tu t'en fous de l'adresse de la boulangerie.
Là c'est pareil. C'est le proxy (ta mère) qui s'occuppe de connaitre l'adresse du site (de la boulangerie).
 
c'est lié au dev du navigateur bien évidemment.

C'est sans doute comme tu le précises implémenté au niveau du navigateur.
 

 
... les deux serveurs jouent le rôle de proxy. Ce n'est donc pas l'élément explicatif.
 
Sur les deux serveurs, il y a modification entre adresse privée et publique par l'intermédiaire de l'en-tête des paquets IP sur le flux sortant.  
Concernant le flux entrant (réponse à une requête), le serveur reçoit le message et remplace dans l'entête du message IP l'adresse publique par l'adresse privée de la machine. Sur ce que j'ai pu lire sur le sujet, le NAT est défini ainsi.
Compte tenu de cela, pour moi les deux serveurs font du NAT dynamique.
 
Concernant le flux entrant et la transmission de la trame reçue sur le LAN, dans un cas, l'IP source (hôte distant) est remplacée par l'IP du serveur et dans l'autre cas, elle ne l'est pas. C'est l'IP source publique de l'hôte distant qui est "maintenue". Puisque dans tous les cas, on parle de translation d'adresses, quelle est cette spécificité ?

si tu as un proxy, tu n'as pas de communication avec l'hote externe puisque tu passes par le proxy. Toi tu fais ta connexion avec le proxy, le proxy fais la connexion avec le serveur mais il y a bien 2 connexions

Bien sûr que si.
Faire de la translation d'adresse, ce n'est pas avoir un rôle de proxy.
 
Dans le cas de la translation d'adresse, la passerelle s'en fout de savoir si c'est du HTTP, du FTP, ou n'importe quel protocole : elle va simplement prendre le paquet, changer l'adresse source dans l'en tête (la remplacer par la sienne), garder trace quelque part de la machine émettrice sur le réseau local, et enfin envoyer le paquet TCP à qui il faut.
Au retour, elle va recevoir le paquet de la machine distante (serveur HTTP ou ce que tu veux, peu importe), retrouver l'émetteur sur le réseau local. Ce que tu as observé correspond à cette explication.
 
Dans le cas du proxy HTTP, on n'est plus sur la même couche (modèle OSI), on est au dessus du cas précédent. L'utilisateur sur le navigateur va demander 123.45.67.89 : si le navigateur est configuré pour passer par un proxy, il va envoyer un paquet au proxy "je veux 123.45.67.89". Le proxy qui écoute sur un port, va lire cette info, et créer un nouveau paquet à destination de 123.45.67.89, et attendre la réponse. Une fois ce retour obtenu, il va répondre au navigateur client sur la connexion initiée par le client.
 
Dans le 1er cas (nat), on a un seul paquet qui est modifié. Dans le 2nd (proxy), on a, pour la requête HTTP, 2 paquets distincts : client <=> proxy et un autre proxy <=> serveur.

on est bien d'accord. Je n'ai jamais précisé le contraire.
 

c'est cette information là qui me manquait afin de mieux comprendre
 

OK, or dans le premier cas évoqué, la situation s'appuie sur le pare-feu IPCOP qui joue le rôle de serveur mandataire (cf. copie écran) ... (???)
 

il est en mode transparent là donc pas de configuration sur le poste client. Le client croit qu'il fait du direct, ce qui peut expliquer ce comportement (à voir, j'ai pas étudié comment fonctionne au niveau ip le mode transparent dans squid)

Merci Je@nb pour ce complément d'info. Je n'ai pas accès à la config du deuxième pare-feu (cas n°2) en raison de droits insuffisants mais il doit être également configuré en mode transparent car si le client n'est pas configuré pour passer par le proxy, les requêtes sont filtrées (utilisation de squidguard certainement) au niveau du serveur. Une règle de pare-feu doit rediriger chaque requête reçue depuis les postes clients sur le port 80 vers le port 3128.

Oui, de mémoire, le mode transparent c'est quelque chose comme ça; une règle iptables qui fait 80 => 3128.