J'ai un problème de connexion entre deux interfaces de mon routeur
etho et eth1.
Mon routeur.
eth0:
192.168.1.1 (hub et un serveur 192.168.1.2 dont gw 192.168.1.1)
eth1:
192.1682.2.1 (hub et deux clients 192.168.2.200-201 dont gw
192.168.2.1)
ppp0: pour le modem et internet.
pas de firwall
iptable -L >> neant.
Problème:
Je ne peux pas pinguer entre serveur et clients (et inversement).
pourtant j'ai bien internet (quand ppp0 actif) aussi bien des clients
que du serveur.
les pings clients clients ou clients routeur passe bien.
les pings serveur routeur passe bien.
je me demande si j ne dois pas établir une route entre les interfaces
eth0 et eth1.?
On Tue, 20 Jul 2004, Rakotomandimby Mihamina wrote:
pas de firwall iptable -L >> neant. [...] pourtant j'ai bien internet (quand ppp0 actif) aussi bien des clients que du serveur.
Les masqueradings ne sont pas affichés par iptables -L. (faut voir avec quelles option tout est affiché)
Je crois qu'il n'y a pas d'autre solution que d'afficher table par table. Donc iptables -t nat -L, iptables -t mangle -L (et -t filter, mais c'est la table par défaut). -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Tue, 20 Jul 2004, Rakotomandimby Mihamina wrote:
pas de firwall
iptable -L >> neant.
[...]
pourtant j'ai bien internet (quand ppp0 actif) aussi bien des clients
que du serveur.
Les masqueradings ne sont pas affichés par iptables -L.
(faut voir avec quelles option tout est affiché)
Je crois qu'il n'y a pas d'autre solution que d'afficher table par table.
Donc iptables -t nat -L, iptables -t mangle -L (et -t filter, mais c'est
la table par défaut).
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
On Tue, 20 Jul 2004, Rakotomandimby Mihamina wrote:
pas de firwall iptable -L >> neant. [...] pourtant j'ai bien internet (quand ppp0 actif) aussi bien des clients que du serveur.
Les masqueradings ne sont pas affichés par iptables -L. (faut voir avec quelles option tout est affiché)
Je crois qu'il n'y a pas d'autre solution que d'afficher table par table. Donc iptables -t nat -L, iptables -t mangle -L (et -t filter, mais c'est la table par défaut). -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
TiChou
Dans le message <news:, *Remi Moyen* tapota sur f.c.o.l.configuration :
On Tue, 20 Jul 2004, Rakotomandimby Mihamina wrote:
pas de firwall iptable -L >> neant. [...] pourtant j'ai bien internet (quand ppp0 actif) aussi bien des clients que du serveur.
Donc un firewall existe.
Les masqueradings ne sont pas affichés par iptables -L.
Mais il y a tout de même les règles de forwarding qui devraient être affichées.
(faut voir avec quelles option tout est affiché)
Je crois qu'il n'y a pas d'autre solution que d'afficher table par table.
Oui, je confirme il n'y en a pas.
Donc iptables -t nat -L, iptables -t mangle -L (et -t filter, mais c'est la table par défaut).
À mon goût, on devrait toujours utiliser la commande 'iptables-save' pour visualiser les règles iptables. Cette commande à l'avantage d'afficher toutes les règles dans toutes les tables.
-- TiChou
Dans le message
<news:Pine.LNX.4.58.0407201331320.5447@pbeanf.raft.vacy-anapl.se>,
*Remi Moyen* tapota sur f.c.o.l.configuration :
On Tue, 20 Jul 2004, Rakotomandimby Mihamina wrote:
pas de firwall
iptable -L >> neant.
[...]
pourtant j'ai bien internet (quand ppp0 actif) aussi bien des clients
que du serveur.
Donc un firewall existe.
Les masqueradings ne sont pas affichés par iptables -L.
Mais il y a tout de même les règles de forwarding qui devraient être
affichées.
(faut voir avec quelles option tout est affiché)
Je crois qu'il n'y a pas d'autre solution que d'afficher table par table.
Oui, je confirme il n'y en a pas.
Donc iptables -t nat -L, iptables -t mangle -L (et -t filter, mais c'est
la table par défaut).
À mon goût, on devrait toujours utiliser la commande 'iptables-save' pour
visualiser les règles iptables. Cette commande à l'avantage d'afficher
toutes les règles dans toutes les tables.
Dans le message <news:, *Remi Moyen* tapota sur f.c.o.l.configuration :
On Tue, 20 Jul 2004, Rakotomandimby Mihamina wrote:
pas de firwall iptable -L >> neant. [...] pourtant j'ai bien internet (quand ppp0 actif) aussi bien des clients que du serveur.
Donc un firewall existe.
Les masqueradings ne sont pas affichés par iptables -L.
Mais il y a tout de même les règles de forwarding qui devraient être affichées.
(faut voir avec quelles option tout est affiché)
Je crois qu'il n'y a pas d'autre solution que d'afficher table par table.
Oui, je confirme il n'y en a pas.
Donc iptables -t nat -L, iptables -t mangle -L (et -t filter, mais c'est la table par défaut).
À mon goût, on devrait toujours utiliser la commande 'iptables-save' pour visualiser les règles iptables. Cette commande à l'avantage d'afficher toutes les règles dans toutes les tables.
-- TiChou
TiChou
Dans le message <news:cdilmu$2k6$, *Rakotomandimby Mihamina* tapota sur f.c.o.l.configuration :
Sinon, "oui" il faut forwarder les interface eth0 et eth1 , amis je sais pas comment.
echo 1 > /proc/sys/net/ipv4/ip_forward
ou si on veut activer le forwarding que sur certaines interfaces, par exemple eth0 et eth1 :
Dans le message <news:, *verlhac* tapota sur f.c.o.l.configuration :
Salut a tous,
Bonjour,
J'ai un problème de connexion entre deux interfaces de mon routeur etho et eth1.
[...]
pas de firwall iptable -L >> neant.
Que donne la sortie de le commande 'iptables-save' ?
Problème:
Je ne peux pas pinguer entre serveur et clients (et inversement). pourtant j'ai bien internet (quand ppp0 actif) aussi bien des clients que du serveur.
les pings clients clients ou clients routeur passe bien. les pings serveur routeur passe bien.
je me demande si j ne dois pas établir une route entre les interfaces eth0 et eth1.?
Non, les routes existent déjà sur votre routeur puisqu'il sait joindre vos deux réseaux.
et si oui comment ?
Vous pouvez toujours vérifier la table de routage avec la commande 'route'.
Si qqun a une idée
Cela peut venir de plusieurs choses. Firewall sur votre routeur, sur les machines clientes, forwarding non activé sur les interfaces du routeur, routes incorrectes sur les machines clientes, etc.
Vérifiez sur le routeur les paramètres noyaux suivant :
Et utilisez les outils traceroute sur vos machines clientes et tcpdump sur le routeur et les machines clientes.
merci beaucoup
De rien.
-- TiChou
Dans le message <news:31ca2a.0407192307.1719e8b7@posting.google.com>,
*verlhac* tapota sur f.c.o.l.configuration :
Salut a tous,
Bonjour,
J'ai un problème de connexion entre deux interfaces de mon routeur
etho et eth1.
[...]
pas de firwall
iptable -L >> neant.
Que donne la sortie de le commande 'iptables-save' ?
Problème:
Je ne peux pas pinguer entre serveur et clients (et inversement).
pourtant j'ai bien internet (quand ppp0 actif) aussi bien des clients
que du serveur.
les pings clients clients ou clients routeur passe bien.
les pings serveur routeur passe bien.
je me demande si j ne dois pas établir une route entre les interfaces
eth0 et eth1.?
Non, les routes existent déjà sur votre routeur puisqu'il sait joindre vos
deux réseaux.
et si oui comment ?
Vous pouvez toujours vérifier la table de routage avec la commande 'route'.
Si qqun a une idée
Cela peut venir de plusieurs choses. Firewall sur votre routeur, sur les
machines clientes, forwarding non activé sur les interfaces du routeur,
routes incorrectes sur les machines clientes, etc.
Vérifiez sur le routeur les paramètres noyaux suivant :
Dans le message <news:, *verlhac* tapota sur f.c.o.l.configuration :
Salut a tous,
Bonjour,
J'ai un problème de connexion entre deux interfaces de mon routeur etho et eth1.
[...]
pas de firwall iptable -L >> neant.
Que donne la sortie de le commande 'iptables-save' ?
Problème:
Je ne peux pas pinguer entre serveur et clients (et inversement). pourtant j'ai bien internet (quand ppp0 actif) aussi bien des clients que du serveur.
les pings clients clients ou clients routeur passe bien. les pings serveur routeur passe bien.
je me demande si j ne dois pas établir une route entre les interfaces eth0 et eth1.?
Non, les routes existent déjà sur votre routeur puisqu'il sait joindre vos deux réseaux.
et si oui comment ?
Vous pouvez toujours vérifier la table de routage avec la commande 'route'.
Si qqun a une idée
Cela peut venir de plusieurs choses. Firewall sur votre routeur, sur les machines clientes, forwarding non activé sur les interfaces du routeur, routes incorrectes sur les machines clientes, etc.
Vérifiez sur le routeur les paramètres noyaux suivant :
Et utilisez les outils traceroute sur vos machines clientes et tcpdump sur le routeur et les machines clientes.
merci beaucoup
De rien.
-- TiChou
jack63
"TiChou" wrote in message news:...
Merci a tous,
Je ne pense pas avoir de firewall sur le routeur (actuellement mais prévu) ni sur les clients, mes routes doivent être correctes sur les machines clientes, mais effectivement je crois que le forwarding n'est pas activé sur les interfaces (eth0 eth1) du routeur.
Sans vouloir trop abuser de vos compétences j'ai une autre question svp:
La carte eth0 de mon serveur samba MDK 9.2 (qui est connecté sur l'interface eth0 du routeur) est en mode "promiscuous", donc si j'ai bien compris elle analyse tout le trafic.
Mais pourquoi ? pour quelle application ? puisque j'ai un intalle MDK 9.2 basique et a priori, je n'ai ni snort, ni iptables, ni autre firwall ou simillaire. Ce serveur est juste prévu comme serveur a très faible trafic ( BIND, SAMBA, POSTFIX, APACHE, et ftp possible). De plus la sécurité est prévu pour être effectué au niveau du routeur (avec iptables, snort, squid).
Le mode promiscuous a il un intéret sur cette interface ? ne faudrait-il pas mieux l'activité sur le routeur (si ce n'est pas déjà fait) ?
Cela peut venir de plusieurs choses. Firewall sur votre routeur, sur les machines clientes, forwarding non activé sur les interfaces du routeur, routes incorrectes sur les machines clientes, etc.
Vérifiez sur le routeur les paramètres noyaux suivant :
Et utilisez les outils traceroute sur vos machines clientes et tcpdump sur le routeur et les machines clientes.
merci beaucoup
De rien.
"TiChou" <gro.uohcit@uohcit> wrote in message news:<gniii.20040720162554@florizarre.tichou.org>...
Merci a tous,
Je ne pense pas avoir de firewall sur le routeur (actuellement mais
prévu) ni sur les clients, mes routes doivent être correctes sur les
machines clientes, mais effectivement je crois que le forwarding n'est
pas activé sur les interfaces (eth0 eth1) du routeur.
Sans vouloir trop abuser de vos compétences j'ai une autre question
svp:
La carte eth0 de mon serveur samba MDK 9.2 (qui est connecté sur
l'interface eth0 du routeur) est en mode "promiscuous", donc si j'ai
bien compris elle analyse tout le trafic.
Mais pourquoi ? pour quelle application ? puisque j'ai un intalle MDK
9.2 basique et a priori, je n'ai ni snort, ni iptables, ni autre
firwall ou simillaire. Ce serveur est juste prévu comme serveur a très
faible trafic ( BIND, SAMBA, POSTFIX, APACHE, et ftp possible).
De plus la sécurité est prévu pour être effectué au niveau du routeur
(avec iptables, snort, squid).
Le mode promiscuous a il un intéret sur cette interface ? ne
faudrait-il pas mieux l'activité sur le routeur (si ce n'est pas déjà
fait) ?
Cela peut venir de plusieurs choses. Firewall sur votre routeur, sur les
machines clientes, forwarding non activé sur les interfaces du routeur,
routes incorrectes sur les machines clientes, etc.
Vérifiez sur le routeur les paramètres noyaux suivant :
Je ne pense pas avoir de firewall sur le routeur (actuellement mais prévu) ni sur les clients, mes routes doivent être correctes sur les machines clientes, mais effectivement je crois que le forwarding n'est pas activé sur les interfaces (eth0 eth1) du routeur.
Sans vouloir trop abuser de vos compétences j'ai une autre question svp:
La carte eth0 de mon serveur samba MDK 9.2 (qui est connecté sur l'interface eth0 du routeur) est en mode "promiscuous", donc si j'ai bien compris elle analyse tout le trafic.
Mais pourquoi ? pour quelle application ? puisque j'ai un intalle MDK 9.2 basique et a priori, je n'ai ni snort, ni iptables, ni autre firwall ou simillaire. Ce serveur est juste prévu comme serveur a très faible trafic ( BIND, SAMBA, POSTFIX, APACHE, et ftp possible). De plus la sécurité est prévu pour être effectué au niveau du routeur (avec iptables, snort, squid).
Le mode promiscuous a il un intéret sur cette interface ? ne faudrait-il pas mieux l'activité sur le routeur (si ce n'est pas déjà fait) ?
Cela peut venir de plusieurs choses. Firewall sur votre routeur, sur les machines clientes, forwarding non activé sur les interfaces du routeur, routes incorrectes sur les machines clientes, etc.
Vérifiez sur le routeur les paramètres noyaux suivant :
Et utilisez les outils traceroute sur vos machines clientes et tcpdump sur le routeur et les machines clientes.
merci beaucoup
De rien.
no_spam
On Wed, 21 Jul 2004 01:50:30 -0700, verlhac wrote:
"TiChou" wrote in message news:...
Merci a tous,
Je ne pense pas avoir de firewall sur le routeur (actuellement mais prévu) ni sur les clients, mes routes doivent être correctes sur les machines clientes, mais effectivement je crois que le forwarding n'est pas activé sur les interfaces (eth0 eth1) du routeur.
Sans vouloir trop abuser de vos compétences j'ai une autre question svp:
La carte eth0 de mon serveur samba MDK 9.2 (qui est connecté sur l'interface eth0 du routeur) est en mode "promiscuous", donc si j'ai bien compris elle analyse tout le trafic.
Puisqu'il n'est pas sur un hub, ça ne change strictement rien, vu que le routeur est censé n'envoyer sur ce brin que ce qui est destiné au serveur.
Mais pourquoi ? pour quelle application ? puisque j'ai un intalle MDK 9.2 basique et a priori, je n'ai ni snort, ni iptables, ni autre firwall ou simillaire.
Il me semble (sous réserve) que le multicast nécessite le mode promiscuous. Si quelqu'un peut confirmer cette piste, il faut voir si le routage multicast n'est pas activé dans le kernel. Si c'est le cas, quoi qu'il en soit, il est inutile.
On Wed, 21 Jul 2004 01:50:30 -0700, verlhac wrote:
"TiChou" <gro.uohcit@uohcit> wrote in message news:<gniii.20040720162554@florizarre.tichou.org>...
Merci a tous,
Je ne pense pas avoir de firewall sur le routeur (actuellement mais
prévu) ni sur les clients, mes routes doivent être correctes sur les
machines clientes, mais effectivement je crois que le forwarding n'est
pas activé sur les interfaces (eth0 eth1) du routeur.
Sans vouloir trop abuser de vos compétences j'ai une autre question
svp:
La carte eth0 de mon serveur samba MDK 9.2 (qui est connecté sur
l'interface eth0 du routeur) est en mode "promiscuous", donc si j'ai
bien compris elle analyse tout le trafic.
Puisqu'il n'est pas sur un hub, ça ne change strictement rien,
vu que le routeur est censé n'envoyer sur ce brin que ce qui est
destiné au serveur.
Mais pourquoi ? pour quelle application ? puisque j'ai un intalle MDK
9.2 basique et a priori, je n'ai ni snort, ni iptables, ni autre
firwall ou simillaire.
Il me semble (sous réserve) que le multicast nécessite le mode
promiscuous. Si quelqu'un peut confirmer cette piste, il faut voir
si le routage multicast n'est pas activé dans le kernel.
Si c'est le cas, quoi qu'il en soit, il est inutile.
On Wed, 21 Jul 2004 01:50:30 -0700, verlhac wrote:
"TiChou" wrote in message news:...
Merci a tous,
Je ne pense pas avoir de firewall sur le routeur (actuellement mais prévu) ni sur les clients, mes routes doivent être correctes sur les machines clientes, mais effectivement je crois que le forwarding n'est pas activé sur les interfaces (eth0 eth1) du routeur.
Sans vouloir trop abuser de vos compétences j'ai une autre question svp:
La carte eth0 de mon serveur samba MDK 9.2 (qui est connecté sur l'interface eth0 du routeur) est en mode "promiscuous", donc si j'ai bien compris elle analyse tout le trafic.
Puisqu'il n'est pas sur un hub, ça ne change strictement rien, vu que le routeur est censé n'envoyer sur ce brin que ce qui est destiné au serveur.
Mais pourquoi ? pour quelle application ? puisque j'ai un intalle MDK 9.2 basique et a priori, je n'ai ni snort, ni iptables, ni autre firwall ou simillaire.
Il me semble (sous réserve) que le multicast nécessite le mode promiscuous. Si quelqu'un peut confirmer cette piste, il faut voir si le routage multicast n'est pas activé dans le kernel. Si c'est le cas, quoi qu'il en soit, il est inutile.
Nicolas George
no_spam wrote in message :
Il me semble (sous réserve) que le multicast nécessite le mode promiscuous.
Ça dépend des cartes réseau et du nombre d'abonnement muticast simultanés. Les paquets en multicast sont envoyés sur une adresse MAC qui reprend une partie de leur adresse multicast, certaines cartes réseau permettent de s'« abonner » à plus ou moins de telles adresses. S'il y a trop d'abonnement simultanés, je suppose que le noyau règle la carte, si elle le supporte, pour laisser passer tous les paquets multicast, et fait le filtrage en soft. Je ne sais pas si toutes les cartes savent faire distinguer le multicast de l'unicase. S'il y en a, alors il faudra effectivement recourir au mode promiscuous complet dans leur cas. Mais ça doit être rare.
Quoi qu'il en soit, on n'a normalement pas à se soucier de ça : le noyau passe lui-même la carte en promiscuous s'il l'estime nécessaire, et comme il la connaît intimement, il est bien informé.
no_spam wrote in message <pan.2004.07.21.11.17.31.816706@magic.fr>:
Il me semble (sous réserve) que le multicast nécessite le mode
promiscuous.
Ça dépend des cartes réseau et du nombre d'abonnement muticast
simultanés. Les paquets en multicast sont envoyés sur une adresse MAC
qui reprend une partie de leur adresse multicast, certaines cartes
réseau permettent de s'« abonner » à plus ou moins de telles adresses.
S'il y a trop d'abonnement simultanés, je suppose que le noyau règle la
carte, si elle le supporte, pour laisser passer tous les paquets
multicast, et fait le filtrage en soft. Je ne sais pas si toutes les
cartes savent faire distinguer le multicast de l'unicase. S'il y en a,
alors il faudra effectivement recourir au mode promiscuous complet dans
leur cas. Mais ça doit être rare.
Quoi qu'il en soit, on n'a normalement pas à se soucier de ça : le noyau
passe lui-même la carte en promiscuous s'il l'estime nécessaire, et
comme il la connaît intimement, il est bien informé.
Il me semble (sous réserve) que le multicast nécessite le mode promiscuous.
Ça dépend des cartes réseau et du nombre d'abonnement muticast simultanés. Les paquets en multicast sont envoyés sur une adresse MAC qui reprend une partie de leur adresse multicast, certaines cartes réseau permettent de s'« abonner » à plus ou moins de telles adresses. S'il y a trop d'abonnement simultanés, je suppose que le noyau règle la carte, si elle le supporte, pour laisser passer tous les paquets multicast, et fait le filtrage en soft. Je ne sais pas si toutes les cartes savent faire distinguer le multicast de l'unicase. S'il y en a, alors il faudra effectivement recourir au mode promiscuous complet dans leur cas. Mais ça doit être rare.
Quoi qu'il en soit, on n'a normalement pas à se soucier de ça : le noyau passe lui-même la carte en promiscuous s'il l'estime nécessaire, et comme il la connaît intimement, il est bien informé.
no_spam
On Wed, 21 Jul 2004 15:44:54 +0000, Nicolas George wrote:
no_spam wrote in message :
Il me semble (sous réserve) que le multicast nécessite le mode promiscuous.
Ça dépend des cartes réseau et du nombre d'abonnement muticast simultanés. Les paquets en multicast sont envoyés sur une adresse MAC qui reprend une partie de leur adresse multicast, certaines cartes réseau permettent de s'« abonner » à plus ou moins de telles adresses. S'il y a trop d'abonnement simultanés, je suppose que le noyau règle la carte, si elle le supporte, pour laisser passer tous les paquets multicast, et fait le filtrage en soft.
Sans doute.
Je ne sais pas si toutes les cartes savent faire distinguer le multicast de l'unicase. S'il y en a, alors il faudra effectivement recourir au mode promiscuous complet dans leur cas. Mais ça doit être rare.
Je ne pense pas qu'il y ait de chip réseau sur le marché actuel qui ne fassent pas de filtrage multicast. Donc, ce que je disais est sans doute faux: pas besoin d'être en mode promiscuous...
Quoi qu'il en soit, on n'a normalement pas à se soucier de ça : le noyau passe lui-même la carte en promiscuous s'il l'estime nécessaire, et comme il la connaît intimement, il est bien informé.
Oui, bien sur.
On Wed, 21 Jul 2004 15:44:54 +0000, Nicolas George wrote:
no_spam wrote in message <pan.2004.07.21.11.17.31.816706@magic.fr>:
Il me semble (sous réserve) que le multicast nécessite le mode
promiscuous.
Ça dépend des cartes réseau et du nombre d'abonnement muticast
simultanés. Les paquets en multicast sont envoyés sur une adresse MAC
qui reprend une partie de leur adresse multicast, certaines cartes
réseau permettent de s'« abonner » à plus ou moins de telles adresses.
S'il y a trop d'abonnement simultanés, je suppose que le noyau règle la
carte, si elle le supporte, pour laisser passer tous les paquets
multicast, et fait le filtrage en soft.
Sans doute.
Je ne sais pas si toutes les
cartes savent faire distinguer le multicast de l'unicase. S'il y en a,
alors il faudra effectivement recourir au mode promiscuous complet dans
leur cas. Mais ça doit être rare.
Je ne pense pas qu'il y ait de chip réseau sur le marché actuel qui
ne fassent pas de filtrage multicast. Donc, ce que je disais est sans
doute faux: pas besoin d'être en mode promiscuous...
Quoi qu'il en soit, on n'a normalement pas à se soucier de ça : le
noyau passe lui-même la carte en promiscuous s'il l'estime nécessaire,
et comme il la connaît intimement, il est bien informé.
On Wed, 21 Jul 2004 15:44:54 +0000, Nicolas George wrote:
no_spam wrote in message :
Il me semble (sous réserve) que le multicast nécessite le mode promiscuous.
Ça dépend des cartes réseau et du nombre d'abonnement muticast simultanés. Les paquets en multicast sont envoyés sur une adresse MAC qui reprend une partie de leur adresse multicast, certaines cartes réseau permettent de s'« abonner » à plus ou moins de telles adresses. S'il y a trop d'abonnement simultanés, je suppose que le noyau règle la carte, si elle le supporte, pour laisser passer tous les paquets multicast, et fait le filtrage en soft.
Sans doute.
Je ne sais pas si toutes les cartes savent faire distinguer le multicast de l'unicase. S'il y en a, alors il faudra effectivement recourir au mode promiscuous complet dans leur cas. Mais ça doit être rare.
Je ne pense pas qu'il y ait de chip réseau sur le marché actuel qui ne fassent pas de filtrage multicast. Donc, ce que je disais est sans doute faux: pas besoin d'être en mode promiscuous...
Quoi qu'il en soit, on n'a normalement pas à se soucier de ça : le noyau passe lui-même la carte en promiscuous s'il l'estime nécessaire, et comme il la connaît intimement, il est bien informé.
