SLt à tous,  
 
je fais en ce moment une actvité sur la configuration du firewall avec la manipulation de Netfilter.
Voici mon shéma réseau :
 

 
Je fais pas mieux pour l'image   , mais ca devrai suffire pour vous montrer ma config.
ALors mon problème cest que je n'arrive pas à partager internet pour le réseau "interne" , et rendre accessible mon serveur Web situé dans la DMZ a internet.
J'utilise pour ca le suivi de connexion et la nat (MASQUERADE), voici mes regles :

 
Si je vide les chaines (input, output et forward),  en acceptant par défaut que tout est accepté pour ces mêmes chaines et en ne mettant que la règle MASQUERADE, tous les postes de mon shéma ont acces internet. J'ai donc oublier une règle mais je ne vois pas ce que ça peut être.
 
Si vous trouvez quelques règles inutiles ou qui n'assurent pas une assez grande sécurité faites le moi savoir, voir même ce qui manque ^^.
Merci de m'eclairer
 

Je n'ai pas regarder précisément tes règles, je le ferais dans un second temps mais il y a fort à parier que tu aies oublié d'activer le routage. Pour cela rajoute dans ton script, de préférence à la fin :

edit, quoique, si tu vides toutes les règles et que ça passe, ce n'est pas ça

1. Tu as oublié les résolutions DNS (UDP port 53)
2. Pour ton serveur Web, rajoute -m state --state NEW,ESTABLISHED à la ligne 44
3. Pour que le serveur en DMZ soit joignable depuis l'extérieur il manque une règle pour le DNAT et 2 règles de filtrage.
4. Pour ton réseau interne, 28.50.0.0/16, à moins que tu fasses parti du DoD, tu n'as pas à les utiliser. Plusieurs sous-réseaux ont été réservés pour des usages privés, il FAUT les utiliser.

cf. la rfc 1918
Ces sous-réseaux sont largement suffisant pour tes besoins. Si nécessaire tu les redécoupes, mais tu n'as pas à taper dans l'espace plublique.

Ca reste encore une fois dans la simulation et je souhaite utiliser mon réseau 28.50.0.0/16 =).
J'ai oublié de préciser que eth0 etait connecté à internet derriere le proxy du bahut, si ca peut t'aider.
Donc j'ai rajouté les regles qui permettent aux requêtes DNS de passer :
 
iptables -A FORWARD -p udp -s <ip_passerelle_proxy> --sport 53 -i eth0 -j ACCEPT
iptables -A FORWARD -p udp -d <ip_passerelle_proxy> --dport 53 -o eth0 -j ACCEPT
 
Mais rien ne marche, même le routeur n'a pas acces a internet.

Relis les règles que tu viens de mettre :
1. regarde exactement ce qu'elle autorise.
2. regarde exactement ce dont tu as besoin

Pour moi c'est normal que ton firewall/routeur ne puisse pas faire de résolution DNS.

la premiere autorise les requêtes DNS(port 53) à passer par l'interface eth0 du routeur avec pour adresse source la passerelle du proxy qui aura résolu le nom
et la deuxieme règle s'occupe du retour.  
Ce n'est pas ce dont j'ai besoin ?

Es-tu forcé de passer par le proxy de ton bahut pour sortir sur le Web ?
ie. dois-tu entrer dans les paramètres de ton browser l'adresse IP et le port de ton proxy ?
si oui, ce port est-il le 80 où est ce un autre ?

il faut donc que je renseigne les deux interfaces lorsque on utilise le forward ou le probleme vient de l'ip du proxy ?

 
Je suis obligé de passer par le proxy du bahut pour avoir internet oui.  
Et je dois en effet rentrer les infos sur les options internet (ip proxy, port)
c'est un port different de 80

Pour moi :
1. un équipement, ton routeur ou un client émet une requete DNS vers ton proxy/passerelle sur le port UDP 53.
2. ton proxy/passerelle répond avec le port source UDP 53 (ie. trafic retour.
 
Ta première règle correspond au trafic retour pour une requête générée depuis un client derrière ton routeur/firewall
Ta seconde autorise la requête en elle même.
 
Pour que ton routeur puisse faire de même, c'est par les chaines INPUT/OUTPUT qu'il faut passer. La chaine FORWARD c'est uniquement pour le trafic qui ne fait que transiter par ton firewall.
 
Sinon tu as la commande "iptables -L -v -n" qui te permet de voir l'ensemble de tes règles et les statistiques de paquets pour chaque chaine. Ca te permet de voir si le trafic attendu est passé par la chaine que tu voulais et voir où cela bloque
 
Sinon tu as wireshark qui te permet d'analyser le trafic, et donc de déduire quel flux ouvrir.

Et où autorises tu ce port différent ?
Lorsque tu utilises un proxy applicatif, ton browser va établir une session TCP sur l'adresse IP/port TCP que tu as indiqué dans la conf du browser. Le trafic web va uniquement transiter dans cette session TCP. Sur ton réseau tu n'auras pas de trafic TCP/80 pour tes requêtes web, uniquement un flux vers le proxy, vers le port adéquat. Il faut donc l'ouvrir.

Nulle part  ^^

Voici donc les règles modifiées  pour la résolution DNS :
 
iptables -A INPUT -p udp -s <ip_passerelle_proxy> --sport 53 -i eth0 -j ACCEPT
iptables -A OUTPUT -p udp -d <ip_passerelle_proxy> --dport 53 -o eth0 -j ACCEPT  
 
Je t'avouerai que j'hesite quelques fois à utiliser le input/ouput ou le forward...
Quant au port internet, il faut donc que je change ttes les regles pour y mettre le port du proxy ?

Tes règles précédentes étaient correctes. Elles correspondaient aux écchanges DNS entre tes clients (ie. derrière ton firewall) et le proxy/passerelle qui fait la résolution DNS. Il manquait simplement ces deux règles pour le trafic DNS entre ton firewall et le proxy/DNS.
netfilter/iptables fait cette distinction.

Simple :

• si le trafic est initié par une application ou à destination d'une application qui tourne sur l'équipement où tu mets du filtrage, il faut utiliser INPUT et OUTPUT.
• si le trafic est juste en "transit", c'est à dire si au final le trafic est initié par un équipement autre que ton firewall => forward.

Ce morceau ne veut absolument rien dire.

ça dépend de ce que tu veux :

• Si tu veux autoriser le trafic HTTP (tcp/80) entre tes clients dans le sous-réseau 28.50.0.0/16 et ton serveur en DMZ, non il faut garder des règles pour le port TCP/80 entre ces deux sous-réseau.
• Si tu veux que tes équipements (sous réseau 28.50.0.0/16 et ton firewall) puisse accéder au web via le proxy, oui il faut rajouter des règles/modifier les existentes pour autoriser ces flux (c'est à dire mettre des règles explicite vers l'adresse IP de ton proxy et le port TCP de ton proxy).

Je viens de commenter la partie sur DNS, et ca ne m'empeche pas de surfer sur internet sur une machine de mon réseau privé. Qu'en penses tu ?
 

Je comprend mieux, merci    
 

A vrai dire, les deux. car je souhaite que le serveur WEB soit autant accessible par le réseau interne que par les internautes.  
Le serveur web de la DMZ serait donc accessible par le réseau 28.50.0.0/16 sans passer par internet(ce qui est je pense logique) donc par le port 80.
Et pour les gens d'internet qu'ils puissent accéder à ce serveur web par le port du proxy, est ce possible ?
Biensûr tt le réseau interne de l'entreprise disposera d'une connexion internet, donc via le port du proxy.

Vu que tu passes par un proxy, c'est normal. Voici ce qu'il se passe :

• L'utilisateur indique une url dans le browser
• le browser établit une session TCP sur le bon port avec le proxy
• le browser transmet l'url via cette session TCP au proxy
• le proxy s'occupe de la résolution DNS et de la récupération de la ressource HTTP demandée
• le proxy, au travers de la même session TCP que précédemment te donne la ressource que tu as demandée.

Grosso modo, c'est le proxy qui fait tout le boulot. Si je t'ai indiqué de rajouter ces règles, je ne savais pas que tu passais par un proxy. Dans ce cas où il y a une  connexion directe à internet (ie. sans proxy), ces règles sont nécessaires vu que c'est ton browser qui résolvera les noms de domaines.

Ca ok, ça sera possible. Il faudra juste indiquer au browser que pour tel subnet, il ne faut pas passer par le proxy.

Vu la configuration de ton réseau, je doute fortement que ton serveur web sera accessible depuis internet. Du moins dans ta simulation. Pour que cela fonctionne, il faut absolument que les requêtes des utilisateurs puissent arriver à ton firewall. Si dans ton bahut on oblige les gens à passer par un proxy, je doute qu'il accepte le flux vers ton serveur web. Quoiqu'il en soit, tu seras obligé de demander aux admins du réseaux de ton bahut de rediriger le port 80 arrivant sur leur accès internet vers ton firewall. Sans ça, c'est mort.

Oui, ça, ça ne change pas.

Oui j'ai pu le changer
 

Je doute fort que l'admin m'accorde ce genre de choses , je vais devoir trouver un autre moyen pour montrer que la connexion depuis internet vers le serveur Web marche. Car je prévois de faire une redirection(le DNAT/ prerouting que tu m'a dit tout à l'heure) et il faut au moins que je puisse démontrer ça par un test. Penses tu que je puisse utilisé qu'une simple machine du réseau 192.168.30.0 pour simuler la machine internet ou ca n'a aucun interet ?
Du moins pour montrer la redirection...

Oui.
Tu prends une machine sur ce réseau, tu tapes l'adresse IP privée de la carte eth0 de ton firewall, si tout est ok, tu tomberas sur le serveur web (prends soin de désactiver le proxy dans le browser avant).

Voici le reste, dis moi si quelque chose ne tourne pas rond:
 
#connexion des internautes vers le serveur web de la DMZ
iptables -A FORWARD -i eth0 -d 10.0.0.1/32 -p tcp --sport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -o eth0 -s 10.0.0.1/32 -p tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
 
(j'hesite aussi sur l'utilisation du --dport et du --sport, peut on les renseigner tout les deux sur la même règle ?)
 
#Redirection de toutes tentative de connexion http sur le parefeu vers le serveur WEB
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -d 192.168.30.15 -j DNAT --to-destination 10.0.0.1:80  
 
 
Demande confirmation =).

Non c'est faux. C'est l'inverse. Tu raisonnes comme si ton client était en DMZ et ton serveur sur internet/LAN
Ta première règle suppose qu'un équipement va transmettre un flux avec le port source TCP à 80 via eth0, dans notre contexte, le serveur est derrière le firewall (derrière eth2 de mémoire= et le client derrière eth0. Seul le serveur va mettre le port source de son flux à 80.
Pour la seconde règle c'est pareil, la tu décris un flux qui sort par le port eth0 vers le port 80 en destination, c'est tout l'inverse.
Pareil pour l'état de tes connexions new,establised... c'est l'inverse.
Par contre, oui on utilise la chaine forward.

Tu vas avoir deux flux :
1. le client sur le réseau 192.168..., va émettre un flux vers ta carte eth0 sur ton firewall. C'est ce client qui va initialiser le flux, donc l'état de la connexion va etre NEW. Et il émet vers le port 80 de ton serveur. Donc son paquet TCP va avoir comme port destination 80.
2. ton serveur, via la redirection de flux que tu as mis en place (cf. en dessous) reçoit le trafic et y répond. A ce moment l'état de la connexion passe sur le firewall en ESTABLISHED, et le serveur lui, mets en ports source le port 80.

tu peux également rajouter l'adresse IP, histoire de...

=>

On peut mettre l'adresse IP privée,  vue qu'à ce niveau, là redirection aura déjà eu lieu (cf

http://irp.nain-t.net/doku.php/130 [...] chitecture

Si tu connais le port source et le port destination, oui tu peux, mais généralement tu ne connais qu'un seul port (le port du service). Le second port est généré pseudo-aléatoirement (du moins dans une majorité des protocoles dont HTTP).
Pour rappel, en une seule règle tu ne décris un flux que dans un seul sens.

ok

Tout marche, merci o'gure.
Pour l'histoire de l'ip privée que l'on peut rajouté dans les regles internautes>>server_Web_DMZ
Peut tu m'expliquer stp

Expliquer quoi ?
J'ai précisé ceci afin d'être au plus proche du trafic. Lorsque l'on établit des règles de filtrage, si les flux ne sont pas trop important, il est bon d'être le plus précis possible dans les règles (si trafic trop important vient le problème des performances et dans ce cas on peut limiter les règles de correspondance histoire d'être plus léger mais plus "laxiste).
 
Je t'ai donc demandé de rajouter, pour la règle de filtrage autorisant les flux entre les internautes et ton serveur en DMZ, l'adresse IP de ton serveur Web. Histoire de coller plus au trafic. J'ai précisé adresse privée car certains peuvent penser qu'il s'agit de l'adresse IP publique (ie. celle de eth0 dans notre cas, elle n'est pas publique mais conceptuellement, elle est dans ta simulation, elle l'est). Hors la translation d'adresse a déjà eu lieu, donc il faut indiqué l'adresse privée.