iptables , netfilter

iptables , netfilter - réseaux et sécurité - Linux et OS Alternatifs

Marsh Posté le 05-03-2009 à 14:35:47    

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 :
 
http://nsa05.casimages.com/img/2009/03/05/mini_090305124055272929.jpg
 
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 :

Code :
  1. # On reinitialise les regles de Netfilter
  2. iptables -F
  3. iptables -X
  4. # On interdit tous les transferts de paquets dans l'ensemble des reseaux
  5. iptables -P INPUT DROP
  6. iptables -P OUTPUT DROP
  7. iptables -P FORWARD DROP
  8. #Creation de la NAT  (pour naviguer sur le net de façon caché)
  9. iptables -A POSTROUTING -t nat -s 28.50.0.0/16 -o eth0 -j MASQUERADE
  10. iptables -A POSTROUTING -t nat -s 10.0.0.0/8 -o eth0 -j MASQUERADE
  11. # je donne l'acces au ping depuis et vers toutes les machines
  12. iptables -A FORWARD -i eth1 -o eth0 -s 28.50.0.0/16 -d 192.168.30.0/24 -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
  13. iptables -A FORWARD -i eth0 -o eth1 -s 192.168.30.0/24 -d 28.50.0.0/16 -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
  14. iptables -A FORWARD -i eth2 -o eth0 -s 10.0.0.0/8 -d 192.168.30.0/24 -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
  15. iptables -A FORWARD -i eth0 -o eth2 -s 192.168.30.0/24 -d 10.0.0.0/8 -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
  16. iptables -A FORWARD -i eth1 -o eth2 -s 28.50.0.0/16 -d 10.0.0.0/8 -p icmp -j ACCEPT
  17. iptables -A FORWARD -i eth2 -o eth1 -s 10.0.0.0/8 -d 28.50.0.0/16 -p icmp -j ACCEPT
  18. (apparemment, ca marche bien)
  19. # connexions Firewall-Internet (www)
  20. iptables -A OUTPUT -p tcp --dport http -o eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
  21. iptables -A INPUT -p tcp --sport http -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
  22. (cest )
  23. # je donne au client l'acces au web sur le port 80
  24. iptables -A FORWARD -i eth1 -o eth0 -s 28.50.0.0/16 -p tcp --dport http -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
  25. iptables -A FORWARD -i eth0 -o eth1 -d 28.50.0.0/16 -p tcp --sport http -m state --state ESTABLISHED -j ACCEPT
  26. # je donne au client l'acces au serveur web de la DMZ sur le port 80
  27. iptables -A FORWARD -i eth1 -o eth2 -s 28.50.0.0/16 -p tcp --dport http -j ACCEPT
  28. iptables -A FORWARD -i eth2 -o eth1 -d 28.50.0.0/16 -p tcp --sport http -m state --state ESTABLISHED -j ACCEPT


 
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
 

Reply

Marsh Posté le 05-03-2009 à 14:35:47   

Reply

Marsh Posté le 05-03-2009 à 14:55:14    

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 :

sysctl -w net.ipv4.ip_forward=1


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


Message édité par o'gure le 05-03-2009 à 15:05:13

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 05-03-2009 à 14:59:00    

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.

> whois 28.50.0.0

 

OrgName:    DoD Network Information Center
OrgID:      DNIC
Address:    3990 E. Broad Street
City:       Columbus
StateProv:  OH
PostalCode: 43218
Country:    US

 

NetRange:   28.0.0.0 - 28.255.255.255
CIDR:       28.0.0.0/8
NetName:    DSI-NORTH2
NetHandle:  NET-28-0-0-0-1
Parent:    
NetType:    Direct Allocation
Comment:    
RegDate:    1996-03-11
Updated:    2007-08-22

 

OrgTechHandle: MIL-HSTMST-ARIN
OrgTechName:   Network DoD
OrgTechPhone:  +1-800-365-3642
OrgTechEmail:  HOSTMASTER@nic.mil

 

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.


Message édité par o'gure le 05-03-2009 à 15:21:46

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 05-03-2009 à 15:35:29    

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.

Reply

Marsh Posté le 05-03-2009 à 15:48:37    

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.


Message édité par o'gure le 05-03-2009 à 15:52:45

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 05-03-2009 à 15:55:36    

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 ?

Reply

Marsh Posté le 05-03-2009 à 15:56:10    

popopo43 a écrit :

J'ai oublié de préciser que eth0 etait connecté à internet derriere le proxy du bahut, si ca peut t'aider.


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 ?


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 05-03-2009 à 15:56:56    

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

Reply

Marsh Posté le 05-03-2009 à 15:57:57    

o'gure a écrit :


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 ?


 
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

Message cité 1 fois
Message édité par popopo43 le 05-03-2009 à 15:59:30
Reply

Marsh Posté le 05-03-2009 à 16:00:41    

popopo43 a écrit :

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 ?


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.


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 05-03-2009 à 16:00:41   

Reply

Marsh Posté le 05-03-2009 à 16:01:23    

popopo43 a écrit :

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


[:jar jar] 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.


Message édité par o'gure le 05-03-2009 à 16:02:49

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 05-03-2009 à 16:02:30    

Nulle part  ^^

Reply

Marsh Posté le 05-03-2009 à 16:11:50    

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 ?

Reply

Marsh Posté le 05-03-2009 à 16:18:50    

popopo43 a écrit :

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


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.

popopo43 a écrit :


Je t'avouerai que j'hesite quelques fois à utiliser le input/ouput ou le forward...


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.
popopo43 a écrit :


Quant au port internet,


Ce morceau ne veut absolument rien dire.

popopo43 a écrit :

il faut donc que je change ttes les regles pour y mettre le port du proxy ?


ç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).

Message cité 1 fois
Message édité par o'gure le 05-03-2009 à 16:20:35

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 05-03-2009 à 16:35:26    

o'gure a écrit :


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.


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 ?
 

o'gure a écrit :


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.



Je comprend mieux, merci  :jap:  
 

o'gure a écrit :


ç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).

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.

Message cité 1 fois
Message édité par popopo43 le 05-03-2009 à 16:41:07
Reply

Marsh Posté le 05-03-2009 à 16:45:36    

popopo43 a écrit :

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 ?


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.

 


popopo43 a écrit :

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.


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

 
popopo43 a écrit :

Et pour les gens d'internet qu'ils puissent accéder à ce serveur web par le port du proxy, est ce possible ?


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.

 
popopo43 a écrit :

Biensûr tt le réseau interne de l'entreprise disposera d'une connexion internet, donc via le port du proxy ?


Oui, ça, ça ne change pas.

Message cité 1 fois
Message édité par o'gure le 05-03-2009 à 16:47:03

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 05-03-2009 à 16:56:02    

o'gure a écrit :


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


Oui j'ai pu le changer
 

o'gure a écrit :


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.
 


Je doute fort que l'admin m'accorde ce genre de choses :lol: , 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...

Message cité 1 fois
Message édité par popopo43 le 05-03-2009 à 16:56:20
Reply

Marsh Posté le 05-03-2009 à 16:58:10    

popopo43 a écrit :

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


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 05-03-2009 à 17:38:10    

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 =).

Message cité 1 fois
Message édité par popopo43 le 05-03-2009 à 17:50:04
Reply

Marsh Posté le 05-03-2009 à 17:51:26    

popopo43 a écrit :

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 -p tcp --sport 80 -m state --state ETABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -o eth0 -p tcp --dport 80 -m state --state NEW,RELATED,ETABLISHED -j ACCEPT


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.

 


#connexion des internautes vers le serveur web de la DMZ
iptables -A FORWARD -i eth0 -p tcp --dport 80 -m state --state NEW,ETABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -o eth0 -p tcp --sport 80 -m state --state RELATED,ETABLISHED -j ACCEPT

 

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

 

=>


#connexion des internautes vers le serveur web de la DMZ
# le flux initiateur du client web
iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 10.0.0.1 -m state --state NEW,ETABLISHED,RELATED -j ACCEPT
# le flux retour du serveur
iptables -A FORWARD -o eth0 -p tcp --sport 80 -s 10.0.0.1 -m state --state RELATED,ETABLISHED -j ACCEPT


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/lib/exe/fetch.php/netfilter:pileip.gif?w=351
http://irp.nain-t.net/doku.php/130 [...] chitecture

 


popopo43 a écrit :


(j'hesite aussi sur l'utilisation du --dport et du --sport, peut on les renseigner tout les deux sur la même règle ?)


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.

popopo43 a écrit :


#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 -j DNAT --to-destination 10.0.0.1:80  


ok


Message édité par o'gure le 05-03-2009 à 17:53:14

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 05-03-2009 à 18:07:30    

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

Reply

Marsh Posté le 05-03-2009 à 18:27:50    

popopo43 a écrit :

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.


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed