dans la boite ou je suis, je peux pas me connecter à jabber, d'ou l'idee
de faire passer le bousin par un tunnel ssh.
Pour l'instant, j'ai fait ca :
$ sudo iptables -t nat -A PREROUTING -p tcp --dport 5222 -j DNAT --to
127.0.0.1:5222
et puis je me suis connecté en ssh sur un serveur qui permet la
connexion à jabber en redirigeant mon port 5222, et visiblement la
redirection fonctionne :
$ nc 127.0.0.1 5222
blah
<stream:error>Invalid XML</stream:error>
dans la boite ou je suis, je peux pas me connecter à jabber, d'ou l'idee de faire passer le bousin par un tunnel ssh.
Pour l'instant, j'ai fait ca : $ sudo iptables -t nat -A PREROUTING -p tcp --dport 5222 -j DNAT --to 127.0.0.1:5222
Pourquoi utiliser iptables ? Il suffit de configurer ton client pour se connecter à localhost, en précisant un jid explicitement.
George Abitbol
George Abitbol wrote in message <e5paie$ff0$:
dans la boite ou je suis, je peux pas me connecter à jabber, d'ou l'idee de faire passer le bousin par un tunnel ssh.
Pour l'instant, j'ai fait ca : $ sudo iptables -t nat -A PREROUTING -p tcp --dport 5222 -j DNAT --to 127.0.0.1:5222
Pourquoi utiliser iptables ? Il suffit de configurer ton client pour se connecter à localhost,
jusque là je suis, et ca fonctionne pas ^u
ca marche :)
en précisant un jid explicitement.
Ce truc que je comprends pas, ca doit etre le champ "connexion au serveur" dans les options avancées de gaim... J'avais essayé de le mettre dans le champ "serveur", ca me donnait une erreur.
Bon bah merci :)
euh quand meme si on pouvait m'expliquer pourquoi ca fonctionne pas avec le prerouting, parce que le serveur ackait mes paquets quand j'essayais de me connecter...
George Abitbol wrote in message <e5paie$ff0$1@shakotay.alphanet.ch>:
dans la boite ou je suis, je peux pas me connecter à jabber, d'ou l'idee
de faire passer le bousin par un tunnel ssh.
Pour l'instant, j'ai fait ca :
$ sudo iptables -t nat -A PREROUTING -p tcp --dport 5222 -j DNAT --to
127.0.0.1:5222
Pourquoi utiliser iptables ? Il suffit de configurer ton client pour se
connecter à localhost,
jusque là je suis, et ca fonctionne pas ^u
ca marche :)
en précisant un jid explicitement.
Ce truc que je comprends pas, ca doit etre le champ "connexion au
serveur" dans les options avancées de gaim...
J'avais essayé de le mettre dans le champ "serveur", ca me donnait une
erreur.
Bon bah merci :)
euh quand meme si on pouvait m'expliquer pourquoi ca fonctionne pas avec
le prerouting, parce que le serveur ackait mes paquets quand j'essayais
de me connecter...
dans la boite ou je suis, je peux pas me connecter à jabber, d'ou l'idee de faire passer le bousin par un tunnel ssh.
Pour l'instant, j'ai fait ca : $ sudo iptables -t nat -A PREROUTING -p tcp --dport 5222 -j DNAT --to 127.0.0.1:5222
Pourquoi utiliser iptables ? Il suffit de configurer ton client pour se connecter à localhost,
jusque là je suis, et ca fonctionne pas ^u
ca marche :)
en précisant un jid explicitement.
Ce truc que je comprends pas, ca doit etre le champ "connexion au serveur" dans les options avancées de gaim... J'avais essayé de le mettre dans le champ "serveur", ca me donnait une erreur.
Bon bah merci :)
euh quand meme si on pouvait m'expliquer pourquoi ca fonctionne pas avec le prerouting, parce que le serveur ackait mes paquets quand j'essayais de me connecter...
Pascal Hambourg
Salut,
dans la boite ou je suis, je peux pas me connecter à jabber, d'ou l'idee de faire passer le bousin par un tunnel ssh.
Pour l'instant, j'ai fait ca : $ sudo iptables -t nat -A PREROUTING -p tcp --dport 5222 -j DNAT --to 127.0.0.1:5222
Sur le client ?
Cette règle : - ne marche pas ; - ne servirait à rien dans ton cas.
1) Cette règle ne marche pas. Seuls les paquets entrants par une interface autre qu'une interface de loopback sont susceptibles d'être affectés par cette règle (les paquets émis en loopback ne traversent pas la chaîne PREROUTING de la table nat car ils ont déjé été vus par le suivi de connexion en sortie). Après avoir traversé la chaîne PREROUTING, les paquets affectés vont arriver à la décision de routage d'entrée avec l'adresse de destination 127.0.0.1. Comme cette adresse appartient à l'interface de loopback, ils vont se faire jeter car le routage IP refuse les paquets destinés à une adresse de loopback arrivant de l'extérieur (par une interface non loopback). Ce n'est en effet pas normal de recevoir de tels paquets. Si on veut rediriger des paquets entrants vers la machine locale (pour faire du proxy transparent par exemple), on doit soit utiliser DNAT avec l'adresse d'une interface non loopback, ou la cible REDIRECT qui choisit d'elle-même l'adresse de l'interface d'entrée.
2) Cette règle ne servirait à rien dans ton cas. Si j'ai bien compris, le client Jabber est la machine cliente SSH. Par conséquent les demandes de connexion sont générées localement et sortent en traversant les chaînes OUTPUT et POSTROUTING. Donc elles ne peuvent pas déclencher cette règle qui est dans la chaîne PREROUTING. La chaîne OUTPUT peut aussi faire du DNAT, sous conditions pour les versions de noyau inférieures à 2.4.29.
Salut,
dans la boite ou je suis, je peux pas me connecter à jabber, d'ou l'idee
de faire passer le bousin par un tunnel ssh.
Pour l'instant, j'ai fait ca :
$ sudo iptables -t nat -A PREROUTING -p tcp --dport 5222 -j DNAT --to
127.0.0.1:5222
Sur le client ?
Cette règle :
- ne marche pas ;
- ne servirait à rien dans ton cas.
1) Cette règle ne marche pas.
Seuls les paquets entrants par une interface autre qu'une interface de
loopback sont susceptibles d'être affectés par cette règle (les paquets
émis en loopback ne traversent pas la chaîne PREROUTING de la table nat
car ils ont déjé été vus par le suivi de connexion en sortie). Après
avoir traversé la chaîne PREROUTING, les paquets affectés vont arriver à
la décision de routage d'entrée avec l'adresse de destination 127.0.0.1.
Comme cette adresse appartient à l'interface de loopback, ils vont se
faire jeter car le routage IP refuse les paquets destinés à une adresse
de loopback arrivant de l'extérieur (par une interface non loopback). Ce
n'est en effet pas normal de recevoir de tels paquets. Si on veut
rediriger des paquets entrants vers la machine locale (pour faire du
proxy transparent par exemple), on doit soit utiliser DNAT avec
l'adresse d'une interface non loopback, ou la cible REDIRECT qui choisit
d'elle-même l'adresse de l'interface d'entrée.
2) Cette règle ne servirait à rien dans ton cas.
Si j'ai bien compris, le client Jabber est la machine cliente SSH. Par
conséquent les demandes de connexion sont générées localement et sortent
en traversant les chaînes OUTPUT et POSTROUTING. Donc elles ne peuvent
pas déclencher cette règle qui est dans la chaîne PREROUTING. La chaîne
OUTPUT peut aussi faire du DNAT, sous conditions pour les versions de
noyau inférieures à 2.4.29.
dans la boite ou je suis, je peux pas me connecter à jabber, d'ou l'idee de faire passer le bousin par un tunnel ssh.
Pour l'instant, j'ai fait ca : $ sudo iptables -t nat -A PREROUTING -p tcp --dport 5222 -j DNAT --to 127.0.0.1:5222
Sur le client ?
Cette règle : - ne marche pas ; - ne servirait à rien dans ton cas.
1) Cette règle ne marche pas. Seuls les paquets entrants par une interface autre qu'une interface de loopback sont susceptibles d'être affectés par cette règle (les paquets émis en loopback ne traversent pas la chaîne PREROUTING de la table nat car ils ont déjé été vus par le suivi de connexion en sortie). Après avoir traversé la chaîne PREROUTING, les paquets affectés vont arriver à la décision de routage d'entrée avec l'adresse de destination 127.0.0.1. Comme cette adresse appartient à l'interface de loopback, ils vont se faire jeter car le routage IP refuse les paquets destinés à une adresse de loopback arrivant de l'extérieur (par une interface non loopback). Ce n'est en effet pas normal de recevoir de tels paquets. Si on veut rediriger des paquets entrants vers la machine locale (pour faire du proxy transparent par exemple), on doit soit utiliser DNAT avec l'adresse d'une interface non loopback, ou la cible REDIRECT qui choisit d'elle-même l'adresse de l'interface d'entrée.
2) Cette règle ne servirait à rien dans ton cas. Si j'ai bien compris, le client Jabber est la machine cliente SSH. Par conséquent les demandes de connexion sont générées localement et sortent en traversant les chaînes OUTPUT et POSTROUTING. Donc elles ne peuvent pas déclencher cette règle qui est dans la chaîne PREROUTING. La chaîne OUTPUT peut aussi faire du DNAT, sous conditions pour les versions de noyau inférieures à 2.4.29.
