Problème de Routage IPCOP 2.0
Résolu
dark.revan
Messages postés
7
Date d'inscription
Statut
Membre
Dernière intervention
-
dark.revan Messages postés 7 Date d'inscription Statut Membre Dernière intervention -
dark.revan Messages postés 7 Date d'inscription Statut Membre Dernière intervention -
A voir également:
- Problème de Routage IPCOP 2.0
- Net framework 2.0 - Télécharger - Divers Utilitaires
- Cool edit pro 2.0 free download - Télécharger - Édition & Montage
- Usb 2.0 video grabber driver windows 10 - Télécharger - Divers Utilitaires
- Telecharger scratch 2.0 - Télécharger - Éducatifs
- Telecharger incredimail 2.0 en français gratuit - Télécharger - Mail
6 réponses
Bonjour,
D'après un collègue et le logiciel Wireshark, les trames redirigées depuis les postes clients sont bloquées.
Comment faire pour les débloquer ?
Cordialement,
Revan.
D'après un collègue et le logiciel Wireshark, les trames redirigées depuis les postes clients sont bloquées.
Comment faire pour les débloquer ?
Cordialement,
Revan.
La solution :
iptables -A CUSTOMFORWARD -i lan-1 -o lan-1 -j ACCEPT
En fait, par défaut IPCop 2.0 bloque le trafic vert-vert... donc il n'est pas capable de router correctement.
Il faut donc autoriser ce trafic avec cette règle iptables.
iptables -A CUSTOMFORWARD -i lan-1 -o lan-1 -j ACCEPT
En fait, par défaut IPCop 2.0 bloque le trafic vert-vert... donc il n'est pas capable de router correctement.
Il faut donc autoriser ce trafic avec cette règle iptables.
Je viens de trouver une partie de solution :
Sur IPCOP v 2.0, le fichier "/etc/rc.d/rc.local" a été remplacé par "/etc/rc.d/rc.event.local".
Il y a une ligne qui indique que le code en dessous de cette dernière remplace le fichier rc.local. Il faut écrire :
if ["${1}" == "system" -a "${2}" == "up"]; then (cette ligne est déjà écrite)
route add -net 172.18.0.0 netmask 255.255.0.0 gw 172.16.0.0 (à écrire à la place de "echo...")
fi (déjà écrite)
Ceci me permet de ne pas perdre la route à chaque redémarrage d'IPCOP.
Le ping depuis IPCOP fonctionne mais depuis un client Windows, j'ai toujours cette réponse au ping "impossible de joindre le port de destination".
J'ai essayé un tracert et là : "impossible de joindre le protocole de destination".
Amis du net, je suis tout ouïe.
Bien cordialement,
Revan.
Sur IPCOP v 2.0, le fichier "/etc/rc.d/rc.local" a été remplacé par "/etc/rc.d/rc.event.local".
Il y a une ligne qui indique que le code en dessous de cette dernière remplace le fichier rc.local. Il faut écrire :
if ["${1}" == "system" -a "${2}" == "up"]; then (cette ligne est déjà écrite)
route add -net 172.18.0.0 netmask 255.255.0.0 gw 172.16.0.0 (à écrire à la place de "echo...")
fi (déjà écrite)
Ceci me permet de ne pas perdre la route à chaque redémarrage d'IPCOP.
Le ping depuis IPCOP fonctionne mais depuis un client Windows, j'ai toujours cette réponse au ping "impossible de joindre le port de destination".
J'ai essayé un tracert et là : "impossible de joindre le protocole de destination".
Amis du net, je suis tout ouïe.
Bien cordialement,
Revan.
Bonjour et merci de ta réponse.
Cependant, sur IPCOP le fichier rc.inet1 n'existe pas, de même que Rc.inet2 etc.
Je tiens également à préciser que je ne pratique pas Linux au quotidien et que tous mes clients fonctionnent sous Windows.
J'ai remarqué également que lorsque la route est entrée manuellement, depuis IPCOP le ping 172.18.0.1 (qui est un serveur de l'autre réseau) répond bien mais depuis un poste client, il est écrit "Impossible de joindre l'hôte de destination.
Je continue de chercher, mais toute aide est la bienvenue...
Bien cordialement,
Revan.
Cependant, sur IPCOP le fichier rc.inet1 n'existe pas, de même que Rc.inet2 etc.
Je tiens également à préciser que je ne pratique pas Linux au quotidien et que tous mes clients fonctionnent sous Windows.
J'ai remarqué également que lorsque la route est entrée manuellement, depuis IPCOP le ping 172.18.0.1 (qui est un serveur de l'autre réseau) répond bien mais depuis un poste client, il est écrit "Impossible de joindre l'hôte de destination.
Je continue de chercher, mais toute aide est la bienvenue...
Bien cordialement,
Revan.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Même si en soit c'est sans doute correct de configurer ta route statique dans ce fichier, à mon avis il y a un fichier de configuration dédié quelque part qui est fait pour. Par exemple sous debian c'est /etc/network/interfaces, pour redhat c'est quelque part dans /etc/sysconfig etc...
D'après ce qui est ici ce serait sous slackware dans /etc/rc.d/rc.inet* :
http://www.slackware.com/config/network.php
Dans ton cas c'est bien entendu la variable GATEWAY qu'il faut configurer à 172.16.1.1.
Ensuite par rapport à ton erreur ping, il faut nous reporter ta table de routage et la commande ping que tu lances :
Dans ton cas je pense que tu as juste deux routes :
- une pour 172.16.0.0 / 255.255.0.0
- et la route par défaut (via ta passerelle 172.16.1.1).
A priori il n'y a pas de raison de créer une route pour 172.18.0.0/16 puisque ce préfixe sera routé avec la route par défaut via ta gateway.
Bonne chance
D'après ce qui est ici ce serait sous slackware dans /etc/rc.d/rc.inet* :
http://www.slackware.com/config/network.php
Dans ton cas c'est bien entendu la variable GATEWAY qu'il faut configurer à 172.16.1.1.
Ensuite par rapport à ton erreur ping, il faut nous reporter ta table de routage et la commande ping que tu lances :
/sbin/route -n ping -c2 x.x.x.x
Dans ton cas je pense que tu as juste deux routes :
- une pour 172.16.0.0 / 255.255.0.0
- et la route par défaut (via ta passerelle 172.16.1.1).
A priori il n'y a pas de raison de créer une route pour 172.18.0.0/16 puisque ce préfixe sera routé avec la route par défaut via ta gateway.
Bonne chance