[RESOLU] NATer plusieurs adresses publiques

[xandre]

Bonjour,
Sur mon lieu de travail, un accès internet a été mis en place. Le routeur a été mis en place. A notre charge (et donc ma charge) de mettre en place un Firewall.
Je dispose de 8 adresses IP publiques. Donc 6 utilisables véritablement (2 ip sont pour le réseau et le broadcast).

Connaissant Ipcop 1.4.21, je décide d'en mettre un en place.
Config réseau VERT / ROUGE (IP publique statique).

Schéma :
lan ---- VERT (@ ip interne) ---- Ipcop ---- ROUGE (@ ip publique 1) ---- ROUTEUR (@ IP publique 2) ---- Internet / wan.

La sortie sur Internet s'effectue correctement (je vous écrit ce post depuis cet accès web).

J'ai un serveur web pour l'instant dans le réseau VERT (on considère que les DNS du FAI ont lié cette adresse ip à mon nom de domaine "www.domaine.fr").
Deux autres serveurs vont bientot devoir etre disponibles depuis Internet.

Comment puis-je NATer le trafic à partir de mon adresse IP publique n°3 vers ce serveur web ?
j'ai eu beau tester des configurations dans l'onglet PAREFEU -> TRANSFERT DE PORTS, je n'ai pas réussi jusqu'à présent.
Quelle procédure dois-je suivre ?

Merci d'avance.

[ccnet]

Plusieurs points.

De façon tout à fait factuelle avez vous créé les alias ip correspondant aux différentes adresses ?
http://www.ipcop.org/1.4.0/en/admin/htm ... s-extalias

Ensuite selon le type de services que vous allez mettre en place :
http://forums.ixus.fr/viewtopic.php?t=4 ... t=snat+red

Pour en venir aux choses qui fâchent, ipcop 1.4.x n'est pas du tout adapté au traitement de ce besoin (ip publiques multiples). Le lien précédent donne des contournements. Je les ai pratiqué, ils fonctionnent très bien mais ce n'est pas une situation sainement administrable. Je les ai abandonné depuis.
Une solution possible est Pfsense.

Ensuite si votre besoin est d'avoir de multiples serveurs Web, il y a au moins cinq raisons qui militent pour une solution différente.
1. Les serveurs virtuels permettent de résoudre le problème avec une seule ip publique évitant le gaspillage de ressources (ip et machines).

2. Connecter un serveur Web à internet même derrière un firewall reste dangereux. Il est devenu pratiquement indispensable de mettre en place un firewall applicatif. C'est à dire un reverse proxy (Vulture pas exemple) assurant un filtrage des url envoyées au serveur web. La majorité des intrusions sont réalisées par l'exploitation de failles applicatives. Un site php dont le code n'a pas été conçu pour résister est vulnérable à toutes sortes d'injections. Le reverse sait aussi desservir plusieurs serveurs web.

3. Il en découle un nécessaire découpage du réseau avec deux dmz (au moins). Le reverse proxy et le firewall ne saurait être dans la même zone. Au passage une question : vous n'avez aucun poste client dans votre réseau ? Les serveurs web n'ont rien à faire dans le Lan (Green).

4. Ipcop ne permet pas de mettre en place comme il convient ce type d'architecture.

5. Si vos serveurs à venir ne sont pas des serveurs web, mais des serveurs initiant des connexions sortantes, vous allez manquer de fonctionnalités avec Ipcop (Cf second lien pour contournement). Il ne sait pas gérer autre chose que le nat de toutes les ip derrière l'ip RED.

[xandre]

Je vous remercie pour votre réponse.

J'ai oublié de dire qu'effectivement j'avais bien rempli la page Réseau --> Alias :
(Règle activée) :
Nom Alias IP
www.mondomaine.fr ----- adresse ip publique n°3

En ce qui concerne la page PAREFEU --> Transferts de ports:
TCP DEFAULT IP : 80(HTTP) => aa.bb.cc.84 : 80(HTTP)
Accès autorisé depuis : xx.yy.zz.108

xx.yy.zz.108 étant l'ip publique n°3.

Ce serveur web héberge virtuellement 2 sites web (merci Apache).

Les 2 autres serveurs seront un serveur SSH pour que les enseignants puissent accéder à une application hébergée sur un serveur "administratif".
Et un serveur de messagerie / liste diffusion type SYMPA.

Si Ipcop ne sait gérer correctement plusieurs IP dynamiques, il peut surement gérer plusieurs translations menant vers différentes IP du Lan à partir d'une seule IP publique.

Pour le reste de votre réponse très précise, pour tout vous dire, et sans prendre de détour, je suis largué.
La raison est que j'ai appris et apprends encore l'administration système et réseau sur le tas (je ne fais pas que ca en plus).
Vous comprendrez donc que je n'ai pas un niveau ingénieur.
Je vais donc me renseigner sur toutes les technologies que vous avez évoquées (j'espère avoir le temps).

Merci pour votre réponse.

J'ai quand meme une autre question : quelle est donc alors la réelle fonction des ALIAS dans Ipcop ?
Il est bien évoqué le fait de pouvoir "gérer" plusieurs ip publiques.

[ccnet]

A priori votre transfert de port est correct sauf pour le champ "Accès autorisé depuisé qui doit être vide dans votre cas? Il sert à restreindre les adresse ip sources pouvant utiliser le transfert de port. Ici vous avez mis l'ip destination.

Et un serveur de messagerie / liste diffusion type SYMPA.

Ce serveur va poser problème. Lorsqu'il enverra des mails il utilisera l'ip de red et non un des alias ip.
Avec ipcop il faudrait modifier manuellement le fichier de conf tel que décrit dans mon second lien.

quelle est donc alors la réelle fonction des ALIAS dans Ipcop ?
Il est bien évoqué le fait de pouvoir "gérer" plusieurs ip publiques.

La fonction offre une gestion minimaliste des ip multiples sur red. Je crois qu'une gestion complète est prévue dans la V2 qui est sur le gaz.

Sur ce projet vous prenez des risques importants si vous ne reconsidérez pas fondamentalement votre architecture.

[jdh]

Pour compléter ce qu'écrit ccnet :


* Fausse idée sur les adresses multiples :

J'ai plusieurs serveurs à mettre en place en DMZ => donc j'ai besoin de plusieurs adresses.

NON, en effet, il n'y a nul besoin de plusieurs adresses, une pour chaque serveur.
Ce n'est le cas que SI les serveurs utilisent le MEME protocole (par exemple https=443/tcp).

Pour http (=80/tcp), on peut héberger plusieurs sites web soit sur une seule machine soit sur plusieurs serveurs en passant d'abord par une machine qui triera le trafic et le renverra sur le bon serveur.

Idem pour smtp (=25/tcp).


* Effets pervers d'adresses multiples :

S'il y a plusieurs serveurs, un par adresse, et que ceux-ci s'avisent d'initier un autre trafic, il faut éviter qu'ils utilisent une autre adresse pour cet autre trafic : ce qui s'appelle faire du source nat.


IPCOP n'est pas fait pour ces gymnastiques : il est vraiment prévu pour 1 adresse externe et point. Parce que modifier manuellement le script rc.firewall pour permettre le source nat qui va avec les alias, je n'appelle pas cela "prévu" !

[xandre]

Donc pour synthétiser, on peut tout NATer à partir d'une seule adresse publique tant que les serveurs derrière n'utilisent pas le meme port (http, ftp, smtp, ssh ...). Ce qui tombe sous le sens et correspond à la fonctionnalité première de la translation d'adresse.

L'analogie vaut ce qu'elle vaut mais ca se rapproche d'une configuration du NAT sur la box qu'on a chez soi.

Et tant pis pour les autres adresses qui ne serviront pas.

Je reviens sur mon expérience quant au NAT sur Ipcop :
Rappel : ip publique 1 -> le routeur, ip publique 2 -> ipcop, ip publique 3 -> NAT sur serveur web

J'ai modifié ma configuration précédente de cette manière :
j'ai toujours mon ALIAS
www.MonDomaine.fr --- ip publique 3

mais dans le transfert de port :
dans la case ALIAS IP j'ai sélectionné non pas DEFAULT IP mais mon alias créé précédemment.

ALIAS IP IP DESTINATION
TCP aa.bb.cc.dd :80(HTTP) => 10.8.20.84 : 80(HTTP)

Cela fonctionne quand j'entre l'IP publique, je tombe sur mon site web.
Je ne peux m'avancer plus car j'ai un problème DNS entre mon nom de domaine et l'adresse ip publique (je vais contacter mon fai).

[xandre]

Je considère le sujet comme résolu dans le sens ou la réponse à la question 1ere a été trouvée. (nater ip publique vers ip lan).
Cependant il est des questions qui ont été soulevées et sont fort intéressantes.
Libres à vous de continuer le topic.

[Franck78]

Hello,

Quand on dispose d'un petit reseau_publique/3 pour 6 IPs donc, et bien on branche directement 6 IPCops !
Une IP publique à chacun. Depuis le temps que l'on dit qu'IPCop est mauvais avec plusieurs IP

Bon bien sur derriere chaque GREEN (qui ne veut pas dire exclusivement PC de travail) ca fait plusieurs réseau qu'il vaut mieux différents (pas tous à 192.168.0.x), qu'un autre routeur/fw/debian/shorewall reliera entre eux et dont la sortie conduira vers le(s) réseau(x) interne(s).

[xandre]

ca va peut etre en surprendre quelques uns mais mon serveur web et mon serveur SSH (chacun sur une ip publique) sont parfaitement accessibles depuis l'extérieur.
Et c'est ipcop qui gère la redirection.

[jdh]

Attention à ce qu'on écrit :

- un serveur web et un serveur ssh avec chacun son ip publique fonctionne bien : évidemment cela fonctionne bien mais cela fonctionnerait tout aussi bien s'il n'y avait qu'une seule ip publique !

- le vrai problème c'est quand il y a plusieurs ip publiques, si un serveur en dmz initialise une session, il vaut mieux qu'il sorte avec son ip publique et non celle du firewall !!!

Or ipcop ne facilite la vie qu'en créant les "alias ip" (est ce bien l'appellation proposée ?) alors qu'il ne propose pas les règles nécessaires de SNAT !


Je reste persuadé qu'il y a gaspillage d'adresse ip (et c'est le cas ici !).

[ccnet]

ca va peut etre en surprendre quelques uns mais mon serveur web et mon serveur SSH (chacun sur une ip publique) sont parfaitement accessibles depuis l'extérieur.
Et c'est ipcop qui gère la redirection.

Je ne vois rien de surprenant. Je confirme le gaspillage d'ip publique.

[xandre]

Effectivement, je n'ai pas besoin de toutes ces adresses publiques. Mais elles m'ont été affectées d'office et ce dans le cadre d'un programme régional. Je n'ai donc pas eu mon mot à dire.
Dans tous les cas (utilisées ou non) elles sont gaspillées. Mon point de vue est donc de les utiliser afin de continuer à mieux maitriser les fonctionnalités de Ipcop. Ainsi que connaitre les limites du système grâce à vos réponses.

Ce gaspillage a donc eu une utilité :
) j'ai appris
) je partage mon savoir nouvellement acquis.
Cette procédure pourra alors servir à d'autres dans un cadre nécessitant réellement plusieurs ip publiques avec des serveurs ne nécessitant pas d'initialiser de connexions.

J'ai donc bien compris que je vais être "coincé" lors de la mise en place du serveur de liste de diffusion / messagerie qui ne pourra pas utiliser sa propre ip publique mais celle d'ipcop.