Salut,

Je sais, je devrais pas poser la question parce que la réponse est
certainement dans la doc d'olivieraj(.free.fr). Mais je n'ai pas
vraiment le temps de la lire et surtout si je fais une erreur, je perds
sans doute la main sur la machine, voir pire.

Je veux modifier le NAT d'une box club-internet en ouvrant un telnet sur
la box à partir d'une session ssh ouverte depuis le net sur un des
postes du réseau.

Habituellement, on peut le faire à l'aide d'une interface web en se
connectant sur 192.168.1.1, si on est à l'intérieur du LAN.

Le but est de modifier l'adresse et le port de destination du traffic
venant du grand ternet vers l'une ou l'autre des machines, alors que je
ne suis pas sur place.

Les règles actuelles de la box, obtenues avec 'iptables -nvL -t nat',
sont à <http://roulaize.fr/need_/nat_cibox.txt>

Pour résumer, ce que je voudrais, c'est la commande qui permet de
détruire une règle et la commande qui permet de créer une règle de
natage.

Abusé-je en vous demandant d'être assez didactique ? Ça me mettra le
pied à l'étrier pour lire enfin cette très bonne doc.

Merci de votre aide

--
Unix is user friendly. He's just very picky about who his friends are.
Hugo (né il y a 1 371 987 679 secondes)

Salut,

Hugolino a écrit :
>
> Je sais, je devrais pas poser la question parce que la réponse est
> certainement dans la doc d'olivieraj(.free.fr). Mais je n'ai pas
> vraiment le temps de la lire et surtout si je fais une erreur, je perds
> sans doute la main sur la machine, voir pire.

Pas moyen de programmer un reboot automatique ?

> Je veux modifier le NAT d'une box club-internet en ouvrant un telnet sur
> la box à partir d'une session ssh ouverte depuis le net sur un des
> postes du réseau.
>
> Le but est de modifier l'adresse et le port de destination du traffic
> venant du grand ternet vers l'une ou l'autre des machines, alors que je
> ne suis pas sur place.
>
> Les règles actuelles de la box, obtenues avec 'iptables -nvL -t nat',
> sont à <http://roulaize.fr/need_/nat_cibox.txt>

Note perso : iptables-save, c'est mieux (si dispo). Comme ça tu vois la
syntaxe des règles.

> Pour résumer, ce que je voudrais, c'est la commande qui permet de
> détruire une règle et la commande qui permet de créer une règle de
> natage.

iptables -t nat -A PREROUTING -i nas_8_36 \
-p {tcp|udp} --dport <port_original> \
-j DNAT --to <adresse_finale>[:<port_final>]

Voir dans la chaîne FORWARD de la table 'filter' s'il faut aussi créer
une règle acceptant le trafic ainsi redirigé ou bien si tout est déjà
accepté par défaut (tu parles d'un trou de sécu).

iptables -A FORWARD -i nas_8_36 -d <adresse_finale> \
-p {tcp|udp} --dport <port_final> -j ACCEPT

Hugolino <hugolino@free.fr> wrote:
>
> Salut,

Bonjour,

> Je veux modifier le NAT d'une box club-internet en ouvrant un telnet
> sur la box à partir d'une session ssh ouverte depuis le net sur un des
> postes du réseau.
>
> Habituellement, on peut le faire à l'aide d'une interface web en se
> connectant sur 192.168.1.1, si on est à l'intérieur du LAN.

Et bien, tu rediriges un port de ta machine vers le 80 de la c-i.box
dans ta session ssh. Je fais ça tout le temps pour gérer ma .box Ã
distance, en me connectant en ssh sur mon petit serveur dans le LAN.

ssh -L 8080:192.168.1.1:80 <@ip-extérieure>

Ensuite, tu accèdes simplement à l'interface via
http://localhost:8080/

> Le but est de modifier l'adresse et le port de destination du traffic
> venant du grand ternet vers l'une ou l'autre des machines, alors que
> je ne suis pas sur place.

Cf. ci-dessus.

A noter que sur la c-i.box, modifier les règles iptables en direct ne
sert à rien, car tout sera perdu au prochain redémarrage. Testé.

Mes deux centimes,
--
Nicolas

Le Wed, 17 Oct 2007 12:04:23 +0200, Pascal Hambourg a écrit:

> > [...] si je fais une erreur, je perds sans doute la main sur la
> > machine, voir pire.
>
> Pas moyen de programmer un reboot automatique ?

Ah oui, j'avais oublié que j'en avais déjà un (avec expect qui cause à
telnet), mais il n'a lieu que tous les deux jours à 4 h du matin.
Je ne peux pas en mettre toutes les trois heures, car le serveur ne sera
pas chez moi et la box sert pour le téléphone...


> > Les règles actuelles de la box, obtenues avec 'iptables -nvL -t nat',
> > sont à <http://roulaize.fr/need_/nat_cibox.txt>
>
> Note perso : iptables-save, c'est mieux (si dispo). Comme ça tu vois la
> syntaxe des règles.

OK noté, mais pas disponible sur la ci-box.


> > Pour résumer, ce que je voudrais, c'est la commande qui permet de
> > détruire une règle et la commande qui permet de créer une règle de
> > natage.
>
> iptables -t nat -A PREROUTING -i nas_8_36 \
> -p {tcp|udp} --dport <port_original> \
> -j DNAT --to <adresse_finale>[:<port_final>]

A première vue, la syntaxe n'est pas très complexe, mais je ne comprends
pas pourquoi il faut "-t nat" et "-j DNAT", un seul ne suffit pas ?


> Voir dans la chaîne FORWARD de la table 'filter' s'il faut aussi créer
> une règle acceptant le trafic ainsi redirigé ou bien si tout est déjà
> accepté par défaut (tu parles d'un trou de sécu).

Je ne comprends pas ce que tu veux dire...

N'y a-t'il pas besoin de détruire la règle précédente qui envoyait le
traffic vers une autre machine ?


Merci pour ton aide


--

> 'lut les lopettes.
Ah, c'est un message perso...
Hugo (né il y a 1 372 007 990 secondes)

Le 17 Oct 2007 10:13:25 GMT, Nicolas KOWALSKI a écrit:
> Hugolino <hugolino@free.fr> wrote:
> >
> > Salut,
>
> Bonjour,
>
> > Je veux modifier le NAT d'une box club-internet en ouvrant un telnet
> > sur la box à partir d'une session ssh ouverte depuis le net sur un des
> > postes du réseau.
> >
> > Habituellement, on peut le faire à l'aide d'une interface web en se
> > connectant sur 192.168.1.1, si on est à l'intérieur du LAN.
>
> Et bien, tu rediriges un port de ta machine vers le 80 de la c-i.box
> dans ta session ssh. Je fais ça tout le temps pour gérer ma .box à
> distance, en me connectant en ssh sur mon petit serveur dans le LAN.
>
> ssh -L 8080:192.168.1.1:80 <@ip-extérieure>
>
> Ensuite, tu accèdes simplement à l'interface via
> http://localhost:8080/

Tu as été un peu violent avec mes neurones

Quand tu dis de "tu rediriges un port de ta machine", tu parles bien de
la machine du LAN, sur laquelle je suis connecté en ssh depuis
l'extérieur ? ("machine" = "mon petit serveur dans le LAN" ?)

Ensuite, si je cause au port 8080 de ma machine, elle redirigera ce que
j'envoie au port 80 du routeur ? J'imagine que oui, mais pourquoi dis-tu
qu'on accède à l'interface web par "http://localhost:8080/" ?
Si je ne suis chez moi, "localhost" != "mon petit serveur dans le LAN"

Par contre si je suis connecté en ssh, je peux tenter directement un
'elinks http://192.168.1.1:80', le problème étant que le html qu'envoie
la box est bourré de morceaux de javascript qu'elinks n'a pas l'air de
digérer car la page est vide.
Essayé aussi avec w3m, qui affiche "No line".
C'est pour ça que je veux le faire par telnet.

> A noter que sur la c-i.box, modifier les règles iptables en direct ne
> sert à rien, car tout sera perdu au prochain redémarrage. Testé.

OK bien noté.

> Mes deux centimes,

Pas assez cher mon fils


--
>> C'est n'importe quoi !
> Tu dis ça parce que tu es à court d'arguments.
Comment peut-on être à court de quelque chose dont on n'a pas besoin ?
Hugo (né il y a 1 372 076 170 secondes)

Hugolino a écrit :
> Le Wed, 17 Oct 2007 12:04:23 +0200, Pascal Hambourg a écrit:
>
>>>[...] si je fais une erreur, je perds sans doute la main sur la
>>>machine, voir pire.
>>
>> Pas moyen de programmer un reboot automatique ?
>
> Ah oui, j'avais oublié que j'en avais déjà un (avec expect qui cause à
> telnet), mais il n'a lieu que tous les deux jours à 4 h du matin.
> Je ne peux pas en mettre toutes les trois heures, car le serveur ne sera
> pas chez moi et la box sert pour le téléphone...

Je pensais à un reboot programmé dans x minutes, et désactivé si tout
marche bien suite aux modifications de règles iptables.

>>>Pour résumer, ce que je voudrais, c'est la commande qui permet de
>>>détruire une règle et la commande qui permet de créer une règle de
>>>natage.
>>
>> iptables -t nat -A PREROUTING -i nas_8_36 \
>> -p {tcp|udp} --dport <port_original> \
>> -j DNAT --to <adresse_finale>[:<port_final>]
>
> A première vue, la syntaxe n'est pas très complexe, mais je ne comprends
> pas pourquoi il faut "-t nat" et "-j DNAT", un seul ne suffit pas ?

L'option -t spécifie la table dans laquelle on va créer la règle. Pour
faire du NAT, c'est fort logiquement dans la table "nat".
L'option -j spécifie l'action associée à la règle, ici un NAT
destination ou DNAT (qui n'est possible que dans la table 'nat').

>> Voir dans la chaîne FORWARD de la table 'filter' s'il faut aussi créer
>> une règle acceptant le trafic ainsi redirigé ou bien si tout est déjà
>> accepté par défaut (tu parles d'un trou de sécu).
>
> Je ne comprends pas ce que tu veux dire...
>
> N'y a-t'il pas besoin de détruire la règle précédente qui envoyait le
> traffic vers une autre machine ?

Ah oui, j'oubliais la suppression. Remplacer -A par -D. Ou
éventuellement créer la règle avec -I au lieu de -A, pour l'insérer en
début de chaîne afin qu'elle soit examinée avant les règles existantes.

Mais ce que je disais au sujet de FORWARD n'a rien à voir avec ceci. La
règle DNAT ne fait que modifier l'adresse et/ou le port destination,
elle ne dit rien sur l'acceptation ou le blocage du paquet. Pour les
paquets traversant le routeur dans les deux sens, c'est dans la chaîne
FORWARD (de la table 'filter', table par défaut si -t est omis) que ça
se passe. Note : le paquet traverse FORWARD après PREROUTING, donc après
que l'adresse et/ou le port source ont été modifiés.

Hugolino <hugolino@free.fr> wrote:
> Le 17 Oct 2007 10:13:25 GMT, Nicolas KOWALSKI a écrit:
>> Hugolino <hugolino@free.fr> wrote:
>> >
>> > Je veux modifier le NAT d'une box club-internet en ouvrant un
>> > telnet sur la box à partir d'une session ssh ouverte depuis le net
>> > sur un des postes du réseau.
>> >
>> > Habituellement, on peut le faire à l'aide d'une interface web en se
>> > connectant sur 192.168.1.1, si on est à l'intérieur du LAN.
>>
>> Et bien, tu rediriges un port de ta machine vers le 80 de la c-i.box
>> dans ta session ssh. Je fais ça tout le temps pour gérer ma .box Ã
>> distance, en me connectant en ssh sur mon petit serveur dans le LAN.
>>
>> ssh -L 8080:192.168.1.1:80 <@ip-extérieure>
>>
>> Ensuite, tu accèdes simplement à l'interface via
>> http://localhost:8080/
>
> Tu as été un peu violent avec mes neurones

Mais non, mais non, c'est juste une technique comme une autre. :-)

> Quand tu dis de "tu rediriges un port de ta machine", tu parles bien
> de la machine du LAN, sur laquelle je suis connecté en ssh depuis
> l'extérieur ? ("machine" = "mon petit serveur dans le LAN" ?)

Non, je parle de la machine extérieure à ton LAN, *depuis laquelle* tu
veux faire tes modifications. Appelons-là "remote".

hugolino@remote$ ssh -L 8080:192.168.1.1:80 <@ip-extérieure-de-la-ci.box>

Ensuite, toujours sur "remote", tu peux lancer un browser, que tu fais
pointer vers http://localhost:8080/ , qui correspond alors à l'interface
http de la c-i.box.

> Par contre si je suis connecté en ssh, je peux tenter directement un
> 'elinks http://192.168.1.1:80', le problème étant que le html
> qu'envoie la box est bourré de morceaux de javascript qu'elinks n'a
> pas l'air de digérer car la page est vide.

Tout à fait exact, le html envoyé est absolument immonde. Il faut passer
par un browser suffisamment riche, style Firefox, mais IE est
préférable.

>> Mes deux centimes,
>
> Pas assez cher mon fils

Deux de plus !

--
Nicolas

Le Wed, 17 Oct 2007 13:57:16 +0200, Pascal Hambourg a écrit:
> Hugolino a écrit :
> > Le Wed, 17 Oct 2007 12:04:23 +0200, Pascal Hambourg a écrit:

> > Ah oui, j'avais oublié que j'en avais déjà un (avec expect qui cause
> > à telnet), mais il n'a lieu que tous les deux jours à 4 h du matin.
> > Je ne peux pas en mettre toutes les trois heures, car le serveur ne
> > sera pas chez moi et la box sert pour le téléphone...
>
> Je pensais à un reboot programmé dans x minutes, et désactivé si tout
> marche bien suite aux modifications de règles iptables.

Ah OK. J'aurais du y penser.

> >> iptables -t nat -A PREROUTING -i nas_8_36 \
> >> -p {tcp|udp} --dport <port_original> \
> >> -j DNAT --to <adresse_finale>[:<port_final>]
> >
> > A première vue, la syntaxe n'est pas très complexe, mais je ne
> > comprends pas pourquoi il faut "-t nat" et "-j DNAT", un seul ne
> > suffit pas ?
>
> L'option -t spécifie la table dans laquelle on va créer la règle.
> Pour faire du NAT, c'est fort logiquement dans la table "nat".
> L'option -j spécifie l'action associée à la règle, ici un NAT
> destination ou DNAT (qui n'est possible que dans la table 'nat').

OK, pour le -t (table), c'est le -j (target) que je ne comprenais pas
(what to do if the packet matches the rule). Et je ne comprends toujours
pas pourquoi il faut une target. Si on veut ajouter quelque chose à la
table nat, c'est bien parce qu'on veut l'accepter, non ?
En plus tu dis plus bas que de toutes façons le packet sera examiné par
la table filter...

> >> Voir dans la chaîne FORWARD de la table 'filter' s'il faut aussi créer
> >> une règle acceptant le trafic ainsi redirigé ou bien si tout est déjà
> >> accepté par défaut (tu parles d'un trou de sécu).
> >
> > Je ne comprends pas ce que tu veux dire...
> >
> > N'y a-t'il pas besoin de détruire la règle précédente qui envoyait le
> > traffic vers une autre machine ?
>
> Ah oui, j'oubliais la suppression. Remplacer -A par -D. Ou
> éventuellement créer la règle avec -I au lieu de -A, pour l'insérer en
> début de chaîne afin qu'elle soit examinée avant les règles existantes.

J'ai ajouté ma règle avec -I et 'iptables -nvL -t nat' me l'affiche en
premier.
Par contre elle est toujours affiché *exactement* de la même manière
après avoir remplacé le -I par -D dans la ligne de commande. C'est à
dire que je n'arrive pas à détruire cette règle.


> Mais ce que je disais au sujet de FORWARD n'a rien à voir avec ceci. La
> règle DNAT ne fait que modifier l'adresse et/ou le port destination,
> elle ne dit rien sur l'acceptation ou le blocage du paquet. Pour les
> paquets traversant le routeur dans les deux sens, c'est dans la chaîne
> FORWARD (de la table 'filter', table par défaut si -t est omis) que ça
> se passe. Note : le paquet traverse FORWARD après PREROUTING, donc après
> que l'adresse et/ou le port source ont été modifiés.

Raison supplémentaire qui m'empêche de comprendre le -j (target) puisque
tu dis que de toute façon le packet sera examiné par une éventuelle
règle de FORWARD..

Merci de tes explications.

--
Si j'etais toi, j'irai verifier la veracite de l'information avant de passer
pour un con sur les ML des BSD. Ca pue le troll pourri dans tout le systeme
solaire son truc. -+- ST (back in Solar System rev 2004) -+-
Hugo (né il y a 1 372 078 555 secondes)