Garder l'IP de la machine

[Ellis]

Une question qui doit être classique mais je n'ai rien trouvé dans le FAQ IPCOP ou en cherchant un peu ici :

J'ai un serveur SMTP derrière un IPCOP (RED-GREEN).

Ce serveur possède une IP publique, et j'ai donc un transfert de port pour le port 25 (smtp) de l'IP publique (RED) vers l'ip privée (GREEN) de la machine.

Mon problème c'est que quand le serveur smtp envoie un mail vers l'extérieur, il apparait comme venant de l'IP du serveur IPCOP, alors que je voudrais qu'il prenne l'IP publique du serveur de mail.

Comment résoudre ça ? (un genre de transfert de port "reverse" ?)

Merci !

[Billou02]

Salut,

ca ne serait pas dans les hotes statiques des fois ?
http://www.ipcop.org/1.4.0/en/admin/html/services.html#services_hosts

@+

[Ellis]

Merci mais je ne pense pas non, ça c'est plutôt pour utiliser un genre de mini DNS local, si on veut par exemple une valeur différente du DNS officiel.

[jdh]

L'ip de sortie ne peut qu'être une ip disponible sur l'interface Red.

"Ce serveur possède une IP publique" : est-elle présente sur l'interface Red ?


On peut imaginer un fournisseur attribuant une range d'adresses ip fixes par exemple en /29. Ce masque donne 6 adresses dont une est prise par le routeur, reste donc 5. On peut alors mettre les 5 adresses sur l'interface Red d'un firewall et rediriger adresse ip/port vers un serveur interne. Je ne suis pas sur qu'IPCOP permettent de faire cela simplement.

Cependant il est assez usuel de n'utiliser qu'une seule adresse et de forwarder selon le port seulement vers de multiples serveurs : port 80 vers serveur1 et port 25 vers serveur2. Sans que cela ne présente aucun problème et cela se fait simplement avec IPCOP.

Bien évidemment, il ne suffit pas de faire un renvoi d'adr ip/port vers le bon serveur. Il faut aussi que, quand c'est le serveur qui initialise une session, il sorte avec la bonne adresse. J'ignore comment IPCOP peut le faire.

[Ellis]

Merci pour la réponse. Oui, l'adresse IP publique est présente sur l'interface red, par le biais d'un alias.
(On contacte très bien le serveur SMTP de l'extérieur via son adresse publique).

L'IPCOP doit à terme filtrer 15 à 20 serveurs, dont de multiples web, qui possèdent donc tous aujourd'hui une IP publique différente. Il y a donc un alias pour chaque IP publique, et un port forwarding, avec le port qui ne change pas, mais juste un passage de l'IP publique vers l'IP privée.

Pour les web ça ne pose pas de problème, car en général ils n'appellent pas eux même des services extérieurs, mais pour le SMTP, vu les controles anti-spam, mon serveur de mail se retrouve avec l'IP de l'IPCOP en sortie et il n'y a plus de correspondance correcte entre son nom et l'IP.

Je ne suis pas sûr d'être très clair, mais j'espérais que quelqu'un aurait déjà rencontré le problème et trouvé une solution.

[Franck78]

Problème connu, pour sortir un serveur caché derrière RED ne prend que l'IP 'maitre' de RED. On pourrait imaginer une table supplémentaire associant des IP internes(+port?) à un alias... Mais bon, c'est un changement important pour 1.4 qui devrait rester telle qu'elle est maintenant!

[jdh]

Franck78 étant un spécialiste d'IPCOP, je pense qu'il faudrait modifier le fonctionnement d'IPCOP pour y arriver.

Par contre avec Shorewall (v3) cela s'appelle le "one to one NAT" et cela se configure dans le fichier /etc/shorewall/nat.


Sinon je ne comprends pas "15 à 20 serveurs, dont de multiples web, qui possèdent donc tous aujourd'hui une IP publique différente".

Premièrement, il me parait difficile d'obtenir une range de type /27 (/29=5 adresses dispo, /28=14 adresses dispo, /27=29 adresses dispo).
Deuxièmement, l'hébergement de multiples sites web ne nécessite ABSOLUMENT pas une adresse par site web : cela est du gaspillage total. Le reverse proxy d'Apache est fait pour cela. De la même façon, pour ftp ou le mail, on peut récupérer ce qui concerne de multiples domaines par une machines pour redispatcher ensuite sur plusieurs serveurs.
Tout cela me semble irréfléchi et partant d'un manque d'expérience.

Heureusement que l'hébergement professionnel n'agit pas de cette façon "une adresse ip par domaine" ! Il y a longtemps que les adresses ip (v4) seraient totalement épuisés.

[Ellis]

Problème connu, pour sortir un serveur caché derrière RED ne prend que l'IP 'maitre' de RED. On pourrait imaginer une table supplémentaire associant des IP internes(+port?) à un alias... Mais bon, c'est un changement important pour 1.4 qui devrait rester telle qu'elle est maintenant!

Ok, en cherchant un peu j'ai trouvé 2 liens intéressants, je ne suis pas sûr d'avoir tout compris mais avec l'aide de notre spécialiste Linux on devrait pouvoir en faire qqchose.

Je les indique ici des fois que ça serve à d'autres :

http://www.the-scream.co.uk/forums/t11460.html

http://marc.theaimsgroup.com/?l=ipcop-u ... 331835&w=2

[Ellis]

Premièrement, il me parait difficile d'obtenir une range de type /27 (/29=5 adresses dispo, /28=14 adresses dispo, /27=29 adresses dispo).

Encore pire, j'ai un /26 et avant c'était même tout une classe C

Je n'ai pas précisé, je suis justement hébergeur de sites, pas un particulier.

Deuxièmement, l'hébergement de multiples sites web ne nécessite ABSOLUMENT pas une adresse par site web

Là encore tu dois te méprendre car tu penses à un hébergement de particulier.
Je n'ai pas parlé de 15 à 20 webs, mais de 15 à 20 serveurs, c'est à dire des machines, qui ont donc toutes une adresse IP (après chaque serveur héberge de nombreux web, tous sur la même IP).

Tout cela me semble irréfléchi et partant d'un manque d'expérience.
Heureusement que l'hébergement professionnel n'agit pas de cette façon "une adresse ip par domaine" !

[jdh]

J'ai bien sur pensé à un particulier ou un professionnel "de base" (ce n'est pas péjoratif) et pas à un hébergeur avec réellement 15 à 20 serveurs. (manque d'infos)

Avec ces infos supplémentaires, je pense qu'IPCOP n'est peut-être pas le firewall adapté. Il serait certainement plus judicieux de réfléchir directement à un script de firewalling dédié (sur une machine dument calibrée). Shorewall permet assez facilement de générer les règles adaptées. (Danc la doc, on trouve de suite ce problème : http://www.shorewall.net/NAT.htm).

Mais à ce niveau, on peut imaginer qu'il serait pas idiot de penser à un filtrage applicatif et pas un simple filtrage de session (comme avec iptables). Ne serait que pour supprimer tous les habituels tentatives du genre "../../../cmd.exe" et autres script-kiddies.

D'ailleurs je pense que le filtrage "iptables" est certes indipensable mais l'important est l'analyse à l'intérieur du protocole.

[Kwint]

Salut Ellis !

Je suis un peu dans ton cas puisque nous possédons aussi une 20aine de serveurs. Je suis tombé sur le même problème que toi d'ailleurs.

La solution est d'ouvrir le fichier "rc.firewall". Il se trouve dans /etc/rc.d/rc.firewall

Avant cette ligne:

/sbin/iptables -t nat -A REDNAT -o $IFACE -j MASQUERADE

Il faut rajouter:

/sbin/iptables -t nat -A REDNAT -s 192.168.2.2 -o $IFACE -j SNAT --to-source 62.161.X.X1
/sbin/iptables -t nat -A REDNAT -s 192.168.2.3 -o $IFACE -j SNAT --to-source 62.161.X.X2
/sbin/iptables -t nat -A REDNAT -s 192.168.2.4 -o $IFACE -j SNAT --to-source 62.161.X.X3

Chaque adresse privée sera transformée en l'adresse publique associée.

J'espère t'avoir éclairé un peu. Chez nous ça fonctionne correctement.

Si tu veux plus de renseignements, voilà mon post originel (regarde vers la fin... il est un peu long ) :
http://forums.ixus.fr/viewtopic.php?t=32752

a+

[Ellis]

Merci Kwint pour ta réponse !

Ca confirme ce que j'avais trouvé dans le 1er lien, je vais donc adopter cette solution également !

[reg]

dans ton cas precis, il pourrait etre judicieux d'envisager une solution autre qu'ipcop, par exemple pfsense (www.pfsense.org) sur lequel le one-to-one nat est prevu d'origine et configurable depuis l'interface web.