Obligation de pinger au préalable

[jpipcop]

Bonjour à tous,

J'ai mis en place un IPCOP dans mon entreprise il y environ 1 an sans rencontrer aucun problème majeur. Néanmoins, j'ai mis en place un nouvel IPCOP dans un nouveau local et nous rencontrons un petit soucis. En effet, nous sommes obligés de pinger la passerelle (donc IPCOP) avant de pouvoir sortir du réseau. Une fois ceci fait, plus aucun problème. L’inconvénient étant qu'à chaque fermeture de session, nous devons effectuer la manip à nouveau.

Notre configuration est tout a fait basique avec une interface verte en 15.63.0.200 et une interface rouge en 192.168.1.200. Au niveau des plugins nous avons seulement Advanced Proxy, URL Filter et ZERINA. Une fois le ping effectué, plus aucun soucis au niveau du réseau, même la prise en main à distance avec UltraVNC fonctionne parfaitement.

Avez vous une quelconque idée de la provenance du problème ?

Merci.

[jdh]

Bonjour, bienvenue sur le forum.

Cela manque un peu de précision : masque réseau, dns, schéma logique, et surtout réglage des clients.

Est ce que l'ipcop est bien la passerelle des clients ?


NB : il est important de s'efforcer de donner, dès le début, le maximum d'infos : cela n'est peut-être pas inutile pour un oeil neuf !

[jpipcop]

Pardon je vais être un peu plus précis.

Alors au niveau du paramétrage des clients nous avons :

OS : Windows 7

Adresse : 15.63.0.X
Masque : 255.255.255.0
Passerelle : 15.63.0.200

Au niveau des DNS, nous utilisons ceux du FAI du type 62.4.X.X. J'ai bien sur configuré le même masque ainsi que les mêmes DNS sur l'IPCOP.

[jdh]

Il y a plusieurs problèmes possibles :

- le dns devrait être interne plutôt qu'externe : ipcop (green) est nativement serveur (relais) dns pour les clients en Green,
- cet adressage n'est pas "private" (au sens de la RFC 1918) : ipcop est-il adapté à un Green non private ?
- des addons sont indiqués, mais je ne vois pas le plus essentiel, BOT ?

[jpipcop]

Merci pour votre réponse jdh.

Alors au sujet du DNS c'est une solution temporaire de test puisque nous allons déménager dans les nouveaux locaux et donc nous aurons notre serveur DNS interne. Concernant l'adressage non privée, je vais approfondir mes recherches mais apparemment il est seulement "conseillé" d'utiliser un adressage privé. Mise à part l'obligation de pinger la première fois, ça fonctionne parfaitement donc je suppose qu'IPCOP gère ce type d'adressage.

Autrement pour BOT, nous avons fait le choix de ne pas l'installer car l'IPCOP nous sert principalement de proxy et pour le NAT/PAT. Même si je suis conscient que le blocage du trafic sortant est important voir primordial pour assurer une sécurité maximale, nous préférons ne pas l'installer pour le moment.

[Franck78]

Hello,

Concernant l'adressage non privée, je vais approfondir mes recherches mais apparemment il est seulement "conseillé" d'utiliser un adressage privé.

C'est un comportement complètement aberrant. Il n'y a rien à approfondir. Les conventions, IANA et des tas d'autres acteurs définissent une solution propre qui n'entre en conflit avec rien d'autre.

15/8 c'est HP.
http://www.iana.org/assignments/ipv4-ad ... -space.xml

Ne pas utiliser ces conventions pour un nouveau site est purement et simplement de la bétise.
Conserver un tel adressage en 2011 est soutenable pour une grosse structure et encore.... depuis le temps qu'on le sait.

Au niveau des DNS, nous utilisons ceux du FAI du type 62.4.X.X. J'ai bien sur configuré le même masque ainsi que les mêmes DNS sur l'IPCOP

Ca ne veut pas dire grand chose cette phase. D'abord pourquoi cacher une ip de serveur dns? Il n'y a aucun 'masque' à configurer !?

En effet, nous sommes obligés de pinger la passerelle (donc IPCOP)

Quelle interface? RED ou GREEN? Depuis l'extérieur ou un poste local?

sortir du réseau.

Mais ca ne veut rien dire

Je dirais qu'avant de venir ici, il faut impérativement passer par la case formation Christian Caleca. On veut bien aider à décortiquer des problèmes bizarres mais surement pas remplacer un admin réseau.


Franck

[jpipcop]

Oula mais faut pas s'énerver pour si peu

Je n'ai pas choisi personnellement l'adressage, mon responsable a fait ce choix pour éviter certains problèmes qu'on rencontrait lorsque des clients avaient le même type d'adressage que nous qui était en 192.168.X.X. De toute manière, même si on utilise un adressage en 15.63.0.X /24, ça reste dans le domaine du privé donc je ne vois pas pourquoi nous serions confrontés à des conflits.

Concernant le DNS, je veux dire que dans l'ipcop, j'ai bien indiqué les 2 DNS fournis par le FAI ainsi que la passerelle 192.168.1.1 puisque nous n'avons pas activés le DHCP.

Je vais vous détailler un peu le réseau. Nous avons déménagé donc tout est en place.

Alors en interne nous avons un switch sur lequel sont reliés nos postes, nos serveurs, ainsi que notre IPCOP (les 2 interfaces).

Interface Verte IPCOP : 15.63.0.200
Interface Rouge IPCOP : 192.168.1.200

Derrière l'IPCOP, nous avons un centrex OneAcess sur lequel sont branchés nos ligne SDSL et ADSL et dont l'interface interne a pour adresse 192.168.1.1 (d'ou le 192.168.1.200 sur l'ipcop rouge)

Sur les machines clients nous paramétrons :

Adresse : 15.63.0.X
Masque : 255.255.255.0
Passerelle : 15.63.0.200
DNS primaire : 15.63.0.1 (notre serveur DNS)
DNS secondaire : 15.63.0.200 (les DNS du FAI étant indiqués sur l'ipcop il devrait faire le relais)

Vous allez surement vous demander pourquoi nous n'avons les 2 interfaces sur le switch et pourquoi nous ne sommes pas forcés de passer par l'ipcop pour accéder à internet donc je vous expliquer brièvement. D'autres personnes externes à l'entreprise vont se servir de notre ligne pour accéder à internet et par conséquent elles utiliseront l'adresse fournie dynamiquement par le OneAccess.

Et donc le soucis c'est que nous sommes de temps en temps obligés de pinger la passerelle 15.63.0.200 donc l'interface verte d'ipcop avant de pouvoir accéder à internet. C'est con ce que je vais dire, mais c'est comme si l'interface se mettait en veille et que nous étions obligés de la pinger pour la faire fonctionner a nouveau. En TSE par contre aucun soucis. La configuration est similaire sauf qu'en DNS secondaire nous avons indiqué le DNS du FAI. Je me demande si le soucis ne viendrait pas tout simplement du DNS du coup.

C'est quand même étonnant ça, car autrement tout fonctionne mis à part qu'en local, c'est extrêmement lent d’accéder à internet alors que sur le serveur TSE ça marche tout de suite.

Si vous avez d'autres pistes, je suis preneur

Merci.

Ps : Je viens de perdre l'accès à internet (heureusement que j'ai eu le temps de copie coller mon pavé) donc j'avais page web inaccessible (que ce soit google ou même l'interface d'administration IPCOP). Ping 15.63.0.200 et hop ca refonctionne parfaitement... allez comprendre

[jdh]

Non, 15.63.x ça n'est pas privé ! Rechercher à RFC1918 (je l'ai déjà indiqué) !
Et si Franck dit que 15/8 est attribué à HP, on peut lui faire confiance, comme 9/8 est attribué à IBM.
D'ailleurs, il suffit de lire http://en.wikipedia.org/wiki/List_of_as ... ess_blocks


Ah, on commence à comprendre !
Pour N'IMPORTE QUEL firewall, il ne faut pas mettre 2 interfaces sur le même switch.
Il est ESSENTIEL de créer des zones physiques en correspondance avec les zones logiques. Et Red n'est pas Green !

Tout cela fait un peu amateur. Je suis désolé de le dire.
Mais il faut prendre une démarche "step by step".

De plus vous allez au devant de problèmes difficiles avec ce joyeux mélange, sans compter la VoIP qui devrait avoir du mal à traverser Ipcop.

En fait, on voit que vous observez des choses, mais vous n'en tirez pas les bonnes conclusions : n'ayez pas de certitude et faites simple.

On ne créé pas de réseaux où des étrangers viennent à leur gré, en utilisant l'ip de sortie, on MANAGE soi-même SON réseau, quitte à être un peu dictateur : il faut savoir s'imposer de temps en temps ...

Pour moi c'est à démonter et à repeindre !

NB : pour les DNS internes, ce sont eux qui doivent avoir, en "forwarders", les dns du fai; le reste, y compris l'ipcop doit avoir seulement les dns internes. (Pour l'ipcop on ajoute "en roue de secours" les dns du fai, donc en 2).

[Franck78]

Que des mauvaises solutions à de faux problèmes. Oui par exemple on sait que pour monter un VPN il faut des réseaux différends. Mais rare sont les VPN entre clients. Et ne pas trouver un terrain d'entente entre 10/8, 172.16/16 192.168/16 faut le faire exprès.

Oula mais faut pas s'énerver pour si peu

Si peu? Pondre une architecture totalement foireuse? Il lit ce forum le chef en question? Suggérez lui une vraie formation réseau parceque là c'est crise de rire ce qu'il fait faire
Mais oui, monter les deux interfaces d'un firewall sur le même switch est communément utilisé, c'est plus facile de la bypasser quand il gène

[mab]

en gros l'adresse local est fait avec des adresses de type publique internet, et le réseau rouge est lui adressé en local...
j'ai une idée aussi dans le genre (mais c'est juste pour taquiner ), pour créer un nouveau fil sur l'impossibilité de faire les mises à jour microsoft, pourquoi ne pas prendre la classe locale 193.238.151.0/255.255.255.0 ? c'est "presque" 192... cela amènera comme conséquence qu'il n'y aura plus aucun accès possible vers microsoft.com

en relisant ce fil, je résume :

le post initial, c'est "pourquoi ça fonctionne pas comme ça", la réponse, c'est "parce que c'est comme ça qu'il faut faire".

il n'y a jamais de bonne justification de prendre une classe d'adresse publique pour gérer un réseau local, ça ne peut qu'amener des problèmes, et ce fil n'est pas le premier qui en parle.

Dans votre cas, ipcop est bypassé de plusieurs façons, son serveur dns n'est pas utilisé, les adresses réseau étant sur le même LAN, je serais curieux de voir les log, il faut imaginer ipcop renvoyer les trames sur le réseau rouge, et qu'il l'entende sur sa carte verte... et pire, inversement !! Toutes les connexions du réseau local sont "entendues" sur sa carte rouge !!

En fait, je crois qu'il serait mieux que l'on sache ce qui voudrait être fait, plutôt que l'on s'oriente sur ce qui ne marche pas, car, là, on est presque dans le pire des cas, qui ne peut pas fonctionner.

[jpipcop]

Bon ben le soucis est réglé, on a modifié notre réseau et surtout, on a remplacé l'ipcop parce que de toute manière, dans cette configuration, il servait pas à grand chose. Tout fonctionne parfaitement désormais

Cet ipcop ira sur notre site secondaire mais cette fois, je l'installerais de manière conventionnelle et par conséquant, il sera impossible à bypasser et surtout, on évitera les problèmes

Merci pour vos conseils, même s'ils ont été parfois assez virulents, au moins ça rentre

[Franck78]

Salut,

Un bon point pour allez dans la bonne voie, cependant, doutant de la formation spontanée, n'hésite pas à présenter les corrections apportées, les surprises rencontrées.
Surtout celles concernant l'adressage qui pourrait en encourager d'autres à se conformer aux règles.

bye