Bonsoir,
j'aimerais connaître comment modifier le routage au
niveau du noyau dans un cas bien précis:
j'ai un SEUL ordinateur muni de deux cartes réseaux
(chacune a sa propre ligne d'interruption).
Chacune des deux cartes réseaux appartient au même
réseau.
Par exemple:
eth1 192.168.1.1 255.255.255.0
eth2 192.168.1.2 255.255.255.0
Je les relie par un RJ45.
Je souhaite envoyer un paquet d'une interface a une
autre.
Pour palier à cela, j'utilise la commande suivante:
route add 192.168.1.1 dev eth2
Cela précise au noyau, aussi loin que je comprenne,
d'envoyer tous les paquets, dont la destination est
192.168.1.1, en utilisant l'interface eth2.
Malheureusement, une capture avec tcpdump me prouve
une fois encore que le paquet n'est pas réellement
émis (couche physique)
Supprimer aussi les routes crées automatiquement lors
du démarrage des interfaces
(192.168.1.0 0.0.0.0 255.255.255.0 U
0 0 0 eth1 par ex) ne change rien.
Si quelqu'un a une piste, par avance merci beaucoup!
Bonsoir,
j'aimerais connaître comment modifier le routage au
niveau du noyau dans un cas bien précis:
j'ai un SEUL ordinateur muni de deux cartes réseaux
(chacune a sa propre ligne d'interruption).
Chacune des deux cartes réseaux appartient au même
réseau.
Par exemple:
eth1 192.168.1.1 255.255.255.0
eth2 192.168.1.2 255.255.255.0
Je les relie par un RJ45.
Je souhaite envoyer un paquet d'une interface a une
autre.
Pour palier à cela, j'utilise la commande suivante:
route add 192.168.1.1 dev eth2
Cela précise au noyau, aussi loin que je comprenne,
d'envoyer tous les paquets, dont la destination est
192.168.1.1, en utilisant l'interface eth2.
Malheureusement, une capture avec tcpdump me prouve
une fois encore que le paquet n'est pas réellement
émis (couche physique)
Supprimer aussi les routes crées automatiquement lors
du démarrage des interfaces
(192.168.1.0 0.0.0.0 255.255.255.0 U
0 0 0 eth1 par ex) ne change rien.
Si quelqu'un a une piste, par avance merci beaucoup!
Bonsoir,
j'aimerais connaître comment modifier le routage au
niveau du noyau dans un cas bien précis:
j'ai un SEUL ordinateur muni de deux cartes réseaux
(chacune a sa propre ligne d'interruption).
Chacune des deux cartes réseaux appartient au même
réseau.
Par exemple:
eth1 192.168.1.1 255.255.255.0
eth2 192.168.1.2 255.255.255.0
Je les relie par un RJ45.
Je souhaite envoyer un paquet d'une interface a une
autre.
Pour palier à cela, j'utilise la commande suivante:
route add 192.168.1.1 dev eth2
Cela précise au noyau, aussi loin que je comprenne,
d'envoyer tous les paquets, dont la destination est
192.168.1.1, en utilisant l'interface eth2.
Malheureusement, une capture avec tcpdump me prouve
une fois encore que le paquet n'est pas réellement
émis (couche physique)
Supprimer aussi les routes crées automatiquement lors
du démarrage des interfaces
(192.168.1.0 0.0.0.0 255.255.255.0 U
0 0 0 eth1 par ex) ne change rien.
Si quelqu'un a une piste, par avance merci beaucoup!
Le 13632ième jour après Epoch,
François de Beauregard écrivait:
> Bonsoir,
>
>
> j'aimerais connaître comment modifier le routage au
> niveau du noyau dans un cas bien précis:
>
> j'ai un SEUL ordinateur muni de deux cartes réseaux
> (chacune a sa propre ligne d'interruption).
> Chacune des deux cartes réseaux appartient au même
> réseau.
> Par exemple:
> eth1 192.168.1.1 255.255.255.0
> eth2 192.168.1.2 255.255.255.0
C'est pas forcément la meilleure idée, ça :) ... Si tu veux "jouer"
avec le routage, essaye avec 2 PC, tu pourras explorer tous les cas
possibles.
> Je les relie par un RJ45.
> Je souhaite envoyer un paquet d'une interface a une
> autre.
Ça, ça va être chaud. Même si ils ne sont pas dans le même CIDR tu vas
avoir du mal à faire passer du trafic sur le câble :)
> Pour palier à cela, j'utilise la commande suivante:
> route add 192.168.1.1 dev eth2
> Cela précise au noyau, aussi loin que je comprenne,
> d'envoyer tous les paquets, dont la destination est
> 192.168.1.1, en utilisant l'interface eth2.
> Malheureusement, une capture avec tcpdump me prouve
> une fois encore que le paquet n'est pas réellement
> émis (couche physique)
Tu as bien compris, mais en fait comme l'IP que tu pingues est "dans"
la machine, ben il va pas réveiller qui que ce soit d'autre que
loopback ;)
> Supprimer aussi les routes crées automatiquement lors
> du démarrage des interfaces
> (192.168.1.0 0.0.0.0 255.255.255.0 U
> 0 0 0 eth1 par ex) ne change rien.
man ip
pour faire du routage un peu plus pointu.
> Si quelqu'un a une piste, par avance merci beaucoup!
Eh bien disons que dans ton cas, ça va être assez dur. Tu peux forcer
ping à utiliser une interface particulière (man ping / -I ), mais je
ne suis pas sûr que cela marche correctement pour toi.
Le 13632ième jour après Epoch,
François de Beauregard écrivait:
> Bonsoir,
>
>
> j'aimerais connaître comment modifier le routage au
> niveau du noyau dans un cas bien précis:
>
> j'ai un SEUL ordinateur muni de deux cartes réseaux
> (chacune a sa propre ligne d'interruption).
> Chacune des deux cartes réseaux appartient au même
> réseau.
> Par exemple:
> eth1 192.168.1.1 255.255.255.0
> eth2 192.168.1.2 255.255.255.0
C'est pas forcément la meilleure idée, ça :) ... Si tu veux "jouer"
avec le routage, essaye avec 2 PC, tu pourras explorer tous les cas
possibles.
> Je les relie par un RJ45.
> Je souhaite envoyer un paquet d'une interface a une
> autre.
Ça, ça va être chaud. Même si ils ne sont pas dans le même CIDR tu vas
avoir du mal à faire passer du trafic sur le câble :)
> Pour palier à cela, j'utilise la commande suivante:
> route add 192.168.1.1 dev eth2
> Cela précise au noyau, aussi loin que je comprenne,
> d'envoyer tous les paquets, dont la destination est
> 192.168.1.1, en utilisant l'interface eth2.
> Malheureusement, une capture avec tcpdump me prouve
> une fois encore que le paquet n'est pas réellement
> émis (couche physique)
Tu as bien compris, mais en fait comme l'IP que tu pingues est "dans"
la machine, ben il va pas réveiller qui que ce soit d'autre que
loopback ;)
> Supprimer aussi les routes crées automatiquement lors
> du démarrage des interfaces
> (192.168.1.0 0.0.0.0 255.255.255.0 U
> 0 0 0 eth1 par ex) ne change rien.
man ip
pour faire du routage un peu plus pointu.
> Si quelqu'un a une piste, par avance merci beaucoup!
Eh bien disons que dans ton cas, ça va être assez dur. Tu peux forcer
ping à utiliser une interface particulière (man ping / -I ), mais je
ne suis pas sûr que cela marche correctement pour toi.
Le 13632ième jour après Epoch,
François de Beauregard écrivait:
> Bonsoir,
>
>
> j'aimerais connaître comment modifier le routage au
> niveau du noyau dans un cas bien précis:
>
> j'ai un SEUL ordinateur muni de deux cartes réseaux
> (chacune a sa propre ligne d'interruption).
> Chacune des deux cartes réseaux appartient au même
> réseau.
> Par exemple:
> eth1 192.168.1.1 255.255.255.0
> eth2 192.168.1.2 255.255.255.0
C'est pas forcément la meilleure idée, ça :) ... Si tu veux "jouer"
avec le routage, essaye avec 2 PC, tu pourras explorer tous les cas
possibles.
> Je les relie par un RJ45.
> Je souhaite envoyer un paquet d'une interface a une
> autre.
Ça, ça va être chaud. Même si ils ne sont pas dans le même CIDR tu vas
avoir du mal à faire passer du trafic sur le câble :)
> Pour palier à cela, j'utilise la commande suivante:
> route add 192.168.1.1 dev eth2
> Cela précise au noyau, aussi loin que je comprenne,
> d'envoyer tous les paquets, dont la destination est
> 192.168.1.1, en utilisant l'interface eth2.
> Malheureusement, une capture avec tcpdump me prouve
> une fois encore que le paquet n'est pas réellement
> émis (couche physique)
Tu as bien compris, mais en fait comme l'IP que tu pingues est "dans"
la machine, ben il va pas réveiller qui que ce soit d'autre que
loopback ;)
> Supprimer aussi les routes crées automatiquement lors
> du démarrage des interfaces
> (192.168.1.0 0.0.0.0 255.255.255.0 U
> 0 0 0 eth1 par ex) ne change rien.
man ip
pour faire du routage un peu plus pointu.
> Si quelqu'un a une piste, par avance merci beaucoup!
Eh bien disons que dans ton cas, ça va être assez dur. Tu peux forcer
ping à utiliser une interface particulière (man ping / -I ), mais je
ne suis pas sûr que cela marche correctement pour toi.
j'aimerais connaître comment modifier le routage au
niveau du noyau dans un cas bien précis:
j'ai un SEUL ordinateur muni de deux cartes réseaux
(chacune a sa propre ligne d'interruption).
Chacune des deux cartes réseaux appartient au même
réseau.
Par exemple:
eth1 192.168.1.1 255.255.255.0
eth2 192.168.1.2 255.255.255.0
Je les relie par un RJ45.
Je souhaite envoyer un paquet d'une interface a une
autre.
Si je fais un ping 192.168.1.1, cela revient a
"s'autopinger" l'interface eth1
Pour palier à cela, j'utilise la commande suivante:
route add 192.168.1.1 dev eth2
Cela précise au noyau, aussi loin que je comprenne,
d'envoyer tous les paquets, dont la destination est
192.168.1.1, en utilisant l'interface eth2.
Malheureusement, une capture avec tcpdump me prouve
une fois encore que le paquet n'est pas réellement
émis (couche physique)
Supprimer aussi les routes crées automatiquement lors
du démarrage des interfaces
(192.168.1.0 0.0.0.0 255.255.255.0 U
0 0 0 eth1 par ex) ne change rien.
Je pense que le noyau se rend compte que la route la
plus courte est d'utiliser eth2 pour émettre ce
paquet(l'ip de destination est celle de l'interface).
j'aimerais connaître comment modifier le routage au
niveau du noyau dans un cas bien précis:
j'ai un SEUL ordinateur muni de deux cartes réseaux
(chacune a sa propre ligne d'interruption).
Chacune des deux cartes réseaux appartient au même
réseau.
Par exemple:
eth1 192.168.1.1 255.255.255.0
eth2 192.168.1.2 255.255.255.0
Je les relie par un RJ45.
Je souhaite envoyer un paquet d'une interface a une
autre.
Si je fais un ping 192.168.1.1, cela revient a
"s'autopinger" l'interface eth1
Pour palier à cela, j'utilise la commande suivante:
route add 192.168.1.1 dev eth2
Cela précise au noyau, aussi loin que je comprenne,
d'envoyer tous les paquets, dont la destination est
192.168.1.1, en utilisant l'interface eth2.
Malheureusement, une capture avec tcpdump me prouve
une fois encore que le paquet n'est pas réellement
émis (couche physique)
Supprimer aussi les routes crées automatiquement lors
du démarrage des interfaces
(192.168.1.0 0.0.0.0 255.255.255.0 U
0 0 0 eth1 par ex) ne change rien.
Je pense que le noyau se rend compte que la route la
plus courte est d'utiliser eth2 pour émettre ce
paquet(l'ip de destination est celle de l'interface).
j'aimerais connaître comment modifier le routage au
niveau du noyau dans un cas bien précis:
j'ai un SEUL ordinateur muni de deux cartes réseaux
(chacune a sa propre ligne d'interruption).
Chacune des deux cartes réseaux appartient au même
réseau.
Par exemple:
eth1 192.168.1.1 255.255.255.0
eth2 192.168.1.2 255.255.255.0
Je les relie par un RJ45.
Je souhaite envoyer un paquet d'une interface a une
autre.
Si je fais un ping 192.168.1.1, cela revient a
"s'autopinger" l'interface eth1
Pour palier à cela, j'utilise la commande suivante:
route add 192.168.1.1 dev eth2
Cela précise au noyau, aussi loin que je comprenne,
d'envoyer tous les paquets, dont la destination est
192.168.1.1, en utilisant l'interface eth2.
Malheureusement, une capture avec tcpdump me prouve
une fois encore que le paquet n'est pas réellement
émis (couche physique)
Supprimer aussi les routes crées automatiquement lors
du démarrage des interfaces
(192.168.1.0 0.0.0.0 255.255.255.0 U
0 0 0 eth1 par ex) ne change rien.
Je pense que le noyau se rend compte que la route la
plus courte est d'utiliser eth2 pour émettre ce
paquet(l'ip de destination est celle de l'interface).
Règle : dans Linux, le trafic émis localement à destination de n'importe
quelle adrese locale, ce qui inclut non seulement le bloc 127.0.0.0/8
mais aussi toutes les adresses des autres interfaces de la machine,
passe systématiquement par l'interface de loopback.
Oui, mais elle se heurte à la règle énoncée plus haut, qui a une
priorité supérieure. Cette règle est appliquée par une table de routage
spéciale appelée "local" qu'on peut afficher avec la commande suivante
(du paquet iproute) :
$ ip route list table local
$ ip rule list
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
La première règle indique que la table "local" a la priorité la plus
haute (0). On ne peut ni la modifier ni la supprimer.
Règle : dans Linux, le trafic émis localement à destination de n'importe
quelle adrese locale, ce qui inclut non seulement le bloc 127.0.0.0/8
mais aussi toutes les adresses des autres interfaces de la machine,
passe systématiquement par l'interface de loopback.
Oui, mais elle se heurte à la règle énoncée plus haut, qui a une
priorité supérieure. Cette règle est appliquée par une table de routage
spéciale appelée "local" qu'on peut afficher avec la commande suivante
(du paquet iproute) :
$ ip route list table local
$ ip rule list
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
La première règle indique que la table "local" a la priorité la plus
haute (0). On ne peut ni la modifier ni la supprimer.
Règle : dans Linux, le trafic émis localement à destination de n'importe
quelle adrese locale, ce qui inclut non seulement le bloc 127.0.0.0/8
mais aussi toutes les adresses des autres interfaces de la machine,
passe systématiquement par l'interface de loopback.
Oui, mais elle se heurte à la règle énoncée plus haut, qui a une
priorité supérieure. Cette règle est appliquée par une table de routage
spéciale appelée "local" qu'on peut afficher avec la commande suivante
(du paquet iproute) :
$ ip route list table local
$ ip rule list
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
La première règle indique que la table "local" a la priorité la plus
haute (0). On ne peut ni la modifier ni la supprimer.
Avant tout, et puisque le sujet intéresse visiblement plusieurs
personnes, aurait tu des pointeurs ou des conseils de lecture (mis à
part le source lui même, qui est confus je trouve) sur ce sujet ?
Comme certain pensent apparement que c'est idiot de vouloir relier
directement deux interfaces réseaux,
voici la raison pour laquelle je
voulais faire ça moi aussi : J'ai un module qui analyse le traffic IP
d'un bridge (grace à un hook netfilter). Pour le tester, j'utilise
actuellement 3 machines : un emméteur, un récepteur, et le bridge
modifié entre les deux. Ce n'est pas très commode, surtout pour lancer
des tests automatiques (synchronisations des commandes à lancer entre
les trois machines).
J'avais pensé à lancer le bridge dans qemu, et à
transmettre les paquets grace à deux interfaces réseaux virtuelles
(tun/tap). Il fallait donc que le kernel accepte d'envoyer des paquets
qui étaient destinés à son autre interface via le bridge dans qemu.
Malheuresement je n'y était pas arrivé, mais je vais réessayer en
masqueradant.
Règle : dans Linux, le trafic émis localement à destination de n'importe
quelle adresse locale, ce qui inclut non seulement le bloc 127.0.0.0/8
mais aussi toutes les adresses des autres interfaces de la machine,
passe systématiquement par l'interface de loopback.
Y a t-il une raison à celà, à part simplifier la vie des administrateurs
réseau fainéants ?
Oui, mais elle se heurte à la règle énoncée plus haut, qui a une
priorité supérieure. Cette règle est appliquée par une table de routage
spéciale appelée "local" qu'on peut afficher avec la commande suivante
(du paquet iproute) :
$ ip route list table local
Si on efface cette règle (ip route del ...), on peut alors apparement
(je viens de tester) envoyer sur une interface physique des paquets à
destination de l'interface (à condition de les envoyer depuis une
interface qui à une autre IP source, sinon l'adresse source sera égale à
l'adresse destination et apparement c'est invalide).
N'est-ce pas plus simple d'effacer cette règle que de masquerader les
interfaces ? Y a t-il des contre-indications ?
Chez moi (debian sarge) la table "local" s'appelle apparement table "255".
La première règle indique que la table "local" a la priorité la plus
haute (0). On ne peut ni la modifier ni la supprimer.
Tiens, justement (cf plus haut) j'ai réussi à la modifier...
kernel : 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686 GNU/Linux
Avant tout, et puisque le sujet intéresse visiblement plusieurs
personnes, aurait tu des pointeurs ou des conseils de lecture (mis à
part le source lui même, qui est confus je trouve) sur ce sujet ?
Comme certain pensent apparement que c'est idiot de vouloir relier
directement deux interfaces réseaux,
voici la raison pour laquelle je
voulais faire ça moi aussi : J'ai un module qui analyse le traffic IP
d'un bridge (grace à un hook netfilter). Pour le tester, j'utilise
actuellement 3 machines : un emméteur, un récepteur, et le bridge
modifié entre les deux. Ce n'est pas très commode, surtout pour lancer
des tests automatiques (synchronisations des commandes à lancer entre
les trois machines).
J'avais pensé à lancer le bridge dans qemu, et à
transmettre les paquets grace à deux interfaces réseaux virtuelles
(tun/tap). Il fallait donc que le kernel accepte d'envoyer des paquets
qui étaient destinés à son autre interface via le bridge dans qemu.
Malheuresement je n'y était pas arrivé, mais je vais réessayer en
masqueradant.
Règle : dans Linux, le trafic émis localement à destination de n'importe
quelle adresse locale, ce qui inclut non seulement le bloc 127.0.0.0/8
mais aussi toutes les adresses des autres interfaces de la machine,
passe systématiquement par l'interface de loopback.
Y a t-il une raison à celà, à part simplifier la vie des administrateurs
réseau fainéants ?
Oui, mais elle se heurte à la règle énoncée plus haut, qui a une
priorité supérieure. Cette règle est appliquée par une table de routage
spéciale appelée "local" qu'on peut afficher avec la commande suivante
(du paquet iproute) :
$ ip route list table local
Si on efface cette règle (ip route del ...), on peut alors apparement
(je viens de tester) envoyer sur une interface physique des paquets à
destination de l'interface (à condition de les envoyer depuis une
interface qui à une autre IP source, sinon l'adresse source sera égale à
l'adresse destination et apparement c'est invalide).
N'est-ce pas plus simple d'effacer cette règle que de masquerader les
interfaces ? Y a t-il des contre-indications ?
Chez moi (debian sarge) la table "local" s'appelle apparement table "255".
La première règle indique que la table "local" a la priorité la plus
haute (0). On ne peut ni la modifier ni la supprimer.
Tiens, justement (cf plus haut) j'ai réussi à la modifier...
kernel : 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686 GNU/Linux
Avant tout, et puisque le sujet intéresse visiblement plusieurs
personnes, aurait tu des pointeurs ou des conseils de lecture (mis à
part le source lui même, qui est confus je trouve) sur ce sujet ?
Comme certain pensent apparement que c'est idiot de vouloir relier
directement deux interfaces réseaux,
voici la raison pour laquelle je
voulais faire ça moi aussi : J'ai un module qui analyse le traffic IP
d'un bridge (grace à un hook netfilter). Pour le tester, j'utilise
actuellement 3 machines : un emméteur, un récepteur, et le bridge
modifié entre les deux. Ce n'est pas très commode, surtout pour lancer
des tests automatiques (synchronisations des commandes à lancer entre
les trois machines).
J'avais pensé à lancer le bridge dans qemu, et à
transmettre les paquets grace à deux interfaces réseaux virtuelles
(tun/tap). Il fallait donc que le kernel accepte d'envoyer des paquets
qui étaient destinés à son autre interface via le bridge dans qemu.
Malheuresement je n'y était pas arrivé, mais je vais réessayer en
masqueradant.
Règle : dans Linux, le trafic émis localement à destination de n'importe
quelle adresse locale, ce qui inclut non seulement le bloc 127.0.0.0/8
mais aussi toutes les adresses des autres interfaces de la machine,
passe systématiquement par l'interface de loopback.
Y a t-il une raison à celà, à part simplifier la vie des administrateurs
réseau fainéants ?
Oui, mais elle se heurte à la règle énoncée plus haut, qui a une
priorité supérieure. Cette règle est appliquée par une table de routage
spéciale appelée "local" qu'on peut afficher avec la commande suivante
(du paquet iproute) :
$ ip route list table local
Si on efface cette règle (ip route del ...), on peut alors apparement
(je viens de tester) envoyer sur une interface physique des paquets à
destination de l'interface (à condition de les envoyer depuis une
interface qui à une autre IP source, sinon l'adresse source sera égale à
l'adresse destination et apparement c'est invalide).
N'est-ce pas plus simple d'effacer cette règle que de masquerader les
interfaces ? Y a t-il des contre-indications ?
Chez moi (debian sarge) la table "local" s'appelle apparement table "255".
La première règle indique que la table "local" a la priorité la plus
haute (0). On ne peut ni la modifier ni la supprimer.
Tiens, justement (cf plus haut) j'ai réussi à la modifier...
kernel : 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686 GNU/Linux
Pourquoi pas plutôt deux machines virtuelles pour simuler l'émetteur et
le récepteur, en laissant le pont dans la machine hôte ?
>>$ ip route list table local
>
>Si on efface cette règle (ip route del ...), on peut alors apparement
>(je viens de tester) envoyer sur une interface physique des paquets à
>destination de l'interface (à condition de les envoyer depuis une
>interface qui à une autre IP source, sinon l'adresse source sera égale à
>l'adresse destination et apparement c'est invalide).
Quelle règle ? Tu parles de *règle* de routage (ip rule...) ou de
*route* (ip route...) ?
Si on supprime une route locale, la destination n'est plus considérée
comme locale. C'est valable en sortie mais aussi en entrée : la machine
ne peut plus émettre depuis cette adresse ni recevoir sur cette adresse.
Tu as modifié une règle ou une route ?
Pourquoi pas plutôt deux machines virtuelles pour simuler l'émetteur et
le récepteur, en laissant le pont dans la machine hôte ?
>>$ ip route list table local
>
>Si on efface cette règle (ip route del ...), on peut alors apparement
>(je viens de tester) envoyer sur une interface physique des paquets à
>destination de l'interface (à condition de les envoyer depuis une
>interface qui à une autre IP source, sinon l'adresse source sera égale à
>l'adresse destination et apparement c'est invalide).
Quelle règle ? Tu parles de *règle* de routage (ip rule...) ou de
*route* (ip route...) ?
Si on supprime une route locale, la destination n'est plus considérée
comme locale. C'est valable en sortie mais aussi en entrée : la machine
ne peut plus émettre depuis cette adresse ni recevoir sur cette adresse.
Tu as modifié une règle ou une route ?
Pourquoi pas plutôt deux machines virtuelles pour simuler l'émetteur et
le récepteur, en laissant le pont dans la machine hôte ?
>>$ ip route list table local
>
>Si on efface cette règle (ip route del ...), on peut alors apparement
>(je viens de tester) envoyer sur une interface physique des paquets à
>destination de l'interface (à condition de les envoyer depuis une
>interface qui à une autre IP source, sinon l'adresse source sera égale à
>l'adresse destination et apparement c'est invalide).
Quelle règle ? Tu parles de *règle* de routage (ip rule...) ou de
*route* (ip route...) ?
Si on supprime une route locale, la destination n'est plus considérée
comme locale. C'est valable en sortie mais aussi en entrée : la machine
ne peut plus émettre depuis cette adresse ni recevoir sur cette adresse.
Tu as modifié une règle ou une route ?
Pourquoi pas plutôt deux machines virtuelles pour simuler l'émetteur et
le récepteur, en laissant le pont dans la machine hôte ?
Parceque c'est plus facile de vérifier ce qu'on a reçu en fonction de ce
qu'on a envoyé si c'est la même machine qui envoit et qui reçoit.
Si on efface cette règle (ip route del ...), on peut alors apparement
(je viens de tester) envoyer sur une interface physique des paquets à
destination de l'interface [...]
Quelle règle ? Tu parles de *règle* de routage (ip rule...) ou de
*route* (ip route...) ?
% sudo ip route del 192.168.1.68 dev eth1 table local
Si on supprime une route locale, la destination n'est plus considérée
comme locale. C'est valable en sortie mais aussi en entrée : la machine
ne peut plus émettre depuis cette adresse ni recevoir sur cette adresse.
C'est génant, en effet.
Ce qui me gène aussi, c'est que cette table de "routage" soit consultée
pour vérifier l'adresse source d'un paquet émis, et qu'elle soit
consultée lorsqu'on reçoit un paquet ; alors qu'a priori ça devrait être
l'adresse de l'interface l'information pertinante dans ce cas. Je trouve
ce design suspect.
Pourquoi pas plutôt deux machines virtuelles pour simuler l'émetteur et
le récepteur, en laissant le pont dans la machine hôte ?
Parceque c'est plus facile de vérifier ce qu'on a reçu en fonction de ce
qu'on a envoyé si c'est la même machine qui envoit et qui reçoit.
Si on efface cette règle (ip route del ...), on peut alors apparement
(je viens de tester) envoyer sur une interface physique des paquets à
destination de l'interface [...]
Quelle règle ? Tu parles de *règle* de routage (ip rule...) ou de
*route* (ip route...) ?
% sudo ip route del 192.168.1.68 dev eth1 table local
Si on supprime une route locale, la destination n'est plus considérée
comme locale. C'est valable en sortie mais aussi en entrée : la machine
ne peut plus émettre depuis cette adresse ni recevoir sur cette adresse.
C'est génant, en effet.
Ce qui me gène aussi, c'est que cette table de "routage" soit consultée
pour vérifier l'adresse source d'un paquet émis, et qu'elle soit
consultée lorsqu'on reçoit un paquet ; alors qu'a priori ça devrait être
l'adresse de l'interface l'information pertinante dans ce cas. Je trouve
ce design suspect.
Pourquoi pas plutôt deux machines virtuelles pour simuler l'émetteur et
le récepteur, en laissant le pont dans la machine hôte ?
Parceque c'est plus facile de vérifier ce qu'on a reçu en fonction de ce
qu'on a envoyé si c'est la même machine qui envoit et qui reçoit.
Si on efface cette règle (ip route del ...), on peut alors apparement
(je viens de tester) envoyer sur une interface physique des paquets à
destination de l'interface [...]
Quelle règle ? Tu parles de *règle* de routage (ip rule...) ou de
*route* (ip route...) ?
% sudo ip route del 192.168.1.68 dev eth1 table local
Si on supprime une route locale, la destination n'est plus considérée
comme locale. C'est valable en sortie mais aussi en entrée : la machine
ne peut plus émettre depuis cette adresse ni recevoir sur cette adresse.
C'est génant, en effet.
Ce qui me gène aussi, c'est que cette table de "routage" soit consultée
pour vérifier l'adresse source d'un paquet émis, et qu'elle soit
consultée lorsqu'on reçoit un paquet ; alors qu'a priori ça devrait être
l'adresse de l'interface l'information pertinante dans ce cas. Je trouve
ce design suspect.
Certes. As-tu envisagé l'utilisation d'un générateur de paquets
arbitraires et d'un programme de capture de trafic afin de
court-circuiter la pile IP et ses limitations ?
Certes. As-tu envisagé l'utilisation d'un générateur de paquets
arbitraires et d'un programme de capture de trafic afin de
court-circuiter la pile IP et ses limitations ?
Certes. As-tu envisagé l'utilisation d'un générateur de paquets
arbitraires et d'un programme de capture de trafic afin de
court-circuiter la pile IP et ses limitations ?
Je peux le comprendre. On a d'un côté la configuration IP des interfaces
qui est sans effet opérationnel direct sur les décisions de routage (au
sens large),
Je peux le comprendre. On a d'un côté la configuration IP des interfaces
qui est sans effet opérationnel direct sur les décisions de routage (au
sens large),
Je peux le comprendre. On a d'un côté la configuration IP des interfaces
qui est sans effet opérationnel direct sur les décisions de routage (au
sens large),
Ceci m'amène à me poser la question suivante: dans le cas oà ¹ une
personne dispose de deux connections internet, les paquets "réponses " repassent
ils toujours par la même interface que les paquets "requetes"
correspondants ?
Ceci m'amène à me poser la question suivante: dans le cas oà ¹ une
personne dispose de deux connections internet, les paquets "réponses " repassent
ils toujours par la même interface que les paquets "requetes"
correspondants ?
Ceci m'amène à me poser la question suivante: dans le cas oà ¹ une
personne dispose de deux connections internet, les paquets "réponses " repassent
ils toujours par la même interface que les paquets "requetes"
correspondants ?