Conversation
precedente ou
suivante
Tunnel de paquets UDP en fonction de leur source / destination?
Envoyé par:
creativehazard
Bonsoir à toutes et à tous,
J'ai une question assez technique à poser, je me permets donc un petit récap de la situation.
Depuis quelques temps, mon F.A.I. (Free pour ne pas le citer ^^) bloque partie des paquets p2p.
Si je fais le test (Entre autres) indiqué ici:
[www.journaldufreenaute.fr]
Je passe de 600Ko en download à 3Ko. Je sais donc que Free filtre sur le user agent, mais aussi sur le formatage des paquets. Il m'est très difficile de jouer sur internet lorsque le jeu utilise UDP, etc... Je n'utilise pourtant pas de client p2p (A part le FTP, mais est-ce un moyen de p2p?... Troll mode on ^^).
Or depuis peu, j'essaye de jouer à un jeu sur ma nintendo DS qui utilise exclusivement l'UDP pour communiquer. Ce qui bien sûr ne fonctionne jamais, vu que Free doit probablement cataloguer les paquets en p2p et les dropper ou les mettre en priorité très basse.
Mon réseau est conçu comme suit:
La Freebox est reliée à ma passerelle / serveur debian (Sarge) via de l'ethernet de base (62.xx.xx.xx, Eth1 pour l'exemple). Debian filtre et est connecté à un point d'accès sans fil (via eth0, 192.168.0.1). Les ordinateurs de mon réseau à la maison se connectent donc tous à ce routeur, de façon transparente. Le réseau chez moi est bien connecté à internet (Masquerading de eth0 sur eth1).
Quand je veux jouer sur le net avec ma DS, j'active une règle iptables qui dit que tous les paquets TCP / UDP venant d'internet sonts DNAT vers la nintendo DS, dont l'IP est 192.168.0.110. Quand quelqu'un essaye de se connecter, j'ai bien les quelques échanges que Free ne bloque pas qui transitent quand je "tcpdump | grep 192.168.0.110".
On a à peut près tout essayé pour contourner le blocage de Free, rien n'y fait. La seule solution que je vois, serait de mettre en place un cryptage pour les paquets allant de chez moi à une IP connue (L'ami avec qui je veux jouer). Le schémas de fonctionnement serait:
La nintendo DS communiquerait en clair vers le serveur Nintendo pour l'authentification (C'est du TCP, pas de souci ça fonctionne déja). Puis quand elle communiquerait chez mon ami, je voudrais les faire passer en tunnel crypté, de façon à ce que l'UDP soit encapsulé dans du TCP crypté, puis décrypté chez mon ami...
Donc, chez mon ami à l'identique de chez moi, il faudrait une rêgle qui dise que tout ce qui vient de mon IP est à décrypter avant de DNATTER sur sa nintendo DS. Inversement, tout ce qui part de chez lui en provenance de sa DS et à destination de mon IP devra être tunnelé / crypté.
La difficulté est que la nintendo ne peut être que très peut paramétrée (IP, DNS, Passerelle, config WIFI) et donc si je mets en place un tunnel sur ma machine debian, comment lui "dis-je" de tunneler tout ce qui vient de la nintendo DS (192.168.0.110)?... Help ^^
Je sais que ma question peut sembler hors sujet Linux, mais il se trouve que la seule solution est celle que j'ai trouvé (Sauf si vous voyez autre chose), et je ne sais pas comment la mettre en oeuvre.
J'éspère avoir été assez clair, je sais que je n'ai pas les mots qui collent sur tout ça, j'ai essayé de m'exprimer le plus près possible du résultat voulu.
En vous remerciant de votre temps et de vos idées!
Pierrot.
J'ai une question assez technique à poser, je me permets donc un petit récap de la situation.
Depuis quelques temps, mon F.A.I. (Free pour ne pas le citer ^^) bloque partie des paquets p2p.
Si je fais le test (Entre autres) indiqué ici:
[www.journaldufreenaute.fr]
Je passe de 600Ko en download à 3Ko. Je sais donc que Free filtre sur le user agent, mais aussi sur le formatage des paquets. Il m'est très difficile de jouer sur internet lorsque le jeu utilise UDP, etc... Je n'utilise pourtant pas de client p2p (A part le FTP, mais est-ce un moyen de p2p?... Troll mode on ^^).
Or depuis peu, j'essaye de jouer à un jeu sur ma nintendo DS qui utilise exclusivement l'UDP pour communiquer. Ce qui bien sûr ne fonctionne jamais, vu que Free doit probablement cataloguer les paquets en p2p et les dropper ou les mettre en priorité très basse.
Mon réseau est conçu comme suit:
La Freebox est reliée à ma passerelle / serveur debian (Sarge) via de l'ethernet de base (62.xx.xx.xx, Eth1 pour l'exemple). Debian filtre et est connecté à un point d'accès sans fil (via eth0, 192.168.0.1). Les ordinateurs de mon réseau à la maison se connectent donc tous à ce routeur, de façon transparente. Le réseau chez moi est bien connecté à internet (Masquerading de eth0 sur eth1).
Quand je veux jouer sur le net avec ma DS, j'active une règle iptables qui dit que tous les paquets TCP / UDP venant d'internet sonts DNAT vers la nintendo DS, dont l'IP est 192.168.0.110. Quand quelqu'un essaye de se connecter, j'ai bien les quelques échanges que Free ne bloque pas qui transitent quand je "tcpdump | grep 192.168.0.110".
On a à peut près tout essayé pour contourner le blocage de Free, rien n'y fait. La seule solution que je vois, serait de mettre en place un cryptage pour les paquets allant de chez moi à une IP connue (L'ami avec qui je veux jouer). Le schémas de fonctionnement serait:
La nintendo DS communiquerait en clair vers le serveur Nintendo pour l'authentification (C'est du TCP, pas de souci ça fonctionne déja). Puis quand elle communiquerait chez mon ami, je voudrais les faire passer en tunnel crypté, de façon à ce que l'UDP soit encapsulé dans du TCP crypté, puis décrypté chez mon ami...
Donc, chez mon ami à l'identique de chez moi, il faudrait une rêgle qui dise que tout ce qui vient de mon IP est à décrypter avant de DNATTER sur sa nintendo DS. Inversement, tout ce qui part de chez lui en provenance de sa DS et à destination de mon IP devra être tunnelé / crypté.
La difficulté est que la nintendo ne peut être que très peut paramétrée (IP, DNS, Passerelle, config WIFI) et donc si je mets en place un tunnel sur ma machine debian, comment lui "dis-je" de tunneler tout ce qui vient de la nintendo DS (192.168.0.110)?... Help ^^
Je sais que ma question peut sembler hors sujet Linux, mais il se trouve que la seule solution est celle que j'ai trouvé (Sauf si vous voyez autre chose), et je ne sais pas comment la mettre en oeuvre.
J'éspère avoir été assez clair, je sais que je n'ai pas les mots qui collent sur tout ça, j'ai essayé de m'exprimer le plus près possible du résultat voulu.
En vous remerciant de votre temps et de vos idées!
Pierrot.
Poste le Monday 11 September 2006 23:28:25
Re: Tunnel de paquets UDP en fonction de leur source / destination?
Envoyé par:
oudoubah
De nom, je te conseillerais de te tourner vers vtund. Je ne l'ai jamais mis en place, mais il semble correspondre à ce que tu cherches.
En gros tu :
² crées un tunnel entre vos 2 machines
² crées une route par défaut pour l'adresse IP de la machine distante qui passe par le tunnel
Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"
En gros tu :
² crées un tunnel entre vos 2 machines
² crées une route par défaut pour l'adresse IP de la machine distante qui passe par le tunnel
Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"
Poste le Tuesday 12 September 2006 16:35:42
Re: Tunnel de paquets UDP en fonction de leur source / destination?
Envoyé par:
creativehazard
UP ^^
Bon il va falloir que tu (oudoubah) te lances dans une explication. Sauf si tu as dis ça genre "j'imagine que vtun fera l'affaire", parceque je ne comprend pas la finalité de ton idée.
Le but du jeu n'est surtout pas de relier mon LAN à celui de mon ami (façon VPN), car les consoles doivent conserver la notion d'IP "publique" pour communiquer. En effet, chaque console se connecte à un serveur central Nintendo, qui lui dis "L'autre console à laquelle tu dois te connecter est 12.34.56.78", donc IP public, surtout pas d'IP privées...
Le but serait de dire à ma passerelle (Sous debian) et à la sienne (sous Windows) de crypter toutes les communications entre mon IP et son IP, et d'encapsuler l'UDP en TCP (Là, façon vtun, mais juste pour le principe de cryptage / encapsulation).
Bon en même temps, j'ai fouinné sur google et n'ai pas compris avec juste "vtund" ce que je pouvais en faire dans mon exemple...
Un tuto / Lien / Idée SVP ^^
Encore une fois, la solution doit être compatible sous windows (Uniquement ma passerelle est sous linux, celle de mon ami est sous Windows XP).
Pierre.
Bon il va falloir que tu (oudoubah) te lances dans une explication. Sauf si tu as dis ça genre "j'imagine que vtun fera l'affaire", parceque je ne comprend pas la finalité de ton idée.
Le but du jeu n'est surtout pas de relier mon LAN à celui de mon ami (façon VPN), car les consoles doivent conserver la notion d'IP "publique" pour communiquer. En effet, chaque console se connecte à un serveur central Nintendo, qui lui dis "L'autre console à laquelle tu dois te connecter est 12.34.56.78", donc IP public, surtout pas d'IP privées...
Le but serait de dire à ma passerelle (Sous debian) et à la sienne (sous Windows) de crypter toutes les communications entre mon IP et son IP, et d'encapsuler l'UDP en TCP (Là, façon vtun, mais juste pour le principe de cryptage / encapsulation).
Bon en même temps, j'ai fouinné sur google et n'ai pas compris avec juste "vtund" ce que je pouvais en faire dans mon exemple...
Un tuto / Lien / Idée SVP ^^
Encore une fois, la solution doit être compatible sous windows (Uniquement ma passerelle est sous linux, celle de mon ami est sous Windows XP).
Pierre.
Poste le Wednesday 13 September 2006 23:38:15
Re: Tunnel de paquets UDP en fonction de leur source / destination?
Envoyé par:
creativehazard
Bon je crois que je n'ai pas été super clair, j'ai trop exposé le problème. Voilà dans l'idée ce que je cherche:
- Une machine en LAN X (deriere une IP publique A) émet un paquet UDP vers une IP publique B, vers son port 1000.
- Ce paquet passe par la passerelle A avant de sortir.
- La passerelle fait un genre de "mangling" sur ce paquet, le crypte, et l'encapsule dans du TCP.
- La passerelle achemine ce paquet vers B, mais sur son port 5000 par ex, en TCP.
- A l'autre bout, la machine B reçoit le paquet. Elle voit que sa provenance est A. Elle le décrypte donc, et DNAT le paquet UDP résultant vers la machine Y sur le port 1000, qui est l'autre machine en LAN...
- Dans le sens inverse (Depuis la machine Y derière
, itou ^^
La totalité de l'opération doit être transparente, un genre de tunnel qui puisse fonctionner sans qu'on ait acces au système d'exploitation de X et Y.
A bientot!
Pierre.
- Une machine en LAN X (deriere une IP publique A) émet un paquet UDP vers une IP publique B, vers son port 1000.
- Ce paquet passe par la passerelle A avant de sortir.
- La passerelle fait un genre de "mangling" sur ce paquet, le crypte, et l'encapsule dans du TCP.
- La passerelle achemine ce paquet vers B, mais sur son port 5000 par ex, en TCP.
- A l'autre bout, la machine B reçoit le paquet. Elle voit que sa provenance est A. Elle le décrypte donc, et DNAT le paquet UDP résultant vers la machine Y sur le port 1000, qui est l'autre machine en LAN...
- Dans le sens inverse (Depuis la machine Y derière
, itou ^^
La totalité de l'opération doit être transparente, un genre de tunnel qui puisse fonctionner sans qu'on ait acces au système d'exploitation de X et Y.
A bientot!
Pierre.
Poste le Wednesday 13 September 2006 23:46:19
Re: Tunnel de paquets UDP en fonction de leur source / destination?
Envoyé par:
chromosome
Bon, en fait tu veux un "truc" pour trapper tous les paquets UDP a destination d'une machine afin de les crypter. Ce qu'y n'est pas un tunnel, car tu ne veut pas toucher aux adresses. et en plus compatible Windows.
Et tous ca, car tu "crois" que ton provider analyse les paquets UDP et qu'en fonction de certains paquets il les drop.
C'est la que je pense que tu fais fausse route. Ca m'etonnerait qu'un provider Internet fasse ce genre de truc. Je pense qu'il a plutot un probleme sur le volume des paquets DP passant dans son reseau. Donc tu veux aussi le convertir en TCP, et toujours sans changer les adresses IP. Et c'est tout !!! Tu n'as rien besoin d'autre, une boite d'allumette aussi, ou un seche cheveux ?
Alors regarde du cote de netcat avec iptables.
Iptables pour rerouter le traffic vers ta machine netcat, etcat pour faire la transition. Tu auras peut-etre aussi besoin d'un truc du genre rinetd, mais la il faut voir (attention en complement, pas comme produit magique).
Maintenant netcat doit exister aussi sous Windows.
Avec ca tu as de quoi t'amuser non ?
Et tous ca, car tu "crois" que ton provider analyse les paquets UDP et qu'en fonction de certains paquets il les drop.
C'est la que je pense que tu fais fausse route. Ca m'etonnerait qu'un provider Internet fasse ce genre de truc. Je pense qu'il a plutot un probleme sur le volume des paquets DP passant dans son reseau. Donc tu veux aussi le convertir en TCP, et toujours sans changer les adresses IP. Et c'est tout !!! Tu n'as rien besoin d'autre, une boite d'allumette aussi, ou un seche cheveux ?
Alors regarde du cote de netcat avec iptables.
Iptables pour rerouter le traffic vers ta machine netcat, etcat pour faire la transition. Tu auras peut-etre aussi besoin d'un truc du genre rinetd, mais la il faut voir (attention en complement, pas comme produit magique).
Maintenant netcat doit exister aussi sous Windows.
Avec ca tu as de quoi t'amuser non ?
Poste le Thursday 14 September 2006 09:26:07
Re: Tunnel de paquets UDP en fonction de leur source / destination?
Envoyé par:
oudoubah
Tu peux utiliser ssh pour faire du port forwarding encapsulé dans du ssh. Peut être avec :
Ce qui part de ton port 1000 arrive sur le port 1000 client via un canal sécurisé.
Je crains que ton paquet n'aboutisse en TCP (à vérifier).
Sinon, peut être qu'en utilisant un autre port pour transiter cela fonctionnerait.
Pour la version sous windows, ça doit être faisable avec de bons outils.
Pour plus d'infos, man ssh ;-)
Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"
ssh -f -N -L1000:machinedistante:1000
Ce qui part de ton port 1000 arrive sur le port 1000 client via un canal sécurisé.
Je crains que ton paquet n'aboutisse en TCP (à vérifier).
Sinon, peut être qu'en utilisant un autre port pour transiter cela fonctionnerait.
Pour la version sous windows, ça doit être faisable avec de bons outils.
Pour plus d'infos, man ssh ;-)
Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"
Poste le Thursday 14 September 2006 12:04:26
Re: Tunnel de paquets UDP en fonction de leur source / destination?
Envoyé par:
creativehazard
Merci pour vos réponses,
Chromosome tu as l'air furax, ne le sois pas car c'est moi qui ais de bonnes raisons pour l'être... J'ai une bonne demi douzaine de choses qui me sont impossible de faire tant que je suis chez n'importe quel F.A.I. non dégroupé sauf Wanadoo, ça ne m'enchante pas.
Et, je te conseille vivement de faire ce test
[www.journaldufreenaute.fr]
Si tu es en Free non dégroupé, ou de le faire chez un ami... Tu te rendras compte de l'étendue des dégats, moi j'étais sur le cul de voir le résultat.
La preuve que Free annalyse les paquets. Ce test démontre que les paquets HTTP avec un user agent "eMule" sont changés en priorité je passe réellement de 600 - 700 ko /s à 3. Et à mon avis ça n'est qu'un des nombreux QoS que Free a mis en place.
Idem chez Club Internet (Et là, je ne le tient pas d'un site web, mais de leur support techique directement en essayant de régler un problème similaire chez un ami...).
Je pense que tu es résident en ville, et ce genre de problème vous n'en entendez jamais parler. Pour vous dégroupés, internet c'est super et sans accroc, détrompez vous, on en parle partout sur internet.
Tout ça, c'était juste pour le tu "crois" que ton FAI blabla. Ca m'énerve quand les gens me croient pas, venez habiter ailleurs qu'en dégroupé (Surtout que la belgique je crois pas qu'il y ait des masses de problèmes de ce genre, vos FAI brident pas). "Tu veux traper les paquets, RIEN QUE CA!"... J'ai pas trop le choix vois-tu
Merci en tout cas pour les infos, je vais regarder tous ces outils.
Maintenant pour la réponse d'oudoubah:
Si je fais du port fwding avec SSH, par exemple comme tu le proposes de port 1000 à port 1000, cela implique que quelque chose doit listener à l'autre bout? Ou comment préconises tu la chose? En tout cas je vais approfondir dans cette direction aussi.
Merci à vous deux pour votre temps!
Pierre.
P.S.: Chromosome, te demandes pas comment je sais que tu es en belgique: tu m'avais aidé pour un souci similaire, SSH très lent rappelles toi. Tu avais pris ma machine en SSH et cherché d'où ça pouvait venir. Et bien, figure toi que le problème est inhérent à tous les gens qui sont cablés au même DSLAM que moi, même fournisseur... Je t'assure, Free filtre les paquets, tests à l'appui, je suis pas du genre à dire ça sans avoir un minimum d'antécédents.
Chromosome tu as l'air furax, ne le sois pas car c'est moi qui ais de bonnes raisons pour l'être... J'ai une bonne demi douzaine de choses qui me sont impossible de faire tant que je suis chez n'importe quel F.A.I. non dégroupé sauf Wanadoo, ça ne m'enchante pas.
Et, je te conseille vivement de faire ce test
[www.journaldufreenaute.fr]
Si tu es en Free non dégroupé, ou de le faire chez un ami... Tu te rendras compte de l'étendue des dégats, moi j'étais sur le cul de voir le résultat.
La preuve que Free annalyse les paquets. Ce test démontre que les paquets HTTP avec un user agent "eMule" sont changés en priorité je passe réellement de 600 - 700 ko /s à 3. Et à mon avis ça n'est qu'un des nombreux QoS que Free a mis en place.
Idem chez Club Internet (Et là, je ne le tient pas d'un site web, mais de leur support techique directement en essayant de régler un problème similaire chez un ami...).
Je pense que tu es résident en ville, et ce genre de problème vous n'en entendez jamais parler. Pour vous dégroupés, internet c'est super et sans accroc, détrompez vous, on en parle partout sur internet.
Tout ça, c'était juste pour le tu "crois" que ton FAI blabla. Ca m'énerve quand les gens me croient pas, venez habiter ailleurs qu'en dégroupé (Surtout que la belgique je crois pas qu'il y ait des masses de problèmes de ce genre, vos FAI brident pas). "Tu veux traper les paquets, RIEN QUE CA!"... J'ai pas trop le choix vois-tu
Merci en tout cas pour les infos, je vais regarder tous ces outils.
Maintenant pour la réponse d'oudoubah:
Si je fais du port fwding avec SSH, par exemple comme tu le proposes de port 1000 à port 1000, cela implique que quelque chose doit listener à l'autre bout? Ou comment préconises tu la chose? En tout cas je vais approfondir dans cette direction aussi.
Merci à vous deux pour votre temps!
Pierre.
P.S.: Chromosome, te demandes pas comment je sais que tu es en belgique: tu m'avais aidé pour un souci similaire, SSH très lent rappelles toi. Tu avais pris ma machine en SSH et cherché d'où ça pouvait venir. Et bien, figure toi que le problème est inhérent à tous les gens qui sont cablés au même DSLAM que moi, même fournisseur... Je t'assure, Free filtre les paquets, tests à l'appui, je suis pas du genre à dire ça sans avoir un minimum d'antécédents.
Poste le Thursday 14 September 2006 22:18:31
Re: Tunnel de paquets UDP en fonction de leur source / destination?
Envoyé par:
chromosome
En fait je ne suis pas furax (du moins pas sur toi). Mais vos "solutions" internet en France sont franchement merdique. Ils font un tel combat sur les prix qu'ils vendent n'importe quoi, et qu'ils ne savent meme pas satisfaire leurs pretentions. Ici en Belgique, ok c'est plus cher, mais ca marche (du moins pour les plus grands)
Avec la solution d'oudoubah je ne suis pas sur que tu puisses encapsuler de UDP dans une session SSH. Et si tu le convertit en TCP avant, alors tu n'as plus de raison de le crypter.
Sinon je me souviens de ton probleme, et je t'avais signaler que tu perdais des paquets dans l'histoire.
Sinon tu peux toujours essayer ma solution, evidement pas ce qu'il y a de plus simple, mais le probleme ne l'est pas non plus :-)
Avec la solution d'oudoubah je ne suis pas sur que tu puisses encapsuler de UDP dans une session SSH. Et si tu le convertit en TCP avant, alors tu n'as plus de raison de le crypter.
Sinon je me souviens de ton probleme, et je t'avais signaler que tu perdais des paquets dans l'histoire.
Sinon tu peux toujours essayer ma solution, evidement pas ce qu'il y a de plus simple, mais le probleme ne l'est pas non plus :-)
Poste le Friday 15 September 2006 08:07:14
Re: Tunnel de paquets UDP en fonction de leur source / destination?
Envoyé par:
oudoubah
Passer en TCP permet de résoudre le problème de perte de paquet, mais avec un temps de communication plus long (il faut acquitter les paquets).
Si SSH le transforme en TCP, alors il faut une règle de filtrage pour retransformer tout ça.
Pour le forwarding de port, je ne l'ai jamais mis en place encore, donc c'est juste une piste ;-)
Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"
Si SSH le transforme en TCP, alors il faut une règle de filtrage pour retransformer tout ça.
Pour le forwarding de port, je ne l'ai jamais mis en place encore, donc c'est juste une piste ;-)
Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"
Poste le Friday 15 September 2006 10:52:20
Re: Tunnel de paquets UDP en fonction de leur source / destination?
Envoyé par:
creativehazard
Messieux ^^,
Merci pour vos deux solutions, qui je pense doivent êtrent possibles en creusant!
J'ai toutefois de grosses lacunes sous nux, je pense que je vais laisser tomber... pour le moment. Peut être que d'ici quelques mois je m'y mettrais (faute de temps pour l'instant :-/)
Même un port forwarding / tunnel tout simple me semble complexe, vu que dans mon cas si je fais ça il faudrait:
- Tunnel SSH de local:1000 à distant:1001 (Et de distant:1000 à local:1001) tcp.
- Une rêgle iptables qui dit: Tout ce qui sort de la console est à forwarder vers local:1000 (Hop dans le tunel!) Mais dans ce cas, la rêgle ne pourra forwarder que le TCP, car les si un paquet UDP arrive de la console et est forwardé vers le port local 1000, il sera droppé, car le listener SSH est UDP
- Une rêgle iptable qui dit: Tout ce qui arrive de local:1001 est à forwarder vers la console... Mais pour cette rêgle, comment récupérer le port original vers lequel était addressé le paquet?...
Enfin bon, je m'y retrouve pas lol
Je vous tiendrais au courrant.
Chromosome, je voulais pas m'énerver, mais sérieux tu peux pas imaginer comme c'est emm...dant de *savoir* que mon FAI filtre, et de rien pouvoir y faire
A bientot,
Pierre.
Merci pour vos deux solutions, qui je pense doivent êtrent possibles en creusant!
J'ai toutefois de grosses lacunes sous nux, je pense que je vais laisser tomber... pour le moment. Peut être que d'ici quelques mois je m'y mettrais (faute de temps pour l'instant :-/)
Même un port forwarding / tunnel tout simple me semble complexe, vu que dans mon cas si je fais ça il faudrait:
- Tunnel SSH de local:1000 à distant:1001 (Et de distant:1000 à local:1001) tcp.
- Une rêgle iptables qui dit: Tout ce qui sort de la console est à forwarder vers local:1000 (Hop dans le tunel!) Mais dans ce cas, la rêgle ne pourra forwarder que le TCP, car les si un paquet UDP arrive de la console et est forwardé vers le port local 1000, il sera droppé, car le listener SSH est UDP
- Une rêgle iptable qui dit: Tout ce qui arrive de local:1001 est à forwarder vers la console... Mais pour cette rêgle, comment récupérer le port original vers lequel était addressé le paquet?...
Enfin bon, je m'y retrouve pas lol
Je vous tiendrais au courrant.
Chromosome, je voulais pas m'énerver, mais sérieux tu peux pas imaginer comme c'est emm...dant de *savoir* que mon FAI filtre, et de rien pouvoir y faire
A bientot,
Pierre.
Poste le Friday 15 September 2006 15:31:55
Re: Tunnel de paquets UDP en fonction de leur source / destination?
Envoyé par:
creativehazard
Oups correction: "... car le listener SSH est UDP ..." = erreur, je voulais dire: "... car le listener SSH est TCP ..." bien sur!
A bientot!
A bientot!
Poste le Friday 15 September 2006 15:33:41
Ce forum !
Tunnel de paquets UDP en fonction de leur source / destination?
Un problème avec une commande du shell ? Comment utiliser la crontab ? Vous avez des soucis pour la gestion réseau sous Linux ? Pour vous la gestion des utilisateurs/groupes est du chinois ? Etc... Posez donc vos questions ici.
Sauf mention contraire, les documentations publiées sont sous licence Creative-Commons