Bonjour,
j'ai toujours mon soucis avec iptables, je vais essayer de m'expliquer
clairement.
J'ai un pc avec deux cartes réseaux.
Je veux que tout les packets qui entrent sur le PC à destination du port
80 de n'importe quel ordinateur excepté ceux venant de l'adresse IP
192.168.1.2 soient redirigés vers le port 3128 de 192.168.1.2.
Je pensais que cette ligne:
iptables -A PREROUTING -t nat -p tcp -s ! 192.168.1.2 --dport 80 -j DNAT\
--to 192.168.1.2:3128
ferait l'affaire, mais seul les packets venant de eth0 arrivent
réellement sur 192.168.1.2, en effet j'ai fait tourner un serveur bidon
qui affiche ce qu'il reçoit sur le port 3128 sur la sortie et quand je
lance une connexion d'une machine connectée à eth0, le contenu est
affiché, par contre, quand je lance une connexion depuis une machine
connectée à eth1, rien n'arrive sur le port 3128 de 192.168.1.2.
Je précise que 192.168.1.2 est connecté à eth1, où se trouve ma
coquille?
D'ailleurs est ce que ce que je veux faire est possible ou devrais je
installer une troisème carte réseau?
Le Wed, 28 Jul 2004 21:10:30 +0200, Gaëtan Duchaussois a écrit :
Je précise que 192.168.1.2 est connecté à eth1, où se trouve ma coquille?
Tout simplement que les machines connectées sur eth1 connaissent parfaitement 192.168.1.2 et n ont pas besoin de passer par ta passerelle...
Tu devrais penser ta structure et/ou parametres de reseau autrement ...
Kal
Gaëtan Duchaussois
le Wed, 28 Jul 2004 21:24:38 +0200, Kalimhero a ressenti le besoin de nous dire:
Le Wed, 28 Jul 2004 21:10:30 +0200, Gaëtan Duchaussois a écrit :
Je précise que 192.168.1.2 est connecté à eth1, où se trouve ma coquille?
Tout simplement que les machines connectées sur eth1 connaissent parfaitement 192.168.1.2 et n ont pas besoin de passer par ta passerelle...
je comprends pas bien là, la machine elle veut accéder à par exemple google.fr, elle passe par la passerelle, là le paquet est renvoyé à 192.168.1.2:3128 non?
Tu devrais penser ta structure et/ou parametres de reseau autrement ...
Si j'ajoute sur mes postes une ligne à la table de routage du style route add 192.168.1.2 gw 192.168.1.1, ça peut pas passer? vu que je dois avoir des cartes réseau qui traine, je vai mettre une eth2 si j'ai pas de choix soft.
Merci
-- Gaëtan
le Wed, 28 Jul 2004 21:24:38 +0200, Kalimhero a ressenti le besoin de nous dire:
Le Wed, 28 Jul 2004 21:10:30 +0200, Gaëtan Duchaussois a écrit :
Je précise que 192.168.1.2 est connecté à eth1, où se trouve ma
coquille?
Tout simplement que les machines connectées sur eth1 connaissent
parfaitement 192.168.1.2 et n ont pas besoin de passer par ta passerelle...
je comprends pas bien là, la machine elle veut accéder à par exemple
google.fr, elle passe par la passerelle, là le paquet est renvoyé à
192.168.1.2:3128
non?
Tu devrais penser ta structure et/ou parametres de reseau autrement ...
Si j'ajoute sur mes postes une ligne à la table de routage du style
route add 192.168.1.2 gw 192.168.1.1, ça peut pas passer?
vu que je dois avoir des cartes réseau qui traine, je vai mettre une
eth2 si j'ai pas de choix soft.
le Wed, 28 Jul 2004 21:24:38 +0200, Kalimhero a ressenti le besoin de nous dire:
Le Wed, 28 Jul 2004 21:10:30 +0200, Gaëtan Duchaussois a écrit :
Je précise que 192.168.1.2 est connecté à eth1, où se trouve ma coquille?
Tout simplement que les machines connectées sur eth1 connaissent parfaitement 192.168.1.2 et n ont pas besoin de passer par ta passerelle...
je comprends pas bien là, la machine elle veut accéder à par exemple google.fr, elle passe par la passerelle, là le paquet est renvoyé à 192.168.1.2:3128 non?
Tu devrais penser ta structure et/ou parametres de reseau autrement ...
Si j'ajoute sur mes postes une ligne à la table de routage du style route add 192.168.1.2 gw 192.168.1.1, ça peut pas passer? vu que je dois avoir des cartes réseau qui traine, je vai mettre une eth2 si j'ai pas de choix soft.
Merci
-- Gaëtan
Kalimhero
Le Wed, 28 Jul 2004 23:22:48 +0200, Gaëtan Duchaussois a écrit :
je comprends pas bien là, la machine elle veut accéder à par exemple google.fr, elle passe par la passerelle, là le paquet est renvoyé à 192.168.1.2:3128 non?
Euh, si ... j avais mal lu, désolé !
Pourrais tu donner les règles de ta conf iptables ?
Kal
Le Wed, 28 Jul 2004 23:22:48 +0200, Gaëtan Duchaussois a écrit :
je comprends pas bien là, la machine elle veut accéder à par exemple
google.fr, elle passe par la passerelle, là le paquet est renvoyé à
192.168.1.2:3128
non?
Euh, si ... j avais mal lu, désolé !
Pourrais tu donner les règles de ta conf iptables ?
Le Wed, 28 Jul 2004 23:22:48 +0200, Gaëtan Duchaussois a écrit :
je comprends pas bien là, la machine elle veut accéder à par exemple google.fr, elle passe par la passerelle, là le paquet est renvoyé à 192.168.1.2:3128 non?
Euh, si ... j avais mal lu, désolé !
Pourrais tu donner les règles de ta conf iptables ?
Kal
Gaëtan Duchaussois
le Thu, 29 Jul 2004 10:40:27 +0200, Kalimhero a ressenti le besoin de nous dire:
Le Wed, 28 Jul 2004 23:22:48 +0200, Gaëtan Duchaussois a écrit :
je comprends pas bien là, la machine elle veut accéder à par exemple google.fr, elle passe par la passerelle, là le paquet est renvoyé à 192.168.1.2:3128 non?
Euh, si ... j avais mal lu, désolé !
pas de mal
Pourrais tu donner les règles de ta conf iptables ?
#Renvoyer les requêtes web vars le proxy iptables -A PREROUTING -t nat -p tcp -s ! 192.168.1.2 --dport 80 -j DNAT --to 192.168.1.2:3128
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils viennet de eth1, sans doute un problème de collision.
-- Gaëtan
le Thu, 29 Jul 2004 10:40:27 +0200, Kalimhero a ressenti le besoin de nous dire:
Le Wed, 28 Jul 2004 23:22:48 +0200, Gaëtan Duchaussois a écrit :
je comprends pas bien là, la machine elle veut accéder à par exemple
google.fr, elle passe par la passerelle, là le paquet est renvoyé à
192.168.1.2:3128
non?
Euh, si ... j avais mal lu, désolé !
pas de mal
Pourrais tu donner les règles de ta conf iptables ?
le Thu, 29 Jul 2004 10:40:27 +0200, Kalimhero a ressenti le besoin de nous dire:
Le Wed, 28 Jul 2004 23:22:48 +0200, Gaëtan Duchaussois a écrit :
je comprends pas bien là, la machine elle veut accéder à par exemple google.fr, elle passe par la passerelle, là le paquet est renvoyé à 192.168.1.2:3128 non?
Euh, si ... j avais mal lu, désolé !
pas de mal
Pourrais tu donner les règles de ta conf iptables ?
#Renvoyer les requêtes web vars le proxy iptables -A PREROUTING -t nat -p tcp -s ! 192.168.1.2 --dport 80 -j DNAT --to 192.168.1.2:3128
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils viennet de eth1,
Vous êtes sûr de ça, vous avez instrumenté le trafic ?
sans doute un problème de collision.
Aucun rapport.
Je pense plutôt que ce sont les paquets renvoyés par le proxy qui ne repassent pas par la passerelle, tout simplement parce que le proxy est dans le même réseau que les clients et a donc naturellement une route de retour directe vers eux. C'est un classique.
Trafic aller : client -> passerelle (DNAT) -> proxy
Trafic retour : proxy -> client sans passer par la case dé-DNAT -> marche pas.
Il faut forcer le proxy a passer par la passerelle pour répondre aux clients. Quelques suggestions :
- En l'isolant des clients dans un réseau distinct, de préférence sur une autre interface de la passerelle. Le mettre dans un sous-réseau IP distinct mais dans le même réseau physique peut s'avérer délicat à gérer à cause des ICMP "redirect" susceptibles d'être émis par la passerelle.
- En faisant de la NAT source (SNAT ou MASQERADE) en sortie de eth1 pour les paquets en question :
#Renvoyer les requêtes web vars le proxy
iptables -A PREROUTING -t nat -p tcp -s ! 192.168.1.2 --dport 80 -j DNAT
--to 192.168.1.2:3128
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils
viennet de eth1,
Vous êtes sûr de ça, vous avez instrumenté le trafic ?
sans doute un problème de collision.
Aucun rapport.
Je pense plutôt que ce sont les paquets renvoyés par le proxy qui ne
repassent pas par la passerelle, tout simplement parce que le proxy est
dans le même réseau que les clients et a donc naturellement une route de
retour directe vers eux. C'est un classique.
Trafic aller :
client -> passerelle (DNAT) -> proxy
Trafic retour :
proxy -> client sans passer par la case dé-DNAT -> marche pas.
Il faut forcer le proxy a passer par la passerelle pour répondre aux
clients. Quelques suggestions :
- En l'isolant des clients dans un réseau distinct, de préférence sur
une autre interface de la passerelle. Le mettre dans un sous-réseau IP
distinct mais dans le même réseau physique peut s'avérer délicat à gérer
à cause des ICMP "redirect" susceptibles d'être émis par la passerelle.
- En faisant de la NAT source (SNAT ou MASQERADE) en sortie de eth1 pour
les paquets en question :
#Renvoyer les requêtes web vars le proxy iptables -A PREROUTING -t nat -p tcp -s ! 192.168.1.2 --dport 80 -j DNAT --to 192.168.1.2:3128
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils viennet de eth1,
Vous êtes sûr de ça, vous avez instrumenté le trafic ?
sans doute un problème de collision.
Aucun rapport.
Je pense plutôt que ce sont les paquets renvoyés par le proxy qui ne repassent pas par la passerelle, tout simplement parce que le proxy est dans le même réseau que les clients et a donc naturellement une route de retour directe vers eux. C'est un classique.
Trafic aller : client -> passerelle (DNAT) -> proxy
Trafic retour : proxy -> client sans passer par la case dé-DNAT -> marche pas.
Il faut forcer le proxy a passer par la passerelle pour répondre aux clients. Quelques suggestions :
- En l'isolant des clients dans un réseau distinct, de préférence sur une autre interface de la passerelle. Le mettre dans un sous-réseau IP distinct mais dans le même réseau physique peut s'avérer délicat à gérer à cause des ICMP "redirect" susceptibles d'être émis par la passerelle.
- En faisant de la NAT source (SNAT ou MASQERADE) en sortie de eth1 pour les paquets en question :
#Renvoyer les requêtes web vars le proxy iptables -A PREROUTING -t nat -p tcp -s ! 192.168.1.2 --dport 80 -j DNAT --to 192.168.1.2:3128
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils viennet de eth1,
Vous êtes sûr de ça, vous avez instrumenté le trafic ?
Je ne sais pas ce que signifie ce terme, mais en fait quand je lance un
serveur bidon sur le port 3128 qui affiche sur la sortie standard ce qu'il reçoit, lorsque je me connecte de eth0, je vois un GET passer et d'autres trucs, mais quand je le fais d'un poste sur eth1 il n'y a rien.
Par contre je viens de penser qu'il y a peut-être un retour avent de lancer le get ce qui rejoindrait votre propos.
sans doute un problème de collision.
Aucun rapport.
c'était une idée merci de ne pas me faire perséverer dans ce chemin.
Je pense plutôt que ce sont les paquets renvoyés par le proxy qui ne repassent pas par la passerelle, tout simplement parce que le proxy est dans le même réseau que les clients et a donc naturellement une route de retour directe vers eux. C'est un classique.
Trafic aller : client -> passerelle (DNAT) -> proxy
Trafic retour : proxy -> client sans passer par la case dé-DNAT -> marche pas.
ok
Il faut forcer le proxy a passer par la passerelle pour répondre aux clients. Quelques suggestions :
- En l'isolant des clients dans un réseau distinct, de préférence sur une autre interface de la passerelle. Le mettre dans un sous-réseau IP distinct mais dans le même réseau physique peut s'avérer délicat à gérer à cause des ICMP "redirect" susceptibles d'être émis par la passerelle.
je risque de trouver facilemùnt une carte réseau, donc allons y pour une troisième.
- En faisant de la NAT source (SNAT ou MASQERADE) en sortie de eth1 pour les paquets en question :
Ainsi le proxy répondra forcément à la passerelle. Inconvénient : les logs du proxy ne contiendront pas l'adresse réelle des clients.
il n'y a pas moyen de changer l'adresse ip en une adresse ip qui ne serait pas d'une même classe, du genre 192.168.2.6 pour 192.168.1.6? Ce serait vachement plus élégant, non? Mais d'après les options de iptables je vois pas, mis à part mettre 253 lignes...
Merci beaucoup.
Je ne peux malheureusement pas essayer avant lundi.
-- Gaëtan
le Thu, 29 Jul 2004 13:47:18 +0200, Annie D. a ressenti le besoin de nous dire:
Gaëtan Duchaussois wrote:
iptables -A FORWARD -j ACCEPT
Aucun filtrage du trafic qui traverse votre passerelle. Vous n'avez pas
peur.
#Renvoyer les requêtes web vars le proxy
iptables -A PREROUTING -t nat -p tcp -s ! 192.168.1.2 --dport 80 -j DNAT
--to 192.168.1.2:3128
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils
viennet de eth1,
Vous êtes sûr de ça, vous avez instrumenté le trafic ?
Je ne sais pas ce que signifie ce terme, mais en fait quand je lance un
serveur bidon sur le port 3128 qui affiche sur la sortie standard ce
qu'il reçoit, lorsque je me connecte de eth0, je vois un GET passer et
d'autres trucs, mais quand je le fais d'un poste sur eth1 il n'y a rien.
Par contre je viens de penser qu'il y a peut-être un retour avent de
lancer le get ce qui rejoindrait votre propos.
sans doute un problème de collision.
Aucun rapport.
c'était une idée merci de ne pas me faire perséverer dans ce chemin.
Je pense plutôt que ce sont les paquets renvoyés par le proxy qui ne
repassent pas par la passerelle, tout simplement parce que le proxy est
dans le même réseau que les clients et a donc naturellement une route de
retour directe vers eux. C'est un classique.
Trafic aller :
client -> passerelle (DNAT) -> proxy
Trafic retour :
proxy -> client sans passer par la case dé-DNAT -> marche pas.
ok
Il faut forcer le proxy a passer par la passerelle pour répondre aux
clients. Quelques suggestions :
- En l'isolant des clients dans un réseau distinct, de préférence sur
une autre interface de la passerelle. Le mettre dans un sous-réseau IP
distinct mais dans le même réseau physique peut s'avérer délicat à gérer
à cause des ICMP "redirect" susceptibles d'être émis par la passerelle.
je risque de trouver facilemùnt une carte réseau, donc allons y pour une
troisième.
- En faisant de la NAT source (SNAT ou MASQERADE) en sortie de eth1 pour
les paquets en question :
Ainsi le proxy répondra forcément à la passerelle. Inconvénient : les
logs du proxy ne contiendront pas l'adresse réelle des clients.
il n'y a pas moyen de changer l'adresse ip en une adresse ip qui ne
serait pas d'une même classe, du genre 192.168.2.6 pour 192.168.1.6?
Ce serait vachement plus élégant, non? Mais d'après les options de
iptables je vois pas, mis à part mettre 253 lignes...
Merci beaucoup.
Je ne peux malheureusement pas essayer avant lundi.
#Renvoyer les requêtes web vars le proxy iptables -A PREROUTING -t nat -p tcp -s ! 192.168.1.2 --dport 80 -j DNAT --to 192.168.1.2:3128
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils viennet de eth1,
Vous êtes sûr de ça, vous avez instrumenté le trafic ?
Je ne sais pas ce que signifie ce terme, mais en fait quand je lance un
serveur bidon sur le port 3128 qui affiche sur la sortie standard ce qu'il reçoit, lorsque je me connecte de eth0, je vois un GET passer et d'autres trucs, mais quand je le fais d'un poste sur eth1 il n'y a rien.
Par contre je viens de penser qu'il y a peut-être un retour avent de lancer le get ce qui rejoindrait votre propos.
sans doute un problème de collision.
Aucun rapport.
c'était une idée merci de ne pas me faire perséverer dans ce chemin.
Je pense plutôt que ce sont les paquets renvoyés par le proxy qui ne repassent pas par la passerelle, tout simplement parce que le proxy est dans le même réseau que les clients et a donc naturellement une route de retour directe vers eux. C'est un classique.
Trafic aller : client -> passerelle (DNAT) -> proxy
Trafic retour : proxy -> client sans passer par la case dé-DNAT -> marche pas.
ok
Il faut forcer le proxy a passer par la passerelle pour répondre aux clients. Quelques suggestions :
- En l'isolant des clients dans un réseau distinct, de préférence sur une autre interface de la passerelle. Le mettre dans un sous-réseau IP distinct mais dans le même réseau physique peut s'avérer délicat à gérer à cause des ICMP "redirect" susceptibles d'être émis par la passerelle.
je risque de trouver facilemùnt une carte réseau, donc allons y pour une troisième.
- En faisant de la NAT source (SNAT ou MASQERADE) en sortie de eth1 pour les paquets en question :
Ainsi le proxy répondra forcément à la passerelle. Inconvénient : les logs du proxy ne contiendront pas l'adresse réelle des clients.
il n'y a pas moyen de changer l'adresse ip en une adresse ip qui ne serait pas d'une même classe, du genre 192.168.2.6 pour 192.168.1.6? Ce serait vachement plus élégant, non? Mais d'après les options de iptables je vois pas, mis à part mettre 253 lignes...
Merci beaucoup.
Je ne peux malheureusement pas essayer avant lundi.
-- Gaëtan
Annie D.
Gaëtan Duchaussois wrote:
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils viennet de eth1,
Vous êtes sûr de ça, vous avez instrumenté le trafic ?
Je ne sais pas ce que signifie ce terme,
Ça signifie que vous avez mis en place quelque chose qui permet de visualiser les paquets qui entrent et sortent par chaque interface : règles iptables avec cible LOG, tcpdump, ethereal... afin de vérifier où ça coince.
mais en fait quand je lance un serveur bidon sur le port 3128 qui affiche sur la sortie standard ce qu'il reçoit, lorsque je me connecte de eth0, je vois un GET passer et d'autres trucs, mais quand je le fais d'un poste sur eth1 il n'y a rien.
Ça, ça ne marche que si la connexion TCP parvient à s'établir, et ça suppose déjà que les paquets circulent correctement dans les deux sens. Vous n'en êtes pas là, il faut commencer par vérifier si 1) le paquet SYN est bien retransmis au proxy et 2) la réponse SYN+ACK du proxy revient bien au client en ayant traversé le routeur.
Il faut forcer le proxy a passer par la passerelle pour répondre aux clients. Quelques suggestions : [...]
- En faisant de la NAT source (SNAT ou MASQERADE) en sortie de eth1 pour les paquets en question :
Ainsi le proxy répondra forcément à la passerelle. Inconvénient : les logs du proxy ne contiendront pas l'adresse réelle des clients.
il n'y a pas moyen de changer l'adresse ip en une adresse ip qui ne serait pas d'une même classe, du genre 192.168.2.6 pour 192.168.1.6?
A la réflexion, vous pouvez mettre n'importe quelle adresse appartenant à une destination de la table de routage du proxy qui passe par la passerelle.
Ce serait vachement plus élégant, non? Mais d'après les options de iptables je vois pas, mis à part mettre 253 lignes...
Que je sache, la cible SNAT standard ne permet pas de faire de la NAT statique 1 vers 1 sur un bloc d'adresses d'un seul coup, et je ne connais pas assez les extensions exotiques de Netfilter pour savoir s'il en existe une qui le fasse. Mais vous pouvez écrire un bout de script qui crée les 253 règles ; je vous conseille toutefois de procéder par un minimum de dichotomie afin de limiter le nombre de règles pouvant être parcourues.
Gaëtan Duchaussois wrote:
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils
viennet de eth1,
Vous êtes sûr de ça, vous avez instrumenté le trafic ?
Je ne sais pas ce que signifie ce terme,
Ça signifie que vous avez mis en place quelque chose qui permet de
visualiser les paquets qui entrent et sortent par chaque interface :
règles iptables avec cible LOG, tcpdump, ethereal... afin de vérifier où
ça coince.
mais en fait quand je lance un
serveur bidon sur le port 3128 qui affiche sur la sortie standard ce
qu'il reçoit, lorsque je me connecte de eth0, je vois un GET passer et
d'autres trucs, mais quand je le fais d'un poste sur eth1 il n'y a rien.
Ça, ça ne marche que si la connexion TCP parvient à s'établir, et ça
suppose déjà que les paquets circulent correctement dans les deux sens.
Vous n'en êtes pas là, il faut commencer par vérifier si 1) le paquet
SYN est bien retransmis au proxy et 2) la réponse SYN+ACK du proxy
revient bien au client en ayant traversé le routeur.
Il faut forcer le proxy a passer par la passerelle pour répondre aux
clients. Quelques suggestions :
[...]
- En faisant de la NAT source (SNAT ou MASQERADE) en sortie de eth1 pour
les paquets en question :
Ainsi le proxy répondra forcément à la passerelle. Inconvénient : les
logs du proxy ne contiendront pas l'adresse réelle des clients.
il n'y a pas moyen de changer l'adresse ip en une adresse ip qui ne
serait pas d'une même classe, du genre 192.168.2.6 pour 192.168.1.6?
A la réflexion, vous pouvez mettre n'importe quelle adresse appartenant
à une destination de la table de routage du proxy qui passe par la
passerelle.
Ce serait vachement plus élégant, non? Mais d'après les options de
iptables je vois pas, mis à part mettre 253 lignes...
Que je sache, la cible SNAT standard ne permet pas de faire de la NAT
statique 1 vers 1 sur un bloc d'adresses d'un seul coup, et je ne
connais pas assez les extensions exotiques de Netfilter pour savoir s'il
en existe une qui le fasse. Mais vous pouvez écrire un bout de script
qui crée les 253 règles ; je vous conseille toutefois de procéder par un
minimum de dichotomie afin de limiter le nombre de règles pouvant être
parcourues.
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils viennet de eth1,
Vous êtes sûr de ça, vous avez instrumenté le trafic ?
Je ne sais pas ce que signifie ce terme,
Ça signifie que vous avez mis en place quelque chose qui permet de visualiser les paquets qui entrent et sortent par chaque interface : règles iptables avec cible LOG, tcpdump, ethereal... afin de vérifier où ça coince.
mais en fait quand je lance un serveur bidon sur le port 3128 qui affiche sur la sortie standard ce qu'il reçoit, lorsque je me connecte de eth0, je vois un GET passer et d'autres trucs, mais quand je le fais d'un poste sur eth1 il n'y a rien.
Ça, ça ne marche que si la connexion TCP parvient à s'établir, et ça suppose déjà que les paquets circulent correctement dans les deux sens. Vous n'en êtes pas là, il faut commencer par vérifier si 1) le paquet SYN est bien retransmis au proxy et 2) la réponse SYN+ACK du proxy revient bien au client en ayant traversé le routeur.
Il faut forcer le proxy a passer par la passerelle pour répondre aux clients. Quelques suggestions : [...]
- En faisant de la NAT source (SNAT ou MASQERADE) en sortie de eth1 pour les paquets en question :
Ainsi le proxy répondra forcément à la passerelle. Inconvénient : les logs du proxy ne contiendront pas l'adresse réelle des clients.
il n'y a pas moyen de changer l'adresse ip en une adresse ip qui ne serait pas d'une même classe, du genre 192.168.2.6 pour 192.168.1.6?
A la réflexion, vous pouvez mettre n'importe quelle adresse appartenant à une destination de la table de routage du proxy qui passe par la passerelle.
Ce serait vachement plus élégant, non? Mais d'après les options de iptables je vois pas, mis à part mettre 253 lignes...
Que je sache, la cible SNAT standard ne permet pas de faire de la NAT statique 1 vers 1 sur un bloc d'adresses d'un seul coup, et je ne connais pas assez les extensions exotiques de Netfilter pour savoir s'il en existe une qui le fasse. Mais vous pouvez écrire un bout de script qui crée les 253 règles ; je vous conseille toutefois de procéder par un minimum de dichotomie afin de limiter le nombre de règles pouvant être parcourues.
Annie D.
"Annie D." wrote:
Mais vous pouvez écrire un bout de script qui crée les 253 règles
J'entends bien sûr automatiquement, avec des boucles 'for' ou équivalent.
"Annie D." wrote:
Mais vous pouvez écrire un bout de script qui crée les 253 règles
J'entends bien sûr automatiquement, avec des boucles 'for' ou
équivalent.
Mais vous pouvez écrire un bout de script qui crée les 253 règles
J'entends bien sûr automatiquement, avec des boucles 'for' ou équivalent.
Gaëtan Duchaussois
le Sat, 31 Jul 2004 00:13:03 +0200, Annie D. a ressenti le besoin de nous dire:
"Annie D." wrote:
Mais vous pouvez écrire un bout de script qui crée les 253 règles
J'entends bien sûr automatiquement, avec des boucles 'for' ou équivalent.
J'avais pensé aussi à cette solution, mais j'avais peur d'alourdir le système. J'ai pas bien compris l'idée de la dichotomie dans ce cas.
Je pensais faire un script du style pour i entre 3 et 253 faire iptables ... fin du pour mais vous pensiez peut-être à quelque chose de bien plus subtil. -- Gaëtan
le Sat, 31 Jul 2004 00:13:03 +0200, Annie D. a ressenti le besoin de nous dire:
"Annie D." wrote:
Mais vous pouvez écrire un bout de script qui crée les 253 règles
J'entends bien sûr automatiquement, avec des boucles 'for' ou
équivalent.
J'avais pensé aussi à cette solution, mais j'avais peur d'alourdir le
système. J'ai pas bien compris l'idée de la dichotomie dans ce cas.
Je pensais faire un script du style
pour i entre 3 et 253 faire
iptables ...
fin du pour
mais vous pensiez peut-être à quelque chose de bien plus subtil.
--
Gaëtan
le Sat, 31 Jul 2004 00:13:03 +0200, Annie D. a ressenti le besoin de nous dire:
"Annie D." wrote:
Mais vous pouvez écrire un bout de script qui crée les 253 règles
J'entends bien sûr automatiquement, avec des boucles 'for' ou équivalent.
J'avais pensé aussi à cette solution, mais j'avais peur d'alourdir le système. J'ai pas bien compris l'idée de la dichotomie dans ce cas.
Je pensais faire un script du style pour i entre 3 et 253 faire iptables ... fin du pour mais vous pensiez peut-être à quelque chose de bien plus subtil. -- Gaëtan
Gaëtan Duchaussois
le Sat, 31 Jul 2004 00:09:53 +0200, Annie D. a ressenti le besoin de nous dire:
Gaëtan Duchaussois wrote:
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils viennet de eth1,
Vous êtes sûr de ça, vous avez instrumenté le trafic ?
Je ne sais pas ce que signifie ce terme,
Ça signifie que vous avez mis en place quelque chose qui permet de visualiser les paquets qui entrent et sortent par chaque interface : règles iptables avec cible LOG, tcpdump, ethereal... afin de vérifier où ça coince.
J'avais fait des tests avec ethereal, mais je n'avais pas pensé à ce cas et il ne 'était pas apparu, mais j'avais pas bien fait attention, ne comprenant pas tout à ce que j'avais vu.
mais en fait quand je lance un serveur bidon sur le port 3128 qui affiche sur la sortie standard ce qu'il reçoit, lorsque je me connecte de eth0, je vois un GET passer et d'autres trucs, mais quand je le fais d'un poste sur eth1 il n'y a rien.
Ça, ça ne marche que si la connexion TCP parvient à s'établir, et ça suppose déjà que les paquets circulent correctement dans les deux sens. Vous n'en êtes pas là, il faut commencer par vérifier si 1) le paquet SYN est bien retransmis au proxy et 2) la réponse SYN+ACK du proxy revient bien au client en ayant traversé le routeur.
Si je comprends bien, le client envoie un paquet SYN et le procy répond SYN+ACK de mémoire, je voyais bien le paquete syn arrivé, mais j'avais pas tilté qu'il devait repartir quelque chose.
Si quelqu'un a le titre d'un bon bouquin sur le sujet de TCP/IP, je susi preneur du tiitre, je devrais réussir à me le faire offrir.
il n'y a pas moyen de changer l'adresse ip en une adresse ip qui ne serait pas d'une même classe, du genre 192.168.2.6 pour 192.168.1.6?
A la réflexion, vous pouvez mettre n'importe quelle adresse appartenant à une destination de la table de routage du proxy qui passe par la passerelle.
C'est ce que j'avais compris.
Ce serait vachement plus élégant, non? Mais d'après les options de iptables je vois pas, mis à part mettre 253 lignes...
Que je sache, la cible SNAT standard ne permet pas de faire de la NAT statique 1 vers 1 sur un bloc d'adresses d'un seul coup, et je ne connais pas assez les extensions exotiques de Netfilter pour savoir s'il
Je vais regarder à titre de curiosité, mais je préfererais un truc standard.
Merci beaucoup -- Gaëtan
le Sat, 31 Jul 2004 00:09:53 +0200, Annie D. a ressenti le besoin de nous dire:
Gaëtan Duchaussois wrote:
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils
viennet de eth1,
Vous êtes sûr de ça, vous avez instrumenté le trafic ?
Je ne sais pas ce que signifie ce terme,
Ça signifie que vous avez mis en place quelque chose qui permet de
visualiser les paquets qui entrent et sortent par chaque interface :
règles iptables avec cible LOG, tcpdump, ethereal... afin de vérifier où
ça coince.
J'avais fait des tests avec ethereal, mais je n'avais pas pensé à ce cas
et il ne 'était pas apparu, mais j'avais pas bien fait attention, ne
comprenant pas tout à ce que j'avais vu.
mais en fait quand je lance un
serveur bidon sur le port 3128 qui affiche sur la sortie standard ce
qu'il reçoit, lorsque je me connecte de eth0, je vois un GET passer et
d'autres trucs, mais quand je le fais d'un poste sur eth1 il n'y a rien.
Ça, ça ne marche que si la connexion TCP parvient à s'établir, et ça
suppose déjà que les paquets circulent correctement dans les deux sens.
Vous n'en êtes pas là, il faut commencer par vérifier si 1) le paquet
SYN est bien retransmis au proxy et 2) la réponse SYN+ACK du proxy
revient bien au client en ayant traversé le routeur.
Si je comprends bien, le client envoie un paquet SYN et le procy répond
SYN+ACK de mémoire, je voyais bien le paquete syn arrivé, mais j'avais
pas tilté qu'il devait repartir quelque chose.
Si quelqu'un a le titre d'un bon bouquin sur le sujet de TCP/IP, je susi
preneur du tiitre, je devrais réussir à me le faire offrir.
il n'y a pas moyen de changer l'adresse ip en une adresse ip qui ne
serait pas d'une même classe, du genre 192.168.2.6 pour 192.168.1.6?
A la réflexion, vous pouvez mettre n'importe quelle adresse appartenant
à une destination de la table de routage du proxy qui passe par la
passerelle.
C'est ce que j'avais compris.
Ce serait vachement plus élégant, non? Mais d'après les options de
iptables je vois pas, mis à part mettre 253 lignes...
Que je sache, la cible SNAT standard ne permet pas de faire de la NAT
statique 1 vers 1 sur un bloc d'adresses d'un seul coup, et je ne
connais pas assez les extensions exotiques de Netfilter pour savoir s'il
Je vais regarder à titre de curiosité, mais je préfererais un truc
standard.
le Sat, 31 Jul 2004 00:09:53 +0200, Annie D. a ressenti le besoin de nous dire:
Gaëtan Duchaussois wrote:
le problème est que les paquets ne vont jamais cers 192.168.1.2 s'ils viennet de eth1,
Vous êtes sûr de ça, vous avez instrumenté le trafic ?
Je ne sais pas ce que signifie ce terme,
Ça signifie que vous avez mis en place quelque chose qui permet de visualiser les paquets qui entrent et sortent par chaque interface : règles iptables avec cible LOG, tcpdump, ethereal... afin de vérifier où ça coince.
J'avais fait des tests avec ethereal, mais je n'avais pas pensé à ce cas et il ne 'était pas apparu, mais j'avais pas bien fait attention, ne comprenant pas tout à ce que j'avais vu.
mais en fait quand je lance un serveur bidon sur le port 3128 qui affiche sur la sortie standard ce qu'il reçoit, lorsque je me connecte de eth0, je vois un GET passer et d'autres trucs, mais quand je le fais d'un poste sur eth1 il n'y a rien.
Ça, ça ne marche que si la connexion TCP parvient à s'établir, et ça suppose déjà que les paquets circulent correctement dans les deux sens. Vous n'en êtes pas là, il faut commencer par vérifier si 1) le paquet SYN est bien retransmis au proxy et 2) la réponse SYN+ACK du proxy revient bien au client en ayant traversé le routeur.
Si je comprends bien, le client envoie un paquet SYN et le procy répond SYN+ACK de mémoire, je voyais bien le paquete syn arrivé, mais j'avais pas tilté qu'il devait repartir quelque chose.
Si quelqu'un a le titre d'un bon bouquin sur le sujet de TCP/IP, je susi preneur du tiitre, je devrais réussir à me le faire offrir.
il n'y a pas moyen de changer l'adresse ip en une adresse ip qui ne serait pas d'une même classe, du genre 192.168.2.6 pour 192.168.1.6?
A la réflexion, vous pouvez mettre n'importe quelle adresse appartenant à une destination de la table de routage du proxy qui passe par la passerelle.
C'est ce que j'avais compris.
Ce serait vachement plus élégant, non? Mais d'après les options de iptables je vois pas, mis à part mettre 253 lignes...
Que je sache, la cible SNAT standard ne permet pas de faire de la NAT statique 1 vers 1 sur un bloc d'adresses d'un seul coup, et je ne connais pas assez les extensions exotiques de Netfilter pour savoir s'il
Je vais regarder à titre de curiosité, mais je préfererais un truc standard.
