Ma connexion Internet est delivrée par une C-Box qui fait office de
routeur. Je souhaite cependant gerer les fonctions de routage sur un
serveur Linux.
J'ai donc installé un serveur sous Linux (Debian sarge) avec 2 cartes
ethernet (eth1 vers la CBox et eth0 vers le LAN), une branchée
directement sur la CBox et une seconde sur le LAN.
Donc, la CBox recoit elle l'adresse IP publique, j'ai donc defini sa
patte interne en 192.168.30.1 et je lui ai indiqué de rediriger toutes
les requetes sur 192.168.30.3 (qui est l'adresse de eth1 sur le serveur)
Jusque là, tout se passe à peu pret normalement :
Les services tournant sur la carte eth1 du serveur sont bien visible
depuis l'Internet.
Le problème arrive dés que je tente de faire du NAT.
Voici les commandes iptables que je tappe :
# iptables -A INPUT -p tcp -m tcp -i eth1 --dport 3389 -j ACCEPT
Pour ouvrir le port 3389 sur la carte eth1
# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 3389 -J DNAT --to
192.168.0.39
pour rediriger vers l'adresse 192.168.0.39 de mon lan.
J'avais deja fait ce genre d'operation auparavant sans le moindre
probleme, mais là, ca ne fonctionne pas.
Quand j'essai de me connecter de l'exterieur, la tentative tombe en timeout.
Si je passe un nmap de l'exterieur, je vois le port 3389 comme filtered.
Je ne comprend pas bien ce qu'il se passe, si quelqu'un a une idée.
Tu as bien une règle qui accepte les paquets retour dans l'autre sens ?
Quelle regle dois je appliquer pour cela ?
Ça dépend de ce que tu as déjà. Si tu as déjà la règle classique : iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT alors ça suffit.
Oui, cette regle est présente
Que donne un tcptraceroute sur le port 3389 depuis l'extérieur ?
tcptraceroute 213.223.113.149 3389 Selected device eth0, address 192.168.0.1, port 38252 for outgoing packets Tracing the path to mx.cadic.fr (213.223.113.149) on TCP port 2021, 30 hops max
Hein ? Port 2021 ou 3389 ?
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
10 195.115.106.77 31.257 ms 31.668 ms 31.037 ms 11 213.223.42.85 31.241 ms 31.313 ms 30.926 ms 12 * * *
Bizarre, cette absence de réponse en 12.
13 213.223.113.149 49.599 ms 83.431 ms 50.134 ms
Ça doit être la réponse de la Cbox.
14 * * * 15 * 213.223.113.149 52.911 ms !H *
Et ça doit être la réponse de la passerelle Linux. !H signifie "Host unreachable", réponse typique quand l'adresse IP de destination n'est pas connectée et ne répond pas aux requêtes ARP. Mais ça peut aussi être un filtrage. La machine a bien pour adresse 192.168.0.39 ? A-t-elle des règles de filtrage ?
La machine 192.168.0.39 est la machine du LAN sur laquelle je veux rerouter le port, elle n'a pas de regle de filtrage, j'arrive à atteindre le port sans probleme depuis la machine linux.
Tu as bien une règle qui accepte les paquets retour dans l'autre sens ?
Quelle regle dois je appliquer pour cela ?
Ça dépend de ce que tu as déjà. Si tu as déjà la règle classique :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
alors ça suffit.
Oui, cette regle est présente
Que donne un tcptraceroute sur le port 3389 depuis l'extérieur ?
tcptraceroute 213.223.113.149 3389
Selected device eth0, address 192.168.0.1, port 38252 for outgoing
packets
Tracing the path to mx.cadic.fr (213.223.113.149) on TCP port 2021, 30
hops max
Hein ? Port 2021 ou 3389 ?
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
10 195.115.106.77 31.257 ms 31.668 ms 31.037 ms
11 213.223.42.85 31.241 ms 31.313 ms 30.926 ms
12 * * *
Bizarre, cette absence de réponse en 12.
13 213.223.113.149 49.599 ms 83.431 ms 50.134 ms
Ça doit être la réponse de la Cbox.
14 * * *
15 * 213.223.113.149 52.911 ms !H *
Et ça doit être la réponse de la passerelle Linux.
!H signifie "Host unreachable", réponse typique quand l'adresse IP de
destination n'est pas connectée et ne répond pas aux requêtes ARP. Mais
ça peut aussi être un filtrage. La machine a bien pour adresse
192.168.0.39 ? A-t-elle des règles de filtrage ?
La machine 192.168.0.39 est la machine du LAN sur laquelle je veux
rerouter le port, elle n'a pas de regle de filtrage, j'arrive à
atteindre le port sans probleme depuis la machine linux.
Tu as bien une règle qui accepte les paquets retour dans l'autre sens ?
Quelle regle dois je appliquer pour cela ?
Ça dépend de ce que tu as déjà. Si tu as déjà la règle classique : iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT alors ça suffit.
Oui, cette regle est présente
Que donne un tcptraceroute sur le port 3389 depuis l'extérieur ?
tcptraceroute 213.223.113.149 3389 Selected device eth0, address 192.168.0.1, port 38252 for outgoing packets Tracing the path to mx.cadic.fr (213.223.113.149) on TCP port 2021, 30 hops max
Hein ? Port 2021 ou 3389 ?
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
10 195.115.106.77 31.257 ms 31.668 ms 31.037 ms 11 213.223.42.85 31.241 ms 31.313 ms 30.926 ms 12 * * *
Bizarre, cette absence de réponse en 12.
13 213.223.113.149 49.599 ms 83.431 ms 50.134 ms
Ça doit être la réponse de la Cbox.
14 * * * 15 * 213.223.113.149 52.911 ms !H *
Et ça doit être la réponse de la passerelle Linux. !H signifie "Host unreachable", réponse typique quand l'adresse IP de destination n'est pas connectée et ne répond pas aux requêtes ARP. Mais ça peut aussi être un filtrage. La machine a bien pour adresse 192.168.0.39 ? A-t-elle des règles de filtrage ?
La machine 192.168.0.39 est la machine du LAN sur laquelle je veux rerouter le port, elle n'a pas de regle de filtrage, j'arrive à atteindre le port sans probleme depuis la machine linux.
Pascal Hambourg
tcptraceroute 213.223.113.149 3389 Selected device eth0, address 192.168.0.1, port 38252 for outgoing packets Tracing the path to mx.cadic.fr (213.223.113.149) on TCP port 2021, 30 hops max
Hein ? Port 2021 ou 3389 ?
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
Je me suis permis de tester depuis ma connexion, et je n'obtiens pas les mêmes résultats pour les deux ports. Pour alléger je commence les traces au dernier routeur avant la Cbox.
$ tcptraceroute -f 9 213.223.113.149 2021 Tracing the path to 213.223.113.149 on TCP port 2021, 30 hops max 9 213.223.42.173 34.166 ms 34.478 ms 32.693 ms 10 213.223.113.149 51.516 ms 51.785 ms 79.521 ms 11 213.223.113.149 51.223 ms 51.420 ms 51.939 ms 12 * * *
En 10, on voit la réponse "TTL exceeded" de la Cbox, ce qui indique bien que les paquets devraient être routés plus loin si on n'avait pas limité leur TTL à l'émission pour les besoins du traceroute. En 11, la réponse "TTL exceeded" de la passerelle qui est derrière indique à nouveau que le paquet devrait être routé plus loin. En 12, on ne le voit pas ici mais une capture de paquets révèle des réponses ICMP "Host unreachable". J'ai vérifié que ces paquets ont le même TTL que les "TTL exceeded" précédents, donc ils sont a priori émis par la même passerelle, pas par le serveur.
Cependant, les deux seules explications qui me viennent à l'esprit sont bancales : - la destination ne répond pas aux requêtes ARP, ce qui est peu probable si tu dis qu'elle répond en local ; - ces paquet ICMP "Host Unreachable" auraient pu être émis par une règle iptables "REJECT --reject-with icmp-host-unreachable" dans la chaîne FORWARD de la passerelle, mais ils auraient alors eu un TTL différent.
$ tcptraceroute -f 9 213.223.113.149 3389 Selected device ppp0, address 213.41.173.35, port 4729 for outgoing packets Tracing the path to 213.223.113.149 on TCP port 3389, 30 hops max 9 213.223.42.173 33.550 ms 34.140 ms 34.383 ms 10 213.223.113.149 115.734 ms 227.140 ms 52.075 ms 11 213.223.113.149 [closed] 60.198 ms 50.314 ms 51.227 ms
En 10, on voit à nouveau la réponse "TTL exceeded" de la Cbox, ce qui indique bien que les paquets devraient être routés plus loin si on n'avait pas limité leur TTL à l'émission pour les besoins du traceroute. En 11 par contre, on a une réponse [closed] qui correspond dans la capture de paquets à l'émission d'un RESET TCP en réponse au SYN du traceroute, avec le même TTL que les réponses précédentes de la passerelle.
J'en déduis que la passerelle ne tente pas de router plus loin les paquets destinés au port 3389, et donc qu'il n'y pas de routage contrairement au cas précédent. Il n'y a pas de redirection de ce port, les paquets vont dans la chaîne INPUT au lieu de FORWARD.
tcptraceroute 213.223.113.149 3389
Selected device eth0, address 192.168.0.1, port 38252 for outgoing
packets
Tracing the path to mx.cadic.fr (213.223.113.149) on TCP port 2021,
30 hops max
Hein ? Port 2021 ou 3389 ?
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
Je me suis permis de tester depuis ma connexion, et je n'obtiens pas les
mêmes résultats pour les deux ports. Pour alléger je commence les traces
au dernier routeur avant la Cbox.
$ tcptraceroute -f 9 213.223.113.149 2021
Tracing the path to 213.223.113.149 on TCP port 2021, 30 hops max
9 213.223.42.173 34.166 ms 34.478 ms 32.693 ms
10 213.223.113.149 51.516 ms 51.785 ms 79.521 ms
11 213.223.113.149 51.223 ms 51.420 ms 51.939 ms
12 * * *
En 10, on voit la réponse "TTL exceeded" de la Cbox, ce qui indique bien
que les paquets devraient être routés plus loin si on n'avait pas limité
leur TTL à l'émission pour les besoins du traceroute. En 11, la réponse
"TTL exceeded" de la passerelle qui est derrière indique à nouveau que
le paquet devrait être routé plus loin. En 12, on ne le voit pas ici
mais une capture de paquets révèle des réponses ICMP "Host unreachable".
J'ai vérifié que ces paquets ont le même TTL que les "TTL exceeded"
précédents, donc ils sont a priori émis par la même passerelle, pas par
le serveur.
Cependant, les deux seules explications qui me viennent à l'esprit sont
bancales :
- la destination ne répond pas aux requêtes ARP, ce qui est peu probable
si tu dis qu'elle répond en local ;
- ces paquet ICMP "Host Unreachable" auraient pu être émis par une règle
iptables "REJECT --reject-with icmp-host-unreachable" dans la chaîne
FORWARD de la passerelle, mais ils auraient alors eu un TTL différent.
$ tcptraceroute -f 9 213.223.113.149 3389
Selected device ppp0, address 213.41.173.35, port 4729 for outgoing packets
Tracing the path to 213.223.113.149 on TCP port 3389, 30 hops max
9 213.223.42.173 33.550 ms 34.140 ms 34.383 ms
10 213.223.113.149 115.734 ms 227.140 ms 52.075 ms
11 213.223.113.149 [closed] 60.198 ms 50.314 ms 51.227 ms
En 10, on voit à nouveau la réponse "TTL exceeded" de la Cbox, ce qui
indique bien que les paquets devraient être routés plus loin si on
n'avait pas limité leur TTL à l'émission pour les besoins du traceroute.
En 11 par contre, on a une réponse [closed] qui correspond dans la
capture de paquets à l'émission d'un RESET TCP en réponse au SYN du
traceroute, avec le même TTL que les réponses précédentes de la passerelle.
J'en déduis que la passerelle ne tente pas de router plus loin les
paquets destinés au port 3389, et donc qu'il n'y pas de routage
contrairement au cas précédent. Il n'y a pas de redirection de ce port,
les paquets vont dans la chaîne INPUT au lieu de FORWARD.
tcptraceroute 213.223.113.149 3389 Selected device eth0, address 192.168.0.1, port 38252 for outgoing packets Tracing the path to mx.cadic.fr (213.223.113.149) on TCP port 2021, 30 hops max
Hein ? Port 2021 ou 3389 ?
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
Je me suis permis de tester depuis ma connexion, et je n'obtiens pas les mêmes résultats pour les deux ports. Pour alléger je commence les traces au dernier routeur avant la Cbox.
$ tcptraceroute -f 9 213.223.113.149 2021 Tracing the path to 213.223.113.149 on TCP port 2021, 30 hops max 9 213.223.42.173 34.166 ms 34.478 ms 32.693 ms 10 213.223.113.149 51.516 ms 51.785 ms 79.521 ms 11 213.223.113.149 51.223 ms 51.420 ms 51.939 ms 12 * * *
En 10, on voit la réponse "TTL exceeded" de la Cbox, ce qui indique bien que les paquets devraient être routés plus loin si on n'avait pas limité leur TTL à l'émission pour les besoins du traceroute. En 11, la réponse "TTL exceeded" de la passerelle qui est derrière indique à nouveau que le paquet devrait être routé plus loin. En 12, on ne le voit pas ici mais une capture de paquets révèle des réponses ICMP "Host unreachable". J'ai vérifié que ces paquets ont le même TTL que les "TTL exceeded" précédents, donc ils sont a priori émis par la même passerelle, pas par le serveur.
Cependant, les deux seules explications qui me viennent à l'esprit sont bancales : - la destination ne répond pas aux requêtes ARP, ce qui est peu probable si tu dis qu'elle répond en local ; - ces paquet ICMP "Host Unreachable" auraient pu être émis par une règle iptables "REJECT --reject-with icmp-host-unreachable" dans la chaîne FORWARD de la passerelle, mais ils auraient alors eu un TTL différent.
$ tcptraceroute -f 9 213.223.113.149 3389 Selected device ppp0, address 213.41.173.35, port 4729 for outgoing packets Tracing the path to 213.223.113.149 on TCP port 3389, 30 hops max 9 213.223.42.173 33.550 ms 34.140 ms 34.383 ms 10 213.223.113.149 115.734 ms 227.140 ms 52.075 ms 11 213.223.113.149 [closed] 60.198 ms 50.314 ms 51.227 ms
En 10, on voit à nouveau la réponse "TTL exceeded" de la Cbox, ce qui indique bien que les paquets devraient être routés plus loin si on n'avait pas limité leur TTL à l'émission pour les besoins du traceroute. En 11 par contre, on a une réponse [closed] qui correspond dans la capture de paquets à l'émission d'un RESET TCP en réponse au SYN du traceroute, avec le même TTL que les réponses précédentes de la passerelle.
J'en déduis que la passerelle ne tente pas de router plus loin les paquets destinés au port 3389, et donc qu'il n'y pas de routage contrairement au cas précédent. Il n'y a pas de redirection de ce port, les paquets vont dans la chaîne INPUT au lieu de FORWARD.
olaf
Pascal Hambourg wrote:
tcptraceroute 213.223.113.149 3389 Selected device eth0, address 192.168.0.1, port 38252 for outgoing packets Tracing the path to mx.cadic.fr (213.223.113.149) on TCP port 2021, 30 hops max
Hein ? Port 2021 ou 3389 ?
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
Je me suis permis de tester depuis ma connexion, et je n'obtiens pas les mêmes résultats pour les deux ports. Pour alléger je commence les t races au dernier routeur avant la Cbox.
$ tcptraceroute -f 9 213.223.113.149 2021 Tracing the path to 213.223.113.149 on TCP port 2021, 30 hops max 9 213.223.42.173 34.166 ms 34.478 ms 32.693 ms 10 213.223.113.149 51.516 ms 51.785 ms 79.521 ms 11 213.223.113.149 51.223 ms 51.420 ms 51.939 ms 12 * * *
En 10, on voit la réponse "TTL exceeded" de la Cbox, ce qui indique bien que les paquets devraient être routés plus loin si on n'avait pas lim ité leur TTL à l'émission pour les besoins du traceroute. En 11, la rép onse "TTL exceeded" de la passerelle qui est derrière indique à nouveau que le paquet devrait être routé plus loin. En 12, on ne le voit pas ici mais une capture de paquets révèle des réponses ICMP "Host unreacha ble". J'ai vérifié que ces paquets ont le même TTL que les "TTL exceeded" précédents, donc ils sont a priori émis par la même passerelle, p as par le serveur.
Cependant, les deux seules explications qui me viennent à l'esprit sont bancales : - la destination ne répond pas aux requêtes ARP, ce qui est peu proba ble si tu dis qu'elle répond en local ; - ces paquet ICMP "Host Unreachable" auraient pu être émis par une r ègle iptables "REJECT --reject-with icmp-host-unreachable" dans la chaîne FORWARD de la passerelle, mais ils auraient alors eu un TTL différent.
$ tcptraceroute -f 9 213.223.113.149 3389 Selected device ppp0, address 213.41.173.35, port 4729 for outgoing packe ts Tracing the path to 213.223.113.149 on TCP port 3389, 30 hops max 9 213.223.42.173 33.550 ms 34.140 ms 34.383 ms 10 213.223.113.149 115.734 ms 227.140 ms 52.075 ms 11 213.223.113.149 [closed] 60.198 ms 50.314 ms 51.227 ms
En 10, on voit à nouveau la réponse "TTL exceeded" de la Cbox, ce qui indique bien que les paquets devraient être routés plus loin si on n'avait pas limité leur TTL à l'émission pour les besoins du tracer oute. En 11 par contre, on a une réponse [closed] qui correspond dans la capture de paquets à l'émission d'un RESET TCP en réponse au SYN du traceroute, avec le même TTL que les réponses précédentes de la p asserelle.
J'en déduis que la passerelle ne tente pas de router plus loin les paquets destinés au port 3389, et donc qu'il n'y pas de routage contrairement au cas précédent. Il n'y a pas de redirection de ce por t, les paquets vont dans la chaîne INPUT au lieu de FORWARD.
J'avais du flusher les regles concernant le 3389 quand vous avez fait votre test. Je viens de faire un nouveau test avec uniquement ces regles :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp -m tcp -i eth1 --dport 3389 -j ACCEPT iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 3389 -j DNAT --to-destination 192.168.0.39
Mais j'ai toujours le meme resultat...
Pascal Hambourg wrote:
tcptraceroute 213.223.113.149 3389
Selected device eth0, address 192.168.0.1, port 38252 for outgoing
packets
Tracing the path to mx.cadic.fr (213.223.113.149) on TCP port 2021,
30 hops max
Hein ? Port 2021 ou 3389 ?
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
Je me suis permis de tester depuis ma connexion, et je n'obtiens pas les
mêmes résultats pour les deux ports. Pour alléger je commence les t races
au dernier routeur avant la Cbox.
$ tcptraceroute -f 9 213.223.113.149 2021
Tracing the path to 213.223.113.149 on TCP port 2021, 30 hops max
9 213.223.42.173 34.166 ms 34.478 ms 32.693 ms
10 213.223.113.149 51.516 ms 51.785 ms 79.521 ms
11 213.223.113.149 51.223 ms 51.420 ms 51.939 ms
12 * * *
En 10, on voit la réponse "TTL exceeded" de la Cbox, ce qui indique bien
que les paquets devraient être routés plus loin si on n'avait pas lim ité
leur TTL à l'émission pour les besoins du traceroute. En 11, la rép onse
"TTL exceeded" de la passerelle qui est derrière indique à nouveau que
le paquet devrait être routé plus loin. En 12, on ne le voit pas ici
mais une capture de paquets révèle des réponses ICMP "Host unreacha ble".
J'ai vérifié que ces paquets ont le même TTL que les "TTL exceeded"
précédents, donc ils sont a priori émis par la même passerelle, p as par
le serveur.
Cependant, les deux seules explications qui me viennent à l'esprit sont
bancales :
- la destination ne répond pas aux requêtes ARP, ce qui est peu proba ble
si tu dis qu'elle répond en local ;
- ces paquet ICMP "Host Unreachable" auraient pu être émis par une r ègle
iptables "REJECT --reject-with icmp-host-unreachable" dans la chaîne
FORWARD de la passerelle, mais ils auraient alors eu un TTL différent.
$ tcptraceroute -f 9 213.223.113.149 3389
Selected device ppp0, address 213.41.173.35, port 4729 for outgoing packe ts
Tracing the path to 213.223.113.149 on TCP port 3389, 30 hops max
9 213.223.42.173 33.550 ms 34.140 ms 34.383 ms
10 213.223.113.149 115.734 ms 227.140 ms 52.075 ms
11 213.223.113.149 [closed] 60.198 ms 50.314 ms 51.227 ms
En 10, on voit à nouveau la réponse "TTL exceeded" de la Cbox, ce qui
indique bien que les paquets devraient être routés plus loin si on
n'avait pas limité leur TTL à l'émission pour les besoins du tracer oute.
En 11 par contre, on a une réponse [closed] qui correspond dans la
capture de paquets à l'émission d'un RESET TCP en réponse au SYN du
traceroute, avec le même TTL que les réponses précédentes de la p asserelle.
J'en déduis que la passerelle ne tente pas de router plus loin les
paquets destinés au port 3389, et donc qu'il n'y pas de routage
contrairement au cas précédent. Il n'y a pas de redirection de ce por t,
les paquets vont dans la chaîne INPUT au lieu de FORWARD.
J'avais du flusher les regles concernant le 3389 quand vous avez fait
votre test.
Je viens de faire un nouveau test avec uniquement ces regles :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp -m tcp -i eth1 --dport 3389 -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 3389 -j DNAT
--to-destination 192.168.0.39
tcptraceroute 213.223.113.149 3389 Selected device eth0, address 192.168.0.1, port 38252 for outgoing packets Tracing the path to mx.cadic.fr (213.223.113.149) on TCP port 2021, 30 hops max
Hein ? Port 2021 ou 3389 ?
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
Je me suis permis de tester depuis ma connexion, et je n'obtiens pas les mêmes résultats pour les deux ports. Pour alléger je commence les t races au dernier routeur avant la Cbox.
$ tcptraceroute -f 9 213.223.113.149 2021 Tracing the path to 213.223.113.149 on TCP port 2021, 30 hops max 9 213.223.42.173 34.166 ms 34.478 ms 32.693 ms 10 213.223.113.149 51.516 ms 51.785 ms 79.521 ms 11 213.223.113.149 51.223 ms 51.420 ms 51.939 ms 12 * * *
En 10, on voit la réponse "TTL exceeded" de la Cbox, ce qui indique bien que les paquets devraient être routés plus loin si on n'avait pas lim ité leur TTL à l'émission pour les besoins du traceroute. En 11, la rép onse "TTL exceeded" de la passerelle qui est derrière indique à nouveau que le paquet devrait être routé plus loin. En 12, on ne le voit pas ici mais une capture de paquets révèle des réponses ICMP "Host unreacha ble". J'ai vérifié que ces paquets ont le même TTL que les "TTL exceeded" précédents, donc ils sont a priori émis par la même passerelle, p as par le serveur.
Cependant, les deux seules explications qui me viennent à l'esprit sont bancales : - la destination ne répond pas aux requêtes ARP, ce qui est peu proba ble si tu dis qu'elle répond en local ; - ces paquet ICMP "Host Unreachable" auraient pu être émis par une r ègle iptables "REJECT --reject-with icmp-host-unreachable" dans la chaîne FORWARD de la passerelle, mais ils auraient alors eu un TTL différent.
$ tcptraceroute -f 9 213.223.113.149 3389 Selected device ppp0, address 213.41.173.35, port 4729 for outgoing packe ts Tracing the path to 213.223.113.149 on TCP port 3389, 30 hops max 9 213.223.42.173 33.550 ms 34.140 ms 34.383 ms 10 213.223.113.149 115.734 ms 227.140 ms 52.075 ms 11 213.223.113.149 [closed] 60.198 ms 50.314 ms 51.227 ms
En 10, on voit à nouveau la réponse "TTL exceeded" de la Cbox, ce qui indique bien que les paquets devraient être routés plus loin si on n'avait pas limité leur TTL à l'émission pour les besoins du tracer oute. En 11 par contre, on a une réponse [closed] qui correspond dans la capture de paquets à l'émission d'un RESET TCP en réponse au SYN du traceroute, avec le même TTL que les réponses précédentes de la p asserelle.
J'en déduis que la passerelle ne tente pas de router plus loin les paquets destinés au port 3389, et donc qu'il n'y pas de routage contrairement au cas précédent. Il n'y a pas de redirection de ce por t, les paquets vont dans la chaîne INPUT au lieu de FORWARD.
J'avais du flusher les regles concernant le 3389 quand vous avez fait votre test. Je viens de faire un nouveau test avec uniquement ces regles :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp -m tcp -i eth1 --dport 3389 -j ACCEPT iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 3389 -j DNAT --to-destination 192.168.0.39
Mais j'ai toujours le meme resultat...
Pascal Hambourg
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
Je me suis permis de tester depuis ma connexion, et je n'obtiens pas les mêmes résultats pour les deux ports. Pour alléger je commence les traces au dernier routeur avant la Cbox. [...]
J'avais du flusher les regles concernant le 3389 quand vous avez fait votre test. Je viens de faire un nouveau test avec uniquement ces regles :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp -m tcp -i eth1 --dport 3389 -j ACCEPT iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 3389 -j DNAT --to-destination 192.168.0.39
Mais j'ai toujours le meme resultat...
En effet. J'ai beau me creuser la cervelle, je sèche. Désolé.
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
Je me suis permis de tester depuis ma connexion, et je n'obtiens pas les
mêmes résultats pour les deux ports. Pour alléger je commence les traces
au dernier routeur avant la Cbox.
[...]
J'avais du flusher les regles concernant le 3389 quand vous avez fait
votre test.
Je viens de faire un nouveau test avec uniquement ces regles :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp -m tcp -i eth1 --dport 3389 -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 3389 -j DNAT
--to-destination 192.168.0.39
Mais j'ai toujours le meme resultat...
En effet. J'ai beau me creuser la cervelle, je sèche. Désolé.
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
Je me suis permis de tester depuis ma connexion, et je n'obtiens pas les mêmes résultats pour les deux ports. Pour alléger je commence les traces au dernier routeur avant la Cbox. [...]
J'avais du flusher les regles concernant le 3389 quand vous avez fait votre test. Je viens de faire un nouveau test avec uniquement ces regles :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp -m tcp -i eth1 --dport 3389 -j ACCEPT iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 3389 -j DNAT --to-destination 192.168.0.39
Mais j'ai toujours le meme resultat...
En effet. J'ai beau me creuser la cervelle, je sèche. Désolé.
Eric Razny
Le Tue, 17 Oct 2006 21:06:13 +0200, Pascal Hambourg a écrit :
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
Je me suis permis de tester depuis ma connexion, et je n'obtiens pas les mêmes résultats pour les deux ports. Pour alléger je commence les traces au dernier routeur avant la Cbox. [...]
J'avais du flusher les regles concernant le 3389 quand vous avez fait votre test. Je viens de faire un nouveau test avec uniquement ces regles :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp -m tcp -i eth1 --dport 3389 -j ACCEPT iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 3389 -j DNAT --to-destination 192.168.0.39
Mais j'ai toujours le meme resultat...
En effet. J'ai beau me creuser la cervelle, je sèche. Désolé.
Bonjour. Question con mais bon... :) Le forwarding est activé? Que donne cat /proc/sys/net/ipv4/ip_forward?
si c'est 0 il faut un petit echo 1 > /proc/sys/net/ipv4/ip_forward
Le Tue, 17 Oct 2006 21:06:13 +0200, Pascal Hambourg a écrit :
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
Je me suis permis de tester depuis ma connexion, et je n'obtiens pas les
mêmes résultats pour les deux ports. Pour alléger je commence les traces
au dernier routeur avant la Cbox.
[...]
J'avais du flusher les regles concernant le 3389 quand vous avez fait
votre test.
Je viens de faire un nouveau test avec uniquement ces regles :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp -m tcp -i eth1 --dport 3389 -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 3389 -j DNAT
--to-destination 192.168.0.39
Mais j'ai toujours le meme resultat...
En effet. J'ai beau me creuser la cervelle, je sèche. Désolé.
Bonjour.
Question con mais bon... :)
Le forwarding est activé?
Que donne cat /proc/sys/net/ipv4/ip_forward?
si c'est 0 il faut un petit echo 1 > /proc/sys/net/ipv4/ip_forward
Le Tue, 17 Oct 2006 21:06:13 +0200, Pascal Hambourg a écrit :
J'ai fait le test sur le 2021 qui lui aussi est redirigé sur le LAN
Je me suis permis de tester depuis ma connexion, et je n'obtiens pas les mêmes résultats pour les deux ports. Pour alléger je commence les traces au dernier routeur avant la Cbox. [...]
J'avais du flusher les regles concernant le 3389 quand vous avez fait votre test. Je viens de faire un nouveau test avec uniquement ces regles :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp -m tcp -i eth1 --dport 3389 -j ACCEPT iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 3389 -j DNAT --to-destination 192.168.0.39
Mais j'ai toujours le meme resultat...
En effet. J'ai beau me creuser la cervelle, je sèche. Désolé.
Bonjour. Question con mais bon... :) Le forwarding est activé? Que donne cat /proc/sys/net/ipv4/ip_forward?
si c'est 0 il faut un petit echo 1 > /proc/sys/net/ipv4/ip_forward
Pascal Hambourg
Question con mais bon... :) Le forwarding est activé?
Il me semble que si la machine émet des ICMP TTL Exceeded et Host Unreachable, ça veut dire que le forwarding IP est activé.
Question con mais bon... :)
Le forwarding est activé?
Il me semble que si la machine émet des ICMP TTL Exceeded et Host
Unreachable, ça veut dire que le forwarding IP est activé.
Le Wed, 18 Oct 2006 09:31:53 +0200, Pascal Hambourg a écrit :
Question con mais bon... :) Le forwarding est activé?
Il me semble que si la machine émet des ICMP TTL Exceeded et Host Unreachable, ça veut dire que le forwarding IP est activé.
De mon côté je n'obtiens pas ces réponses (pas de réponse du tout en fait)
Une autre solution serait de vérifier les interfaces. Un petit /sbin/ifconfig ne serais pas de trop (eth1 est-ce la bonne?)
Sinon les règles FORWARD. *Si* ça ne pose pas un problème de sécu pour les tests un policy à ACCEPT pour les tests?
Pascal Hambourg
Le forwarding est activé?
Il me semble que si la machine émet des ICMP TTL Exceeded et Host Unreachable, ça veut dire que le forwarding IP est activé.
De mon côté je n'obtiens pas ces réponses (pas de réponse du tout en fait)
Je viens de refaire le test, et apparemment la situation a légèrement changé : je ne reçois plus de Host Unreachable. Par contre je reçois toujours les TTL Exceeded de la machine qui est derrière le modem-routeur. Une machine qui n'a pas le forwarding activé n'aurait aucune raison d'envoyer des TTL exceeded, non ?
Le forwarding est activé?
Il me semble que si la machine émet des ICMP TTL Exceeded et Host
Unreachable, ça veut dire que le forwarding IP est activé.
De mon côté je n'obtiens pas ces réponses (pas de réponse du tout en
fait)
Je viens de refaire le test, et apparemment la situation a légèrement
changé : je ne reçois plus de Host Unreachable. Par contre je reçois
toujours les TTL Exceeded de la machine qui est derrière le
modem-routeur. Une machine qui n'a pas le forwarding activé n'aurait
aucune raison d'envoyer des TTL exceeded, non ?
Il me semble que si la machine émet des ICMP TTL Exceeded et Host Unreachable, ça veut dire que le forwarding IP est activé.
De mon côté je n'obtiens pas ces réponses (pas de réponse du tout en fait)
Je viens de refaire le test, et apparemment la situation a légèrement changé : je ne reçois plus de Host Unreachable. Par contre je reçois toujours les TTL Exceeded de la machine qui est derrière le modem-routeur. Une machine qui n'a pas le forwarding activé n'aurait aucune raison d'envoyer des TTL exceeded, non ?
Eric Razny
Le Wed, 18 Oct 2006 19:15:53 +0200, Pascal Hambourg a écrit :
Le forwarding est activé?
Il me semble que si la machine émet des ICMP TTL Exceeded et Host Unreachable, ça veut dire que le forwarding IP est activé.
De mon côté je n'obtiens pas ces réponses (pas de réponse du tout en fait)
Je viens de refaire le test, et apparemment la situation a légèrement changé : je ne reçois plus de Host Unreachable. Par contre je reçois toujours les TTL Exceeded de la machine qui est derrière le modem-routeur. Une machine qui n'a pas le forwarding activé n'aurait aucune raison d'envoyer des TTL exceeded, non ?
Yep, mais quand j'ai voulu réassayer il y a maintenant quelque chose au bout. (avec nmap port closed).
Quand j'avais fait le test avec hping3 il ne me semble pas que j'avais de TTL Exceeded (option -T et -t pour passer outre les absences de réponse)
Olaf : tu as donc modifié quelque chose. Les groupes ne sont pas en demande seulement ; quand on a trouvé la réponse à une question qu'on a posé sur usenet il est de bon ton de la donner, même si les contribution n'ont pas aidée... :)
Le Wed, 18 Oct 2006 19:15:53 +0200, Pascal Hambourg a écrit :
Le forwarding est activé?
Il me semble que si la machine émet des ICMP TTL Exceeded et Host
Unreachable, ça veut dire que le forwarding IP est activé.
De mon côté je n'obtiens pas ces réponses (pas de réponse du tout en
fait)
Je viens de refaire le test, et apparemment la situation a légèrement
changé : je ne reçois plus de Host Unreachable. Par contre je reçois
toujours les TTL Exceeded de la machine qui est derrière le
modem-routeur. Une machine qui n'a pas le forwarding activé n'aurait
aucune raison d'envoyer des TTL exceeded, non ?
Yep, mais quand j'ai voulu réassayer il y a maintenant quelque chose au
bout. (avec nmap port closed).
Quand j'avais fait le test avec hping3 il ne me semble pas que j'avais de
TTL Exceeded (option -T et -t pour passer outre les absences de réponse)
Olaf : tu as donc modifié quelque chose. Les groupes ne sont pas
en demande seulement ; quand on a trouvé la réponse à une question qu'on
a posé sur usenet il est de bon ton de la donner, même si les
contribution n'ont pas aidée... :)
Le Wed, 18 Oct 2006 19:15:53 +0200, Pascal Hambourg a écrit :
Le forwarding est activé?
Il me semble que si la machine émet des ICMP TTL Exceeded et Host Unreachable, ça veut dire que le forwarding IP est activé.
De mon côté je n'obtiens pas ces réponses (pas de réponse du tout en fait)
Je viens de refaire le test, et apparemment la situation a légèrement changé : je ne reçois plus de Host Unreachable. Par contre je reçois toujours les TTL Exceeded de la machine qui est derrière le modem-routeur. Une machine qui n'a pas le forwarding activé n'aurait aucune raison d'envoyer des TTL exceeded, non ?
Yep, mais quand j'ai voulu réassayer il y a maintenant quelque chose au bout. (avec nmap port closed).
Quand j'avais fait le test avec hping3 il ne me semble pas que j'avais de TTL Exceeded (option -T et -t pour passer outre les absences de réponse)
Olaf : tu as donc modifié quelque chose. Les groupes ne sont pas en demande seulement ; quand on a trouvé la réponse à une question qu'on a posé sur usenet il est de bon ton de la donner, même si les contribution n'ont pas aidée... :)
