Jérémie a écrit :Par contre je viens de penser à une chose : sur le routeur il y a 4
interfaces, dont une que j'ai prise pour établir mon pontage.
Les 3 autres partent dans un switch qui redistribue tout.
Afin que mon pont remplisse sa fonction de pont, je vais bien devoir
déconnecter les trois autres câbles, sinon je ne récupérerai qu'une
partie du traffic ...
A quoi correspondent ces interfaces ? Si elles correspondent à des
sous-réseaux distincts (donc à des VLAN distincts sur le switch), alors
les déconnecter coupera la communication entre ces sous-réseaux et le
routeur.
Jérémie a écrit :
Par contre je viens de penser à une chose : sur le routeur il y a 4
interfaces, dont une que j'ai prise pour établir mon pontage.
Les 3 autres partent dans un switch qui redistribue tout.
Afin que mon pont remplisse sa fonction de pont, je vais bien devoir
déconnecter les trois autres câbles, sinon je ne récupérerai qu'une
partie du traffic ...
A quoi correspondent ces interfaces ? Si elles correspondent à des
sous-réseaux distincts (donc à des VLAN distincts sur le switch), alors
les déconnecter coupera la communication entre ces sous-réseaux et le
routeur.
Jérémie a écrit :Par contre je viens de penser à une chose : sur le routeur il y a 4
interfaces, dont une que j'ai prise pour établir mon pontage.
Les 3 autres partent dans un switch qui redistribue tout.
Afin que mon pont remplisse sa fonction de pont, je vais bien devoir
déconnecter les trois autres câbles, sinon je ne récupérerai qu'une
partie du traffic ...
A quoi correspondent ces interfaces ? Si elles correspondent à des
sous-réseaux distincts (donc à des VLAN distincts sur le switch), alors
les déconnecter coupera la communication entre ces sous-réseaux et le
routeur.
Pascal Hambourg a écrit :Jérémie a écrit :Par contre je viens de penser à une chose : sur le routeur il y a 4
interfaces, dont une que j'ai prise pour établir mon pontage.
Les 3 autres partent dans un switch qui redistribue tout.
Afin que mon pont remplisse sa fonction de pont, je vais bien devoir
déconnecter les trois autres câbles, sinon je ne récupérerai qu'une
partie du traffic ...
A quoi correspondent ces interfaces ? Si elles correspondent à des
sous-réseaux distincts (donc à des VLAN distincts sur le switch),
alors les déconnecter coupera la communication entre ces sous-réseaux
et le routeur.
Non, en fait je n'ai qu'un réseau, sans VLAN (192.168.2.0/24).
En fait, j'ai simplement intercalé le bridge entre le routeur et le
switch, et là, "magie" : un tcpdump soit sur eth0 soit sur eth1 me donne
l'intégralité des paquets réseau !
Je n'ai même pas besoin de déconnecter les autres interfaces, c'est
comme si le bridge récupérait une copie de tous les paquets transitant
sur ce segment (qui est obligatoire pour tous).
Maintenant, je dois juste encore regarder comment faire pour que tcpdump
prenne l'intégralité des paquets sans les tronquer.
Merci encore à vous deux pour votre patience et voter aide !
Jérémie
Pascal Hambourg a écrit :
Jérémie a écrit :
Par contre je viens de penser à une chose : sur le routeur il y a 4
interfaces, dont une que j'ai prise pour établir mon pontage.
Les 3 autres partent dans un switch qui redistribue tout.
Afin que mon pont remplisse sa fonction de pont, je vais bien devoir
déconnecter les trois autres câbles, sinon je ne récupérerai qu'une
partie du traffic ...
A quoi correspondent ces interfaces ? Si elles correspondent à des
sous-réseaux distincts (donc à des VLAN distincts sur le switch),
alors les déconnecter coupera la communication entre ces sous-réseaux
et le routeur.
Non, en fait je n'ai qu'un réseau, sans VLAN (192.168.2.0/24).
En fait, j'ai simplement intercalé le bridge entre le routeur et le
switch, et là, "magie" : un tcpdump soit sur eth0 soit sur eth1 me donne
l'intégralité des paquets réseau !
Je n'ai même pas besoin de déconnecter les autres interfaces, c'est
comme si le bridge récupérait une copie de tous les paquets transitant
sur ce segment (qui est obligatoire pour tous).
Maintenant, je dois juste encore regarder comment faire pour que tcpdump
prenne l'intégralité des paquets sans les tronquer.
Merci encore à vous deux pour votre patience et voter aide !
Jérémie
Pascal Hambourg a écrit :Jérémie a écrit :Par contre je viens de penser à une chose : sur le routeur il y a 4
interfaces, dont une que j'ai prise pour établir mon pontage.
Les 3 autres partent dans un switch qui redistribue tout.
Afin que mon pont remplisse sa fonction de pont, je vais bien devoir
déconnecter les trois autres câbles, sinon je ne récupérerai qu'une
partie du traffic ...
A quoi correspondent ces interfaces ? Si elles correspondent à des
sous-réseaux distincts (donc à des VLAN distincts sur le switch),
alors les déconnecter coupera la communication entre ces sous-réseaux
et le routeur.
Non, en fait je n'ai qu'un réseau, sans VLAN (192.168.2.0/24).
En fait, j'ai simplement intercalé le bridge entre le routeur et le
switch, et là, "magie" : un tcpdump soit sur eth0 soit sur eth1 me donne
l'intégralité des paquets réseau !
Je n'ai même pas besoin de déconnecter les autres interfaces, c'est
comme si le bridge récupérait une copie de tous les paquets transitant
sur ce segment (qui est obligatoire pour tous).
Maintenant, je dois juste encore regarder comment faire pour que tcpdump
prenne l'intégralité des paquets sans les tronquer.
Merci encore à vous deux pour votre patience et voter aide !
Jérémie
Salut,
Jérémie a écrit :
Sur le réseau que j'administre actuellement (192.168.2.0/24), je me
trouve avec une passerelle 192.168.1.254
L'adresse de la passerelle est en-dehors du sous-réseau. Ça marche, ça ?Nous assistons depuis peu à des attaques réseaux que nous n'arrivons
pas bien à déterminer.
Mon idée : mettre en place une seconde passerelle sous forme de
machine linux avec deux cartes réseau :
eth0 <> LAN (dont l'IP sera 192.168.1.254)
eth1 <> Routeur (dont l'IP deviendra 253)
et de donner des règles iptables pour transférer en auto les paquets
de eth0 vers le routeur (eth0 > eth1) afin de pouvoir continuer à
avoir le traffic entrant et sortant mais passant obligatoirement vers
la nouvelle machine, qui pourra scruter le réseau.
Est-ce une bonne idée selon vous ?
Après avoir lu ça je ne peux plus penser, j'ai trop mal au crâne.
Si le but est de pouvoir capturer le trafic entre le routeur et le LAN,
le plus simple serait d'intercaler une machine fonctionnant en pont
transparent (à défaut de pouvoir configurer un port du switch en
mirroring). Ainsi pas besoin de créer un sous-réseau IP distinct ni de
renuméroter des interfaces, de modifier des routes, etc. ou d'avoir
recours à des horreurs du style proxy ARP ou deux interfaces dans le
même sous-réseau.
Salut,
Jérémie a écrit :
Sur le réseau que j'administre actuellement (192.168.2.0/24), je me
trouve avec une passerelle 192.168.1.254
L'adresse de la passerelle est en-dehors du sous-réseau. Ça marche, ça ?
Nous assistons depuis peu à des attaques réseaux que nous n'arrivons
pas bien à déterminer.
Mon idée : mettre en place une seconde passerelle sous forme de
machine linux avec deux cartes réseau :
eth0 <> LAN (dont l'IP sera 192.168.1.254)
eth1 <> Routeur (dont l'IP deviendra 253)
et de donner des règles iptables pour transférer en auto les paquets
de eth0 vers le routeur (eth0 > eth1) afin de pouvoir continuer à
avoir le traffic entrant et sortant mais passant obligatoirement vers
la nouvelle machine, qui pourra scruter le réseau.
Est-ce une bonne idée selon vous ?
Après avoir lu ça je ne peux plus penser, j'ai trop mal au crâne.
Si le but est de pouvoir capturer le trafic entre le routeur et le LAN,
le plus simple serait d'intercaler une machine fonctionnant en pont
transparent (à défaut de pouvoir configurer un port du switch en
mirroring). Ainsi pas besoin de créer un sous-réseau IP distinct ni de
renuméroter des interfaces, de modifier des routes, etc. ou d'avoir
recours à des horreurs du style proxy ARP ou deux interfaces dans le
même sous-réseau.
Salut,
Jérémie a écrit :
Sur le réseau que j'administre actuellement (192.168.2.0/24), je me
trouve avec une passerelle 192.168.1.254
L'adresse de la passerelle est en-dehors du sous-réseau. Ça marche, ça ?Nous assistons depuis peu à des attaques réseaux que nous n'arrivons
pas bien à déterminer.
Mon idée : mettre en place une seconde passerelle sous forme de
machine linux avec deux cartes réseau :
eth0 <> LAN (dont l'IP sera 192.168.1.254)
eth1 <> Routeur (dont l'IP deviendra 253)
et de donner des règles iptables pour transférer en auto les paquets
de eth0 vers le routeur (eth0 > eth1) afin de pouvoir continuer à
avoir le traffic entrant et sortant mais passant obligatoirement vers
la nouvelle machine, qui pourra scruter le réseau.
Est-ce une bonne idée selon vous ?
Après avoir lu ça je ne peux plus penser, j'ai trop mal au crâne.
Si le but est de pouvoir capturer le trafic entre le routeur et le LAN,
le plus simple serait d'intercaler une machine fonctionnant en pont
transparent (à défaut de pouvoir configurer un port du switch en
mirroring). Ainsi pas besoin de créer un sous-réseau IP distinct ni de
renuméroter des interfaces, de modifier des routes, etc. ou d'avoir
recours à des horreurs du style proxy ARP ou deux interfaces dans le
même sous-réseau.
Si ton switch n'est pas administré, il est fort probable que deux des 3
câbles ne servent à rien, sauf si le switch et le routeur savent tous
les deux faire de l'aggrégation automatique de liens, auquel cas tu
triple la bande passante,
mais je doûte que la bande passante de ton
accès soit de plusieurs centaines de Mb/s, donc un seul câble sur une
interface 100Mb/ doit suffire.
Si ton switch n'est pas administré, il est fort probable que deux des 3
câbles ne servent à rien, sauf si le switch et le routeur savent tous
les deux faire de l'aggrégation automatique de liens, auquel cas tu
triple la bande passante,
mais je doûte que la bande passante de ton
accès soit de plusieurs centaines de Mb/s, donc un seul câble sur une
interface 100Mb/ doit suffire.
Si ton switch n'est pas administré, il est fort probable que deux des 3
câbles ne servent à rien, sauf si le switch et le routeur savent tous
les deux faire de l'aggrégation automatique de liens, auquel cas tu
triple la bande passante,
mais je doûte que la bande passante de ton
accès soit de plusieurs centaines de Mb/s, donc un seul câble sur une
interface 100Mb/ doit suffire.
C'est possible, l'agrégation de liens automatique sans configuration
explicite des deux extrémités ?
C'est possible, l'agrégation de liens automatique sans configuration
explicite des deux extrémités ?
C'est possible, l'agrégation de liens automatique sans configuration
explicite des deux extrémités ?
Pascal Hambourg a écrit :C'est possible, l'agrégation de liens automatique sans configuration
explicite des deux extrémités ?
Oui, protocole LACP (qui correspond à 802.3ad).
Pascal Hambourg a écrit :
C'est possible, l'agrégation de liens automatique sans configuration
explicite des deux extrémités ?
Oui, protocole LACP (qui correspond à 802.3ad).
Pascal Hambourg a écrit :C'est possible, l'agrégation de liens automatique sans configuration
explicite des deux extrémités ?
Oui, protocole LACP (qui correspond à 802.3ad).
GuiGui a écrit :Pascal Hambourg a écrit :C'est possible, l'agrégation de liens automatique sans configuration
explicite des deux extrémités ?
Oui, protocole LACP (qui correspond à 802.3ad).
Je me suis peut-être mal fait comprendre. D'après ce que j'ai lu, il
faut que LACP soit activé sur les ports destinés à être agrégés. Est-ce
le cas par défaut sur les équipements qui supportent ce protocole ?
GuiGui a écrit :
Pascal Hambourg a écrit :
C'est possible, l'agrégation de liens automatique sans configuration
explicite des deux extrémités ?
Oui, protocole LACP (qui correspond à 802.3ad).
Je me suis peut-être mal fait comprendre. D'après ce que j'ai lu, il
faut que LACP soit activé sur les ports destinés à être agrégés. Est-ce
le cas par défaut sur les équipements qui supportent ce protocole ?
GuiGui a écrit :Pascal Hambourg a écrit :C'est possible, l'agrégation de liens automatique sans configuration
explicite des deux extrémités ?
Oui, protocole LACP (qui correspond à 802.3ad).
Je me suis peut-être mal fait comprendre. D'après ce que j'ai lu, il
faut que LACP soit activé sur les ports destinés à être agrégés. Est-ce
le cas par défaut sur les équipements qui supportent ce protocole ?
Pascal Hambourg a écrit :GuiGui a écrit :Pascal Hambourg a écrit :C'est possible, l'agrégation de liens automatique sans configuration
explicite des deux extrémités ?
Oui, protocole LACP (qui correspond à 802.3ad).
Je me suis peut-être mal fait comprendre. D'après ce que j'ai lu, il
faut que LACP soit activé sur les ports destinés à être agrégés.
Est-ce le cas par défaut sur les équipements qui supportent ce
protocole ?
Par exemple, on peut lire dans networking/bonding.txt de la
documentation du noyau Linux :
===================================================================== > The 802.3ad mode requires that the switch have the appropriate
ports configured as an 802.3ad aggregation. The precise method used
to configure this varies from switch to switch, but, for example, a
Cisco 3550 series switch requires that the appropriate ports first be
grouped together in a single etherchannel instance, then that
etherchannel is set to mode "lacp" to enable 802.3ad (instead of
standard EtherChannel).
===================================================================== >
Ça me semble assez loin de "sans configuration explicite".
Pascal Hambourg a écrit :
GuiGui a écrit :
Pascal Hambourg a écrit :
C'est possible, l'agrégation de liens automatique sans configuration
explicite des deux extrémités ?
Oui, protocole LACP (qui correspond à 802.3ad).
Je me suis peut-être mal fait comprendre. D'après ce que j'ai lu, il
faut que LACP soit activé sur les ports destinés à être agrégés.
Est-ce le cas par défaut sur les équipements qui supportent ce
protocole ?
Par exemple, on peut lire dans networking/bonding.txt de la
documentation du noyau Linux :
===================================================================== > The 802.3ad mode requires that the switch have the appropriate
ports configured as an 802.3ad aggregation. The precise method used
to configure this varies from switch to switch, but, for example, a
Cisco 3550 series switch requires that the appropriate ports first be
grouped together in a single etherchannel instance, then that
etherchannel is set to mode "lacp" to enable 802.3ad (instead of
standard EtherChannel).
===================================================================== >
Ça me semble assez loin de "sans configuration explicite".
Pascal Hambourg a écrit :GuiGui a écrit :Pascal Hambourg a écrit :C'est possible, l'agrégation de liens automatique sans configuration
explicite des deux extrémités ?
Oui, protocole LACP (qui correspond à 802.3ad).
Je me suis peut-être mal fait comprendre. D'après ce que j'ai lu, il
faut que LACP soit activé sur les ports destinés à être agrégés.
Est-ce le cas par défaut sur les équipements qui supportent ce
protocole ?
Par exemple, on peut lire dans networking/bonding.txt de la
documentation du noyau Linux :
===================================================================== > The 802.3ad mode requires that the switch have the appropriate
ports configured as an 802.3ad aggregation. The precise method used
to configure this varies from switch to switch, but, for example, a
Cisco 3550 series switch requires that the appropriate ports first be
grouped together in a single etherchannel instance, then that
etherchannel is set to mode "lacp" to enable 802.3ad (instead of
standard EtherChannel).
===================================================================== >
Ça me semble assez loin de "sans configuration explicite".
Effectivement, sur mes HP les ports sont en mode LACP "passif" par
défaut.
Il faut les passer manuellement en mode actif (on peut le faire
globalement pour un groupe de ports) pour faire du LACP dynamique.
Par
contre, il me semble que ce qui est décrit ci-dessus c'est du LACP
statique pour lequel il faut configurer manuellement les trunks LACP.
L'avantage de la conf dynamique, c'est qu'on a en plus de l'augmentation
de la BP une redondance (si un lien devient HS, les autres sont toujours
actifs) : c'est fromage et dessert.
Note que dans ce cas, il ne faut pas
activer le spanning-tree sur les ports (inutile que stp coupe les liens
puisqu'on veut les agréger).
Effectivement, sur mes HP les ports sont en mode LACP "passif" par
défaut.
Il faut les passer manuellement en mode actif (on peut le faire
globalement pour un groupe de ports) pour faire du LACP dynamique.
Par
contre, il me semble que ce qui est décrit ci-dessus c'est du LACP
statique pour lequel il faut configurer manuellement les trunks LACP.
L'avantage de la conf dynamique, c'est qu'on a en plus de l'augmentation
de la BP une redondance (si un lien devient HS, les autres sont toujours
actifs) : c'est fromage et dessert.
Note que dans ce cas, il ne faut pas
activer le spanning-tree sur les ports (inutile que stp coupe les liens
puisqu'on veut les agréger).
Effectivement, sur mes HP les ports sont en mode LACP "passif" par
défaut.
Il faut les passer manuellement en mode actif (on peut le faire
globalement pour un groupe de ports) pour faire du LACP dynamique.
Par
contre, il me semble que ce qui est décrit ci-dessus c'est du LACP
statique pour lequel il faut configurer manuellement les trunks LACP.
L'avantage de la conf dynamique, c'est qu'on a en plus de l'augmentation
de la BP une redondance (si un lien devient HS, les autres sont toujours
actifs) : c'est fromage et dessert.
Note que dans ce cas, il ne faut pas
activer le spanning-tree sur les ports (inutile que stp coupe les liens
puisqu'on veut les agréger).
GuiGui a écrit :
Effectivement, sur mes HP les ports sont en mode LACP "passif" par
défaut.
C'est déjà pas mal. Si l'équipement en face a ses ports en LACP actif,
alors l'agrégation devrait se mettre en place automatiquement, non ?
Il faut les passer manuellement en mode actif (on peut le faire
globalement pour un groupe de ports) pour faire du LACP dynamique.
Une question qui me turlupine : avec ce genre de switch on n'aurait pas
besoin de définir a priori quels ports seront agrégés ensemble ? Il
suffit de relier n ports entre les deux, et LACP en fera un seul lien ?
L'avantage de la conf dynamique, c'est qu'on a en plus de
l'augmentation de la BP une redondance (si un lien devient HS, les
autres sont toujours actifs) : c'est fromage et dessert.
En quoi est-ce une exclusivité de la conf dynamique ? LACP permet la
redondance et la répartition de charge même en statique, non ?
Note que dans ce cas, il ne faut pas activer le spanning-tree sur les
ports (inutile que stp coupe les liens puisqu'on veut les agréger).
Je n'y connais rien, mais il me semble que la logique voudrait que du
point de vue du STP les ports agrégés soient considérés comme un seul
lien, donc le problème ne devrait pas se poser.
GuiGui a écrit :
Effectivement, sur mes HP les ports sont en mode LACP "passif" par
défaut.
C'est déjà pas mal. Si l'équipement en face a ses ports en LACP actif,
alors l'agrégation devrait se mettre en place automatiquement, non ?
Il faut les passer manuellement en mode actif (on peut le faire
globalement pour un groupe de ports) pour faire du LACP dynamique.
Une question qui me turlupine : avec ce genre de switch on n'aurait pas
besoin de définir a priori quels ports seront agrégés ensemble ? Il
suffit de relier n ports entre les deux, et LACP en fera un seul lien ?
L'avantage de la conf dynamique, c'est qu'on a en plus de
l'augmentation de la BP une redondance (si un lien devient HS, les
autres sont toujours actifs) : c'est fromage et dessert.
En quoi est-ce une exclusivité de la conf dynamique ? LACP permet la
redondance et la répartition de charge même en statique, non ?
Note que dans ce cas, il ne faut pas activer le spanning-tree sur les
ports (inutile que stp coupe les liens puisqu'on veut les agréger).
Je n'y connais rien, mais il me semble que la logique voudrait que du
point de vue du STP les ports agrégés soient considérés comme un seul
lien, donc le problème ne devrait pas se poser.
GuiGui a écrit :
Effectivement, sur mes HP les ports sont en mode LACP "passif" par
défaut.
C'est déjà pas mal. Si l'équipement en face a ses ports en LACP actif,
alors l'agrégation devrait se mettre en place automatiquement, non ?
Il faut les passer manuellement en mode actif (on peut le faire
globalement pour un groupe de ports) pour faire du LACP dynamique.
Une question qui me turlupine : avec ce genre de switch on n'aurait pas
besoin de définir a priori quels ports seront agrégés ensemble ? Il
suffit de relier n ports entre les deux, et LACP en fera un seul lien ?
L'avantage de la conf dynamique, c'est qu'on a en plus de
l'augmentation de la BP une redondance (si un lien devient HS, les
autres sont toujours actifs) : c'est fromage et dessert.
En quoi est-ce une exclusivité de la conf dynamique ? LACP permet la
redondance et la répartition de charge même en statique, non ?
Note que dans ce cas, il ne faut pas activer le spanning-tree sur les
ports (inutile que stp coupe les liens puisqu'on veut les agréger).
Je n'y connais rien, mais il me semble que la logique voudrait que du
point de vue du STP les ports agrégés soient considérés comme un seul
lien, donc le problème ne devrait pas se poser.