Encore une petite question, mais le problème est différent...
J'ai toujours mon UltraSparc avec ses trois interfaces réseau :
eth0, eth1 et eth2 et ses deux modems speedstream 5200.
eth0 : 192.168.254.1 ----- Modem 192.168.254.254 ----- IP publique 1
eth1 : 192.168.0.128 ----- LAN
eth2 : 192.168.1.1 ----- Modem 192.168.1.254 ----- IP publique 2
Ma table de routage différencie les interfaces de sortie en fonction
des ports utilisés.
Je fait suivre en entrée TCP/IP2:3000 vers 192.168.0.130:3000
Un tcpdump sur eth2 donne quelque chose du genre :
source:xxxxx > 192.168.1.1:3000
ce qui est logique. La translation de port se faisant par mon
routeur, elle n'apparaît pas ici. Or 192.168.0.130 répond et je vois
toujours dans le tcpdump sur eth2 :
192.168.0.130:3000 > source:xxxxx
qui ne passe pas le speedstream. J'ai essayé de jouer avec les
masques réseau sans grand succès. Je pense que le modem filtre
quelque chose, mais même en désactivant totalement le pare-feu et
les protections diverses, pas moyen de faire passer le truc.
J'ai regardé du côté d'iptables pour voir s'il était possible de
truander les adresses IP en sortie au niveau de eth2, mais je n'ai
pas trouvé de règle évidente...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal
Je fait suivre en entrée TCP/IP2:3000 vers 192.168.0.130:3000 Un tcpdump sur eth2 donne quelque chose du genre : source:xxxxx > 192.168.1.1:3000
ce qui est logique. La translation de port se faisant par mon routeur, elle n'apparaît pas ici. Or 192.168.0.130 répond et je vois toujours dans le tcpdump sur eth2 : 192.168.0.130:3000 > source:xxxxx
qui ne passe pas le speedstream. J'ai essayé de jouer avec les masques réseau sans grand succès. Je pense que le modem filtre quelque chose, mais même en désactivant totalement le pare-feu et les protections diverses, pas moyen de faire passer le truc.
De toute façon agir sur le modem-routeur ne marchera pas.
Soit il a l'équivalent de rp_filter=1 et pas de route vers 192.168.0.0/24 (il n'en a normalement pas besoin), et donc il jette le paquet.
Soit il laisse passer le paquet mais il ne peut le reconnaître comme appartenant à la connexion ouverte par le paquet entrant (pas la bonne adresse source) et il ne peut le dé-nater correctement. Ce paquet va être naté+paté en créant une nouvelle connexion sortante et le client distant ne va pas le reconnaître non plus (pas le bon port source). Echec.
Le seul endroit pour résoudre ça est clairement ta passerelle tricéphale. Elle est la seule à pouvoir dé-nater correctement les paquets de réponse du serveur.
Hypothèse : ça pourrait être un effet de bord de la cible ROUTE. As-tu essayé avec l'option --continue ?
-- Boîte à spam :
Je fait suivre en entrée TCP/IP2:3000 vers 192.168.0.130:3000
Un tcpdump sur eth2 donne quelque chose du genre :
source:xxxxx > 192.168.1.1:3000
ce qui est logique. La translation de port se faisant par mon
routeur, elle n'apparaît pas ici. Or 192.168.0.130 répond et je vois
toujours dans le tcpdump sur eth2 :
192.168.0.130:3000 > source:xxxxx
qui ne passe pas le speedstream. J'ai essayé de jouer avec les
masques réseau sans grand succès. Je pense que le modem filtre
quelque chose, mais même en désactivant totalement le pare-feu et
les protections diverses, pas moyen de faire passer le truc.
De toute façon agir sur le modem-routeur ne marchera pas.
Soit il a l'équivalent de rp_filter=1 et pas de route vers
192.168.0.0/24 (il n'en a normalement pas besoin), et donc il jette le
paquet.
Soit il laisse passer le paquet mais il ne peut le reconnaître comme
appartenant à la connexion ouverte par le paquet entrant (pas la bonne
adresse source) et il ne peut le dé-nater correctement. Ce paquet va
être naté+paté en créant une nouvelle connexion sortante et le client
distant ne va pas le reconnaître non plus (pas le bon port source). Echec.
Le seul endroit pour résoudre ça est clairement ta passerelle
tricéphale. Elle est la seule à pouvoir dé-nater correctement les
paquets de réponse du serveur.
Hypothèse : ça pourrait être un effet de bord de la cible ROUTE. As-tu
essayé avec l'option --continue ?
Je fait suivre en entrée TCP/IP2:3000 vers 192.168.0.130:3000 Un tcpdump sur eth2 donne quelque chose du genre : source:xxxxx > 192.168.1.1:3000
ce qui est logique. La translation de port se faisant par mon routeur, elle n'apparaît pas ici. Or 192.168.0.130 répond et je vois toujours dans le tcpdump sur eth2 : 192.168.0.130:3000 > source:xxxxx
qui ne passe pas le speedstream. J'ai essayé de jouer avec les masques réseau sans grand succès. Je pense que le modem filtre quelque chose, mais même en désactivant totalement le pare-feu et les protections diverses, pas moyen de faire passer le truc.
De toute façon agir sur le modem-routeur ne marchera pas.
Soit il a l'équivalent de rp_filter=1 et pas de route vers 192.168.0.0/24 (il n'en a normalement pas besoin), et donc il jette le paquet.
Soit il laisse passer le paquet mais il ne peut le reconnaître comme appartenant à la connexion ouverte par le paquet entrant (pas la bonne adresse source) et il ne peut le dé-nater correctement. Ce paquet va être naté+paté en créant une nouvelle connexion sortante et le client distant ne va pas le reconnaître non plus (pas le bon port source). Echec.
Le seul endroit pour résoudre ça est clairement ta passerelle tricéphale. Elle est la seule à pouvoir dé-nater correctement les paquets de réponse du serveur.
Hypothèse : ça pourrait être un effet de bord de la cible ROUTE. As-tu essayé avec l'option --continue ?
-- Boîte à spam :
JKB
Le 22-02-2005, à propos de Re: Configuration routeur (suite), écrivait dans fr.comp.os.linux.configuration :
Je fait suivre en entrée TCP/IP2:3000 vers 192.168.0.130:3000 Un tcpdump sur eth2 donne quelque chose du genre : source:xxxxx > 192.168.1.1:3000
ce qui est logique. La translation de port se faisant par mon routeur, elle n'apparaît pas ici. Or 192.168.0.130 répond et je vois toujours dans le tcpdump sur eth2 : 192.168.0.130:3000 > source:xxxxx
qui ne passe pas le speedstream. J'ai essayé de jouer avec les masques réseau sans grand succès. Je pense que le modem filtre quelque chose, mais même en désactivant totalement le pare-feu et les protections diverses, pas moyen de faire passer le truc.
De toute façon agir sur le modem-routeur ne marchera pas.
Soit il a l'équivalent de rp_filter=1 et pas de route vers 192.168.0.0/24 (il n'en a normalement pas besoin), et donc il jette le paquet.
Soit il laisse passer le paquet mais il ne peut le reconnaître comme appartenant à la connexion ouverte par le paquet entrant (pas la bonne adresse source) et il ne peut le dé-nater correctement. Ce paquet va être naté+paté en créant une nouvelle connexion sortante et le client distant ne va pas le reconnaître non plus (pas le bon port source). Echec.
Le seul endroit pour résoudre ça est clairement ta passerelle tricéphale. Elle est la seule à pouvoir dé-nater correctement les paquets de réponse du serveur.
Hypothèse : ça pourrait être un effet de bord de la cible ROUTE. As-tu essayé avec l'option --continue ?
Oui, mais je ne comprends pas bien son effet. J'ai essayé --continue avec une règle SNAT pour essayer de faire apparaître les paquets comme venant de 192.168.1.1, mais rien n'y fait.
JKB
Le 22-02-2005, à propos de
Re: Configuration routeur (suite),
Pascal@plouf écrivait dans fr.comp.os.linux.configuration :
Je fait suivre en entrée TCP/IP2:3000 vers 192.168.0.130:3000
Un tcpdump sur eth2 donne quelque chose du genre :
source:xxxxx > 192.168.1.1:3000
ce qui est logique. La translation de port se faisant par mon
routeur, elle n'apparaît pas ici. Or 192.168.0.130 répond et je vois
toujours dans le tcpdump sur eth2 :
192.168.0.130:3000 > source:xxxxx
qui ne passe pas le speedstream. J'ai essayé de jouer avec les
masques réseau sans grand succès. Je pense que le modem filtre
quelque chose, mais même en désactivant totalement le pare-feu et
les protections diverses, pas moyen de faire passer le truc.
De toute façon agir sur le modem-routeur ne marchera pas.
Soit il a l'équivalent de rp_filter=1 et pas de route vers
192.168.0.0/24 (il n'en a normalement pas besoin), et donc il jette le
paquet.
Soit il laisse passer le paquet mais il ne peut le reconnaître comme
appartenant à la connexion ouverte par le paquet entrant (pas la bonne
adresse source) et il ne peut le dé-nater correctement. Ce paquet va
être naté+paté en créant une nouvelle connexion sortante et le client
distant ne va pas le reconnaître non plus (pas le bon port source). Echec.
Le seul endroit pour résoudre ça est clairement ta passerelle
tricéphale. Elle est la seule à pouvoir dé-nater correctement les
paquets de réponse du serveur.
Hypothèse : ça pourrait être un effet de bord de la cible ROUTE. As-tu
essayé avec l'option --continue ?
Oui, mais je ne comprends pas bien son effet. J'ai essayé --continue
avec une règle SNAT pour essayer de faire apparaître les paquets
comme venant de 192.168.1.1, mais rien n'y fait.
Le 22-02-2005, à propos de Re: Configuration routeur (suite), écrivait dans fr.comp.os.linux.configuration :
Je fait suivre en entrée TCP/IP2:3000 vers 192.168.0.130:3000 Un tcpdump sur eth2 donne quelque chose du genre : source:xxxxx > 192.168.1.1:3000
ce qui est logique. La translation de port se faisant par mon routeur, elle n'apparaît pas ici. Or 192.168.0.130 répond et je vois toujours dans le tcpdump sur eth2 : 192.168.0.130:3000 > source:xxxxx
qui ne passe pas le speedstream. J'ai essayé de jouer avec les masques réseau sans grand succès. Je pense que le modem filtre quelque chose, mais même en désactivant totalement le pare-feu et les protections diverses, pas moyen de faire passer le truc.
De toute façon agir sur le modem-routeur ne marchera pas.
Soit il a l'équivalent de rp_filter=1 et pas de route vers 192.168.0.0/24 (il n'en a normalement pas besoin), et donc il jette le paquet.
Soit il laisse passer le paquet mais il ne peut le reconnaître comme appartenant à la connexion ouverte par le paquet entrant (pas la bonne adresse source) et il ne peut le dé-nater correctement. Ce paquet va être naté+paté en créant une nouvelle connexion sortante et le client distant ne va pas le reconnaître non plus (pas le bon port source). Echec.
Le seul endroit pour résoudre ça est clairement ta passerelle tricéphale. Elle est la seule à pouvoir dé-nater correctement les paquets de réponse du serveur.
Hypothèse : ça pourrait être un effet de bord de la cible ROUTE. As-tu essayé avec l'option --continue ?
Oui, mais je ne comprends pas bien son effet. J'ai essayé --continue avec une règle SNAT pour essayer de faire apparaître les paquets comme venant de 192.168.1.1, mais rien n'y fait.
JKB
Pascal
Hypothèse : ça pourrait être un effet de bord de la cible ROUTE. As-tu essayé avec l'option --continue ?
Oui, mais je ne comprends pas bien son effet.
D'après la documentation succinte du patch-o-matic, elle spécifie que le paquet doit continuer à traverser les règles. On peut supposer qu'il ne s'agit que des règles de la table/chaîne où se trouve la règle ROUTE et que les autres tables/chaînes sont de toute façon traversées, mais sans certitude sans avoir testé ou examiné le code source.
J'ai essayé --continue avec une règle SNAT pour essayer de faire apparaître les paquets comme venant de 192.168.1.1, mais rien n'y fait.
Normal concernant la règle SNAT. Toute règle NAT (SNAT, DNAT, MASQUERADE, et NETMAP je suppose) est sans effet sur les paquets retour. Comme ces paquets appartiennent à une connexion déjà établie, les opérations appliquées dans les chaînes de la table nat sont déjà fixées automatiquement comme étant les opérations réciproques de celles qui ont été appliquées au premier paquet aller qui a créé la connexion.
PS : au lieu d'utiliser des options exotiques comme ROUTE, j'essaierais la méthode exposée par TiChou dans l'autre fil qui consiste à utiliser une adresse différente en alias pour le serveur quand on y accède par la connexion "intranet" et router en fonction de l'adresse source (qui au moins marche chez toi).
-- Boîte à spam :
Hypothèse : ça pourrait être un effet de bord de la cible ROUTE. As-tu
essayé avec l'option --continue ?
Oui, mais je ne comprends pas bien son effet.
D'après la documentation succinte du patch-o-matic, elle spécifie que le
paquet doit continuer à traverser les règles. On peut supposer qu'il ne
s'agit que des règles de la table/chaîne où se trouve la règle ROUTE et
que les autres tables/chaînes sont de toute façon traversées, mais sans
certitude sans avoir testé ou examiné le code source.
J'ai essayé --continue
avec une règle SNAT pour essayer de faire apparaître les paquets
comme venant de 192.168.1.1, mais rien n'y fait.
Normal concernant la règle SNAT. Toute règle NAT (SNAT, DNAT,
MASQUERADE, et NETMAP je suppose) est sans effet sur les paquets retour.
Comme ces paquets appartiennent à une connexion déjà établie, les
opérations appliquées dans les chaînes de la table nat sont déjà fixées
automatiquement comme étant les opérations réciproques de celles qui ont
été appliquées au premier paquet aller qui a créé la connexion.
PS : au lieu d'utiliser des options exotiques comme ROUTE, j'essaierais
la méthode exposée par TiChou dans l'autre fil qui consiste à utiliser
une adresse différente en alias pour le serveur quand on y accède par la
connexion "intranet" et router en fonction de l'adresse source (qui au
moins marche chez toi).
Hypothèse : ça pourrait être un effet de bord de la cible ROUTE. As-tu essayé avec l'option --continue ?
Oui, mais je ne comprends pas bien son effet.
D'après la documentation succinte du patch-o-matic, elle spécifie que le paquet doit continuer à traverser les règles. On peut supposer qu'il ne s'agit que des règles de la table/chaîne où se trouve la règle ROUTE et que les autres tables/chaînes sont de toute façon traversées, mais sans certitude sans avoir testé ou examiné le code source.
J'ai essayé --continue avec une règle SNAT pour essayer de faire apparaître les paquets comme venant de 192.168.1.1, mais rien n'y fait.
Normal concernant la règle SNAT. Toute règle NAT (SNAT, DNAT, MASQUERADE, et NETMAP je suppose) est sans effet sur les paquets retour. Comme ces paquets appartiennent à une connexion déjà établie, les opérations appliquées dans les chaînes de la table nat sont déjà fixées automatiquement comme étant les opérations réciproques de celles qui ont été appliquées au premier paquet aller qui a créé la connexion.
PS : au lieu d'utiliser des options exotiques comme ROUTE, j'essaierais la méthode exposée par TiChou dans l'autre fil qui consiste à utiliser une adresse différente en alias pour le serveur quand on y accède par la connexion "intranet" et router en fonction de l'adresse source (qui au moins marche chez toi).
-- Boîte à spam :
JKB
Le 22-02-2005, à propos de Re: Configuration routeur (suite), écrivait dans fr.comp.os.linux.configuration :
Hypothèse : ça pourrait être un effet de bord de la cible ROUTE. As-tu essayé avec l'option --continue ?
Oui, mais je ne comprends pas bien son effet.
D'après la documentation succinte du patch-o-matic, elle spécifie que le paquet doit continuer à traverser les règles. On peut supposer qu'il ne s'agit que des règles de la table/chaîne où se trouve la règle ROUTE et que les autres tables/chaînes sont de toute façon traversées, mais sans certitude sans avoir testé ou examiné le code source.
J'ai essayé --continue avec une règle SNAT pour essayer de faire apparaître les paquets comme venant de 192.168.1.1, mais rien n'y fait.
Normal concernant la règle SNAT. Toute règle NAT (SNAT, DNAT, MASQUERADE, et NETMAP je suppose) est sans effet sur les paquets retour. Comme ces paquets appartiennent à une connexion déjà établie, les opérations appliquées dans les chaînes de la table nat sont déjà fixées automatiquement comme étant les opérations réciproques de celles qui ont été appliquées au premier paquet aller qui a créé la connexion.
On est bien d'accord. Sur la connexion principale, je fais du DNAT sans aucun problème. J'ai par exemple une connexion ssh sur le lien principal qui passe sur mon serveur intranet :
14:05:20.144272 IP 82.101.6.157.54718 > kant.astelys.fr.2200: . ack 1 win 5840 <nop,nop,timestamp 363411194 86825889> 14:05:20.145285 IP kant.*.fr.2200 > 82.101.6.157.54718: P 1:42(41) ack 1 win 5792 <nop,nop,timestamp 86825947 363411194> 14:05:20.204124 IP 82.101.6.157.54718 > kant.*.fr.2200: . ack 42 win 5840
Le NAT fonctionne bien au retour, puisque c'est kant qui semble répondre et non mon serveur intranet.
Question subsidiaire : pourquoi avec la même technique, cela ne fonctionne pas sur le second lien ? Pourquoi est-ce que sur le second lien, c'est l'adresse du serveur intranet qui passe et non l'adresse censée être natée ? L'application intranet est écrite en java. Y aurait-il un bug dans la sdk qui ferait passer le retour comme une nouvelle connexion ?
PS : au lieu d'utiliser des options exotiques comme ROUTE, j'essaierais la méthode exposée par TiChou dans l'autre fil qui consiste à utiliser une adresse différente en alias pour le serveur quand on y accède par la connexion "intranet" et router en fonction de l'adresse source (qui au moins marche chez toi).
C'est bien ce que je fais.
Cordialement,
JKB
Le 22-02-2005, à propos de
Re: Configuration routeur (suite),
Pascal@plouf écrivait dans fr.comp.os.linux.configuration :
Hypothèse : ça pourrait être un effet de bord de la cible ROUTE. As-tu
essayé avec l'option --continue ?
Oui, mais je ne comprends pas bien son effet.
D'après la documentation succinte du patch-o-matic, elle spécifie que le
paquet doit continuer à traverser les règles. On peut supposer qu'il ne
s'agit que des règles de la table/chaîne où se trouve la règle ROUTE et
que les autres tables/chaînes sont de toute façon traversées, mais sans
certitude sans avoir testé ou examiné le code source.
J'ai essayé --continue
avec une règle SNAT pour essayer de faire apparaître les paquets
comme venant de 192.168.1.1, mais rien n'y fait.
Normal concernant la règle SNAT. Toute règle NAT (SNAT, DNAT,
MASQUERADE, et NETMAP je suppose) est sans effet sur les paquets retour.
Comme ces paquets appartiennent à une connexion déjà établie, les
opérations appliquées dans les chaînes de la table nat sont déjà fixées
automatiquement comme étant les opérations réciproques de celles qui ont
été appliquées au premier paquet aller qui a créé la connexion.
On est bien d'accord. Sur la connexion principale, je fais du DNAT
sans aucun problème. J'ai par exemple une connexion ssh sur le lien
principal qui passe sur mon serveur intranet :
14:05:20.144272 IP 82.101.6.157.54718 > kant.astelys.fr.2200: . ack 1
win 5840 <nop,nop,timestamp 363411194 86825889>
14:05:20.145285 IP kant.*.fr.2200 > 82.101.6.157.54718: P 1:42(41)
ack 1 win 5792 <nop,nop,timestamp 86825947 363411194>
14:05:20.204124 IP 82.101.6.157.54718 > kant.*.fr.2200: . ack 42
win 5840
Le NAT fonctionne bien au retour, puisque c'est kant qui semble
répondre et non mon serveur intranet.
Question subsidiaire : pourquoi avec la même technique, cela ne
fonctionne pas sur le second lien ? Pourquoi est-ce que sur le
second lien, c'est l'adresse du serveur intranet qui passe et non
l'adresse censée être natée ? L'application intranet est écrite en
java. Y aurait-il un bug dans la sdk qui ferait passer le retour
comme une nouvelle connexion ?
PS : au lieu d'utiliser des options exotiques comme ROUTE, j'essaierais
la méthode exposée par TiChou dans l'autre fil qui consiste à utiliser
une adresse différente en alias pour le serveur quand on y accède par la
connexion "intranet" et router en fonction de l'adresse source (qui au
moins marche chez toi).
Le 22-02-2005, à propos de Re: Configuration routeur (suite), écrivait dans fr.comp.os.linux.configuration :
Hypothèse : ça pourrait être un effet de bord de la cible ROUTE. As-tu essayé avec l'option --continue ?
Oui, mais je ne comprends pas bien son effet.
D'après la documentation succinte du patch-o-matic, elle spécifie que le paquet doit continuer à traverser les règles. On peut supposer qu'il ne s'agit que des règles de la table/chaîne où se trouve la règle ROUTE et que les autres tables/chaînes sont de toute façon traversées, mais sans certitude sans avoir testé ou examiné le code source.
J'ai essayé --continue avec une règle SNAT pour essayer de faire apparaître les paquets comme venant de 192.168.1.1, mais rien n'y fait.
Normal concernant la règle SNAT. Toute règle NAT (SNAT, DNAT, MASQUERADE, et NETMAP je suppose) est sans effet sur les paquets retour. Comme ces paquets appartiennent à une connexion déjà établie, les opérations appliquées dans les chaînes de la table nat sont déjà fixées automatiquement comme étant les opérations réciproques de celles qui ont été appliquées au premier paquet aller qui a créé la connexion.
On est bien d'accord. Sur la connexion principale, je fais du DNAT sans aucun problème. J'ai par exemple une connexion ssh sur le lien principal qui passe sur mon serveur intranet :
14:05:20.144272 IP 82.101.6.157.54718 > kant.astelys.fr.2200: . ack 1 win 5840 <nop,nop,timestamp 363411194 86825889> 14:05:20.145285 IP kant.*.fr.2200 > 82.101.6.157.54718: P 1:42(41) ack 1 win 5792 <nop,nop,timestamp 86825947 363411194> 14:05:20.204124 IP 82.101.6.157.54718 > kant.*.fr.2200: . ack 42 win 5840
Le NAT fonctionne bien au retour, puisque c'est kant qui semble répondre et non mon serveur intranet.
Question subsidiaire : pourquoi avec la même technique, cela ne fonctionne pas sur le second lien ? Pourquoi est-ce que sur le second lien, c'est l'adresse du serveur intranet qui passe et non l'adresse censée être natée ? L'application intranet est écrite en java. Y aurait-il un bug dans la sdk qui ferait passer le retour comme une nouvelle connexion ?
PS : au lieu d'utiliser des options exotiques comme ROUTE, j'essaierais la méthode exposée par TiChou dans l'autre fil qui consiste à utiliser une adresse différente en alias pour le serveur quand on y accède par la connexion "intranet" et router en fonction de l'adresse source (qui au moins marche chez toi).
