Problème de transfert de port.

[finger]

Bonjour,

J'ai parcouru le forum mais n'ai pas trouvé réponse à ce problème spécifique.

Voici ma configuration :

- ipcop 1.4.18
- pas d'addons
- configuration VERT/ORANGE/BLUE/ROUGE

Blue est utilisé comme DMZ.

L'interface Rouge dispose de nombreuses adresses ips toutes installés en ALIAS.

Nous utilisons des transferts de port pour atteindre la DMZ ainsi qu'une machine dans la zone VERTE.

Le transfert de port qui pose problème est celui qui pointe vers la zone verte. Il pointe en effet d'un couple ip publique/port vers notre serveur de mail.

Ce transfert de port ne fonctionne plus de manière régulière mais plus ou moins aléatoire. Il est nécessaire de redémarrer IPCOP pour qu'il refonctionne.

Quand celui-ci "plante" les autres transferts vers orange fonctionnent toujours ...

Nous avons déjà tenté une réinstallation sur une nouvelle machine en refaisant toute la config a la main, sans résultat.

C'est la première fois que je vois ce genre de chose ...car le reste fonctionne correctement.

Pourriez vous m'aiguiller ?

Merci d'avance.

[ccnet]

Pourriez vous m'aiguiller ?

Oui, utilisez ipcop conformément à sa conception, à savoir dmz en Orange, Lan et Green.
Ensuite n'oubliez pas que le support des adresses ips multiples sur RED est très partiel, très limité.

Dans ipcop le rôle des interfaces ne peut être changé sans risque. C'est inhérent à la conception de base.
Par curiosité qu'est ce qui vous à pousser à utiliser Blue comme dmz alors que Orange est faite pour cela ?

Je peux comprendre qu'ipcop ne réponde pas complètement aux besoins (c'est le cas avec des ips multiples sur RED). Par contre je comprend moins bien les contorsions auxquelles vous êtes conduits. Pour plus de sérenité dans votre exploitatoin j'ai deux conseils à vous proposer.

1. Continuez avec ipcop mais en suivant les règles de son fonctionnement. Si besoin améliorer à la main le support des ipc RED et de leurs translations :

Exemple :
IP interne sur green : 192.168.1.254

IPs Publiques : 213.41.16.217 / 255.255.255.240

Dans /etc/rc.d/rc.firewall, ajouter la ligne suivante pour chaque serveur :

Code: Tout sélectionner

/sbin/iptables -t nat -A REDNAT -s ip_local_dmz -o $IFACE -j SNAT --to-source ip_public

juste avant la ligne:

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


Exemples :

/sbin/iptables -t nat -A REDNAT -s 192.168.1.1 -o $IFACE -j SNAT --to-source 213.41.16.219

/sbin/iptables -t nat -A REDNAT -s 192.168.1.3 -o $IFACE -j SNAT --to-source 62.161.X.X2
/sbin/iptables -t nat -A REDNAT -s 192.168.1.4 -o $IFACE -j SNAT --to-source 62.161.X.X3
/sbin/iptables -t nat -A REDNAT -o $IFACE -j MASQUERADE

Vous obtiendrez ainsi un NAT (1:1 comme on dit dans Pfsense ou un nat statique comme on dit chez Checkpoint). Les modifications indiquées ci dessus sont un problème dans le sens où l'on cesse d'utiliser ipcop tel qu'il a été conçu avec toutes les difficultés de maintenance et d'administration que cela comporte pour le futur. C'est à vous d'en décider.

2. Choisir une autre solution. Pfsense fera cela très bien. Puissant, stable, mais plus complexe.

[finger]

Bonjour,

Merci pour vos réponses, je reprend une architecture installée par une autre personne donc je m'adapte

L'architecture va etre refondu dans 2/3 mois, je dois juste faire fonctionner jusque la ...

J'etudie vos propositions et reviens vers vous.

Merci.

Bonne soiree,

[ccnet]

Dans ce cas, j'opterai pour un minimum de remise en ordre avec ipcop (transfert des serveurs en dmz en orange) et moyennant les modifs proposées pour la gestion des ips multiples sur red, cela vous laisse le temps de mettre au point une configuration propre.
Le premier point me semble assez critique. Il ne serait pas non plus inutile (en fait I N D I S P E N S A B L E) d'installer BOT, un addon qui va permettre un contrôle réel du trafic sortant. Dans sa configuration de base ipcop laisse tout sortir vers RED. Même pour 3 mois ce la me semble important.
Bon courage, il y a un peu de boulot pour les prochains jours.

[finger]

En fait je me suis assez mal exprimé sur un point, en relisant au calme

Green : LAN en 10.1.X
Blue : "Dmz" en 192.168.9.X
Orange : DMZ en 192.168.160.X
Red : ip publique sur FO

Pour BOT, il y'a trop d'implication actuellement pour le mettre en service rapidement, je dois d'abord faire l'etat de tout .... mais j'y pensais

J'envisage de modifier la configuration pour déplacer le serveur qui est en bleu dans orange des que possible (exploitation d'abord ..)

Merci,

[Artefact]

Ensuite n'oubliez pas que le support des adresses ips multiples sur RED est très partiel, très limité.

Bonjour,
On a des IPCOP dont les reds ont des /24 et des /25 publiques, et on n'a jamais eu de soucis depuis plus de quatre ans avec la même configuration que Finger (4 Eth). En même temps, les interfaces sont des INTEL e1000 (ou au pire des Broadcom Bnx3) montées dans des rack Dell.

Et on n'a jamais perdu un paquet, sauf le jour où Redbus-Telecity à perdu son électricité

J'irais voir du côté des cartes s'il y a pas un problème parceque la conf de Finger à l'air ultrasimple. J'ai vu dernièrement une carte Intel QuadEth1000 PCIe baguoter sérieusement sur un serveur. Sinon peut-etre la conf du serveur de mail de Finger ???

Un ethtool -t sur l'interface du serveur de mail donne de bons résultats ?

Cdt,
E.R.

[ccnet]

Et on n'a jamais perdu un paquet, sauf le jour où Redbus-Telecity à perdu son électricité

Les problèmes de pertes de paquets et le fait que le support des ip multiples dur RED soit limité dans IPCOP sont deux questions bien différentes et pour tout dire sans rapport.
Ce n'est parce que les fonctionnalités disponibles avec des ip multiples sur RED sont pauvres que cela occasionne des pertes de paquets. Il est par exemple impossible de faire du nat statique (ou nat 1:1) sans procéder aux modifications que j'ai indiqué avec toutes les réserves que cela comporte. Ce n'est pas pour autant que l'on perd des paquets, mais toutes les connexions sortantes auront pour ip source, une fois ipcop passé, l'ip RED par défaut et aucune des ip en alias. C'est tout. C'est néanmoins un vrai problème.

Ensuite et d'un façon générale, l'utilisation d'un produit en dehors de ses spécifications et le fait que cela fonctionne ne signifie pas que l'on puise en déduire que c'est fonctionnel. On peut juste constater que, dans une configuration très précise, on a de la chance, mais on ne peut rien généraliser parce que justement l'on est hors spécifications. C'est l'exemple type d'une situation où "ça tombe en marche".