Discussion :

[Neckara]

Bonjour,

J'ai actuellement un vieil ordi portable (qui a un peu plus de 2 ans) sous débian dont je me sert comme serveur.

J'ai commencé à modifié l'iptables en interdisant par défaut toutes les connections entrantes, sourtantes et les foreward de wlan0 (il est connecté par internet uniquement par ce moyen)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

Bien sûr j'ai ouvert par la suite un port pour le ssh, etc...

Maintenant je voudrais que n'importe qui, en essayant de passer par le port 80 de mon serveur soit redirigé vers un serveur mumble dont je connais l'ip et le port. Mon serveur est dans un réseau wifi domestique et possède donc une adresse ip réseau. Le réseau redirige déjà automatiquement les requêtes vers le port 80 vers mon serveurs.

En faisant quelques recherches, je suis tombé sur ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
iptales -t nat -A PREROUTING -d (adresses de destination) --to-destination (ip de destination modifiée) -j DNAT
iptales -t nat -A POSTROUTING -s (adresses sources d'entrée) -j SNAT --to-source (adresse source à appliquer)

Mais je dois avouer que je m'embrouille un petit peu.

J'ai tenté de faire quelques essais et de bidouiller un peu sans réussite.

Pourriez-vous me donner quelques indications svp?

[Neckara]

Voici ce que j'ai réussi à faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
iptables -A INPUT -i wlan0 -p TCP --dport 80 -j PREROUTING
iptables -A INPUT -i wlan0 -p UDP --dport 80 -j PREROUTING
 
 
iptables -A INPUT -i wlan0 -p TCP --dport 8014 -j PREROUTING
iptables -A INPUT -i wlan0 -p UDP --dport 8014 -j PREROUTING
 
iptables -t nat - A PREROUTING -p TCP --dport 80 --to-destination -j 91.121.7.94:8014 DNAT
iptables -t nat - A PREROUTING -p UDP --dport 80 --to-destination -j 91.121.7.94:8014 DNAT
 
#prerouting des paquets recu du serveur mumble???
 
iptables -t nat -A POSTROUTING -p TCP --dport 80 -j SNAT --to-source [mon-ip]
iptables -t nat -A POSTROUTING -p UDP --dport 8014 -j SNAT --to-source [mon-ip]
iptables -t nat -A POSTROUTING -p TCP --dport 80 -j SNAT --to-source [mon-ip]
iptables -t nat -A POSTROUTING -p UDP --dport 8014 -j SNAT --to-source [mon-ip]

Déjà, je ne sais pas si dans les sources je dois mettre l'adresse ip publique ou l'adresse ip de l'ordinateur au sein du réseau.

Ensuite, pour renvoyer les paquets vers celui qui c'est connecté, je ne sais pas du tout comment faire...

[Obsidian]

Hello,

J'ai commencé à modifié l'iptables en interdisant par défaut toutes les connections entrantes, sourtantes et les foreward de wlan0 (il est connecté par internet uniquement par ce moyen)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

Attention, quand tu utilises -P, tu définis la « politique » de la chaîne, c'est-à-dire son comportement par défaut quand aucune règle ne correspond. Ce faisant, tu ne filtres pas seulement « wlan0 », mais tout ce qui parvient, repart ou transite par une interface réseau (y compris « lo », le cas échéant).

Voici ce que j'ai réussi à faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
iptables -A INPUT -i wlan0 -p TCP --dport 80 -j PREROUTING
iptables -A INPUT -i wlan0 -p UDP --dport 80 -j PREROUTING
 
 
iptables -A INPUT -i wlan0 -p TCP --dport 8014 -j PREROUTING
iptables -A INPUT -i wlan0 -p UDP --dport 8014 -j PREROUTING

Ça, ça ne fonctionnera pas, parce que « PREROUTING » n'est pas une chaîne de la table « filter ». Connais-tu bien le fonctionnement global de ipchains et iptables ?

[Neckara]

Attention, quand tu utilises -P, tu définis la « politique » de la chaîne, c'est-à-dire son comportement par défaut quand aucune règle ne correspond. Ce faisant, tu ne filtres pas seulement « wlan0 », mais tout ce qui parvient, repart ou transite par une interface réseau (y compris « lo », le cas échéant).

Derrière cela j'ai autorisé toutes les connexions de eth0 mais je ne l'ai pas fait avec lo, je vais donc l'autoriser.

Ça, ça ne fonctionnera pas, parce que « PREROUTING » n'est pas une chaîne de la table « filter ». Connais-tu bien le fonctionnement global de ipchains et iptables ?

On a très rapidement survolé le sujet en TP de réseau et on a juste fait des DROP/ACCEPT/REFUSE/LOG sur des INPUT et OUTPUT et c'est la seule chose que je verrais en cours...

Comme j'avais vu qu'on pouvais créer nos propres chaînes, j'ai cru que PREROUTING en étais une mais apparemment je me trompais...

iptables je vois comment il fonctionne avec OUTPUT/INPUT/FORWARD par contre avec les NAT, il m'a fallu un certain temps pour comprendre.

Pour les ipchains, si j'ai bien compris, un paquet est intercepté, un démon regarde les règles et applique la première règle qui correspond.

L'ipchains serait la liste ordonnée des règles qui seront appliqué à un paquet?
Une sorte de "chemin" en gros.


EDIT : si j'ai bien compris :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
iptables -t nat -A PREROUTING -j DNAT -i wlan0 -p tcp --dport 80 --to-destination 91.121.7.94:8014
# Tous les paquets provenant de wlan0 via le port 80 sont redirigé vers le serveur mumble via le port 8014
iptables -t nat -A POSTROUTING -j MASQUERADE -o wlan0 -p tcp --dport 80 -d 91.121.7.94
#tous les paquets qui sont reçu par le port 80 de wlan0 et à destination du serveur mumble reçoivent comme ip source l'ip "routeur" du serveur ? Ainsi la réponse du serveur mumble sera envoyé sur mon serveur.

Est-ce juste? Dans ce cas là, comment faire pour envoyer la réponse du serveur mumble de mon serveur au client?

[Obsidian]

En fait, « ipchains » était la génération précédente du filtre réseau Linux (jusque dans les noyaux 2.4 si je ne me trompe pas). Pour faire simple, ipchains était iptables mais muni uniquement de la table « filter ».

Dans une même table, tu as des chaînes prédéfinies (par exemple « INPUT », « OUTPUT », « FORWARD ») que tu peux enrichir ou vider, mais pas supprimer. Tu as des cibles prédéfinies (par exemple « ACCEPT », « REJECT », « DROP ») et tu peux enfin créer tes propres chaînes, pour créer des sortes de sous-programmes ou pour définir des profils de trafic (par exemple « TRAFICDMZ »).

À l'époque d'ipchains, il y avait une cible spéciale : MASQUERADE, qui permettait justement de transformer la machine en proxy transparent sur une certaine partie du trafic, pour faire par exemple du partage de connexion.

Depuis « iptables », tu as désormais des tables supplémentaires : l'idée est que le paquet est examiné simultanément et indépendamment dans chacune des tables. Autrement dit, les règles de la table filter vont vérifier si un paquet doit être admis ou éliminé, et celles de « nat » vont vérifier si ses coordonnées doivent être réécrites ou pas.

C'est donc tout naturellement que la règle « MASQUERADE » a quitté la table « filter » pour rejoindre « nat ».

Le nat est devenu omniprésent dans la gestion d'un réseau et constitue une activité à part entière qui lui vaut de mériter sa propre table. Mais dans le même esprit, on a tout naturellement créé une troisième table « mangle » (« déchiqueter, mettre en pièce ») qui permet en fait de faire toutes les autres altérations sur un paquet, notamment sur ses flags.

Pour finir, quand j'ai dit « simultanément », ce n'est pas tout-à-fait vrai : il y a un ordre d'exécution. Notamment, dans le cas du NAT, si tu veux réécrire l'adresse de destination, cela doit se faire avant le routage ! D'où l'existence des règles PREROUTING et POSTROUTING. Dès lors que le paquet a été dûment modifié, il peut être présenté à la table de routage et donc, juste avant, au filtre (donc à la table filter).

Je te laisse faire toi-même une petite recherche avec IPTables flowchart pour voir comment tout cela circule.

[Neckara]

Merci pour cette réponse.

Je comprend déjà un peu mieux comment marche la table NAT.

Donc si je résume il va falloir :

chemin client -> serveur mumble :
- utiliser PREROUTING pour écrire dans le paquet en adresse de destination l'adresse du serveur mumble.
- autoriser le forward vers le serveur mumble
- interdire le forward du serveur mumble vers le serveur mumble
- utiliser POSTROUTING pour écrire dans le paquet en adresse source l'adresse du serveur intermédiaire

chemin serveur mumble -> client
- autoriser le forward à partir du serveur mumble

par contre pas besoin d'autoriser INPUT et OUTPUT c'est bien cela?

Je n'ai pas tout à fait compris MASQUERADE, si j'ai compris, en l'utilisant pour écrire l'adresse source, il fera en sorte que le paquet passe "dans l'autre sens" donc pour le chemin inverse, il suffit juste d'autoriser un forward?

[Obsidian]

Donc si je résume il va falloir :

chemin client -> serveur mumble :
- utiliser PREROUTING pour écrire dans le paquet en adresse de destination l'adresse du serveur mumble.
- autoriser le forward vers le serveur mumble
- interdire le forward du serveur mumble vers le serveur mumble
- utiliser POSTROUTING pour écrire dans le paquet en adresse source l'adresse du serveur intermédiaire ← Seulement en sortie !

chemin serveur mumble -> client
- autoriser le forward à partir du serveur mumble

par contre pas besoin d'autoriser INPUT et OUTPUT c'est bien cela?

Bien sûr que si ! Si ton serveur n'est pas la machine sur laquelle tu définis ces règles, alors ton paquet va entrer, transiter sur ta machine et repartir vers le ton serveur via la bonne carte réseau (qui peut être la même, et qui peut être en Wi-Fi) mais sur un sous-réseau complètement différent (a priori un 192.168.x.x). Donc les trois règles du filtre, INPUT, FORWARD et OUTPUT s'appliquent.

Les règles PREROUTING de la table nat vont s'appliquer également s'il y a lieu, avant le routage et, donc, avant de passer au filtre. À l'inverse, une fois aura passé la table de routage et sera sur le point de repartir vers la bonne interface, les règles de la table POSTROUTING pourront s'appliquer juste avant l'émission.

Par contre :
— Interdire « mumble » vers « mumble » n'a aucun sens si le serveur en question ne se trouve pas sur la machine en question. De tels paquets resteront toujours sur ton réseau local et en fait, ne sortiront jamais de la machine du serveur. Donc, ton firewall n'en verra jamais la couleur. En plus, ce n'est pas souhaitable : des éléments de ton serveur peuvent très bien faire appel eux-mêmes à des RPC ou d'autres sections du site de manière légitime ;
— Tu n'écriras pas non plus, en expéditeur, l'adresse du serveur intermédiaire, sinon ton serveur répondra au serveur intermédiaire et pas au client. En plus, tu ne sauras pas qui te contacte. Donc, non, SAUF si tu utilises le masquerading.

Je n'ai pas tout à fait compris MASQUERADE, si j'ai compris, en l'utilisant pour écrire l'adresse source, il fera en sorte que le paquet passe "dans l'autre sens" donc pour le chemin inverse, il suffit juste d'autoriser un forward?

Non, le masquerading consiste à à transformer toutes les adresses source d'un trafic donné en celle de la machine intermédiaire et ce, compte tenu de l'interface par laquelle les paquets vont sortir. C'est le principe du proxy, et c'est ça qui te permet de partager une même connexion Internet, avec une seule adresse IP publique, entre plusieurs machines locales. C'est ce qui est utilisé sur toutes les « box » Internet quand elles sont configurées en mode routeur (ce qui est en partie un abus de langage).

L'idée est que, pour chaque paquet sortant, le noyau va conserver la trace de l'identifiant du paquet ainsi que la machine émettrice. Si un paquet est reçu en retour concernant cette connexion en particulier, le noyau s'en souviendra et reroutera automatiquement le paquet vers le bon expéditeur initial. Ceci implique néanmoins plusieurs choses :

— Il faut garder la trace du dernier paquet de chaque connexion ouverte. C'est un système stateful qui consomme donc de la mémoire et des ressources CPU pour en faire la gestion, même si ça reste très raisonnable, surtout qu'on en consomme déjà pour router les paquets de manière ordinaire ;
— Ça ne peut fonctionner que si le protocole utilisé permet justement de faire une chaîne en faisant référence au paquet précédent à chaque fois. Donc, pas possible de faire du masquerading sur de l'UDP ;
— Ceci interdit de fait toute nouvelle connexion entrante même en l'absence de règle de filtrage explicite puisque le noyau ne peut pas savoir a priori à qui ce paquet entrant est censé être destiné. En ce sens, la démocratisation des box mises en routeur par défaut (surtout depuis l'apparition du Wi-Fi qui a complètement désolidarisé l'équipement réseau de la machine qui l'exploite) a beaucoup participé à renforcer la sécurité chez les particuliers ;

Du coup, dans ton cas, soit tu fais du NAT explicite en modifiant simplement l'adresse de destination sur les paquets entrants, et l'adresse source sur les paquets sortants, soit tu fais une seule règle qui fait du masquerading en entrée et tu laisses le noyau gérer toutes les traductions mais tu deviens plus sensible aux attaques par déni de service et ton serveur ne peux plus connaître les adresses publiques de ses clients.

[Neckara]

Mon serveur mumble va répondre sur le port 8014 or le client écoute sur le port 80 donc je suis obligé d'utiliser MASQUERADE si j'ai bien compris.

Par contre il faut que je me renseigne car je ne sais pas si Mumble n'utilise pas un peu d'UDP...

Je vais déjà essayer de faire tout cela^^

Merci pour votre aide.

[Obsidian]

Bon, j'ai parlé trop vite en banissant d'emblée le masquerading UDP, surtout que c'est un cas relativement fréquent (ne serait-ce que pour le D.N.S.). En fait, la plupart du temps, le port source d'une connexion, TCP ou UDP, n'est pas spécifié par le client. C'est donc sa machine qui en choisit un au hasard et qui s'arrange pour les faire tourner, si possible en les mélangeant, et en blacklistant temporairement (de l'ordre d'une minute) tout numéro de port déjà utilisé s'il en reste par ailleurs, pour limiter les ambiguïtés sur le réseau. En fait, deux connexions clientes ouvertes depuis une même machine, que ce soit en UDP ou TCP, auront chacune un port différent.

Partant de ce constat, une machine peut décider de faire du PAT et s'appuyer sur les numéros de ports en UDP en estimant qu'une même application cliente est toujours à l'écoute du port en question, même si UDP ne spécifie nullement que ce soit le cas.

[Neckara]

Je vais essayer de relire votre post plus tard à tête reposée.

Pour l'instant voici ce que j'ai fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
#pour mumble :
iptables -A INPUT -i wlan0 -p TCP --dport 80 -j ACCEPT
iptables -A INPUT -i wlan0 -p TCP --dport 8014 -j ACCEPT
iptables -A INPUT -i wlan0 -p UDP --dport 80 -j ACCEPT
iptables -A INPUT -i wlan0 -p UDP --dport 8014 -j ACCEPT
 
iptables -A OUTPUT -o wlan0 -p TCP --dport 80 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p TCP --dport 8014 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p UDP --dport 80 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p UDP --dport 8014 -j ACCEPT
 
 
iptables -A FORWARD -o wlanO -i wlanO -p TCP --dport 80 -j ACCEPT
iptables -A FORWARD -o wlanO -i wlanO -p TCP --dport 8014 -j ACCEPT
 
iptables -A FORWARD -o wlanO -i wlanO -p UDP --dport 80 -j ACCEPT
iptables -A FORWARD -o wlanO -i wlanO -p UDP --dport 8014 -j ACCEPT
 
iptables -t nat -A PREROUTING -j DNAT -i wlan0 -p tcp --dport 80 --to-destination 91.121.7.94:8014
iptables -t nat -A POSTROUTING -j MASQUERADE -o wlan0 -p tcp --dport 80 -d 91.121.7.94

Par contre ça n'a pas l'air de marcher pour le TCP vu que lorsque j'essaye de lancer mumble, il me dit que "La connexion au serveur à échoué : L'hôte distant a fermé la connexion."

[Obsidian]

En fait, dans le cas où toutes les adresses des serveurs sont statiques, il faut faire du NAT statique. Oublie le masquerading.

— En entrée : tout paquet venant de l'extérieur, donc soit d'une interface dédiée si c'est le cas (et j'espère que ça l'est) soit d'une adresse qui ne correspond PAS à une adresse interne et à destination du port 80 est modifié pour recevoir une adresse de destination correspondant à celle du serveur Web et le port de destination 8014 ;
— En sortie : tout paquet provenant de l'adresse de ton serveur et du port source 8014 reçoit une adresse source correspondant à celle de ton firewall et un port source égal à 80.

N'oublie pas non plus d'activer le transfert de paquet (forwarding) avec /proc/sys/net/ipv4/ip_forward, car il ne le sera jamais par défaut. Les machines sont conçues pour réagir par défaut comme des hôtes terminaux ordinaires avant de se comporter comme des équipements de transport.

Et bien sûr, si c'est bien un serveur Web qui est interrogé, tu n'établis ces règles que pour TCP.

[Neckara]

J'ai déjà activé le forwarding.


En fait, j'ai :

Un serveur mumble hébergé par un tiers dont l'ip est 91.121.7.94.
Ce serveur utilise le port 8014.

Un serveur privé qui est relié à internet via un réseau wi-fi free (adresse ip publique fixe, adresse ip au sein du réseau fixe). La freebox redirige tous les paquets du port 80 vers ce serveur (l'internet marche tout de même sur les autres ordinateurs).


Il arrive qu'avec quelques amis on se connecte sur différents réseaux wi-fi mais le port 8014 est très souvent bloqué (par défaut on ferme tous les ports et on ouvre que ceux qui sont 'utile').
Malheureusement, on ne peut pas demander à l'hébergeur Mumble de changer le port.

Je voulais donc utiliser mon serveur privé pour rediriger le port 80 vers le port 8014.

[Obsidian]

Donc, en fait, ce que tu veux faire, c'est :

— Recevoir des paquets publics de l'extérieur sur le ports 80 de ta box ;
— Faire rediriger ces paquets vers une machine privée interne (la tienne) ;
— Relayer ces paquets en les renvoyant vers l'extérieur vers le port 8014 du serveur Mungle ;
— Effectuer le parcours inverse pour renvoyer le tout vers les machines clientes ;
— Le tout en passant par ta Freebox qui, elle, effectue déjà du masquerading pour permettre aux autres machines de ton réseau de continuer à surfer normalement sur le Net. Et en transitant par le Wi-Fi.

C'est assez éloigné de ton post initial et ça risque d'être un peu lent à l'usage.

C'est ta freebox qui va faire du masquerading sur les deux liaisons : depuis les clients. Par contre, il va falloir demander à la Freebox de laisser rentrer vers ta machine les paquets en provenance du serveur Mumble et du port source 8014. Ensuite, un NAT statique dans les deux sens sur ta machine interne devrait suffire, mais il y aura beaucoup de tests à faire pour mettre cela au point.

Et évidemment, tout ceci n'est valable qu'à partir du moment où le port 80 est physiquement ouvert depuis l'intérieur sur les sites d'où tu comptes contacter ton serveur. Si c'est un proxy HTTP qui permet d'aller sur le Web, c'est fichu.

[Neckara]

Bonjour,

Merci pour ta réponse.
Je sais que ça va être assez lent à l'usage, mais je n'ai pas tellement le choix^^
Sinon il faudrait que je me loue un serveur privé juste pour cela

J'ai déjà redirigé tous les paquets reçu du port 80 vers le port 80 de mon serveur privé.

Il faut donc que je redirige tous les paquets reçu du port 8014 vers le port 8014 de mon serveur privé.


ensuite, sur mon serveur privé, je redirige tous les paquets reçu sur le port 80 vers le port 8014 en mettant en destination le serveur mumble et en source 192.168.0.14 (ip serveur privé)

Et pour les paquets reçus dans l'autre sens, je les redirige vers 192.168.0.0 en mettant en source 192.168.0.14

C'est bien cela?

[Neckara]

Bonjour,

J'ai malencontreusement fermé tous les ports sur mon "serveur", je vais donc devoir attendre ce week-end pour pouvoir effectuer toute autre modification.

[Obsidian]

J'ai malencontreusement fermé tous les ports sur mon "serveur", je vais donc devoir attendre ce week-end pour pouvoir effectuer toute autre modification.

« Achievement Unlocked » comme on dit chez les gamers ! :-) Tu viens d'être confronté à ce que tout admin réseau a vécu au moins une fois. Si tu ne veux pas être ennuyé, fais une crontab qui réinsère les bonnes règles à intervalles réguliers, mais n'oublie pas de la retirer une fois ta config terminée.

Il faut donc que je redirige tous les paquets reçu du port 8014 vers le port 8014 de mon serveur privé.

Non, justement ! Dans ce sens-là, il faudra rediriger vers ton serveur les paquets venant du serveur Mumble et provenant du port source 8014 !

Pour le reste, le fait que ta Freebox fasse du masquerading dans un sens (intérieur vers extérieur) mais pas dans l'autre va t'obliger à peaufiner ta config' avec beaucoup de circonspection. Si ton serveur Mumble peut fonctionner uniquement en TCP et à l'initiative du client, tu n'as rien à faire. S'il doit (et pas seulement s'il peut) utiliser l'UDP en parallèle, ce sera plus délicat. Et si le serveur peut prendre l'initiative d'ouvrir des connexions, là, ça va devenir compliqué.

[Neckara]

Merci pour ta réponse,

« Achievement Unlocked » comme on dit chez les gamers ! :-) Tu viens d'être confronté à ce que tout admin réseau a vécu au moins une fois. Si tu ne veux pas être ennuyé, fais une crontab qui réinsère les bonnes règles à intervalles réguliers, mais n'oublie pas de la retirer une fois ta config terminée.

Je n'y aurais jamais pensé, c'est une idée assez géniale

Non, justement ! Dans ce sens-là, il faudra rediriger vers ton serveur les paquets venant du serveur Mumble et provenant du port source 8014 !

Pour le reste, le fait que ta Freebox fasse du masquerading dans un sens (intérieur vers extérieur) mais pas dans l'autre va t'obliger à peaufiner ta config' avec beaucoup de circonspection. Si ton serveur Mumble peut fonctionner uniquement en TCP et à l'initiative du client, tu n'as rien à faire. S'il doit (et pas seulement s'il peut) utiliser l'UDP en parallèle, ce sera plus délicat. Et si le serveur peut prendre l'initiative d'ouvrir des connexions, là, ça va devenir compliqué.

ça m'a l'air un peu trop compliqué pour moi...
A ce niveau là, n'est-il pas plus simple de se connecter à distance sur un ordi, et de lancer mumble sur cet ordi?

Par contre, comme ma chipset graphique de mon ancien portable est un peu dessoudée, je ne sais pas du tout si ça pourrais le faire (sinon faudra utiliser un PC encore plus vieux )

Faudrait donc que je voie un peu ce que je pourrais faire à ce niveau là.

[Obsidian]

ça m'a l'air un peu trop compliqué pour moi...
A ce niveau là, n'est-il pas plus simple de se connecter à distance sur un ordi, et de lancer mumble sur cet ordi?

Si, mais ce n'est pas ce que tu veux faire, il me semble. Si l'idée est d'offrir un relais privé à tes copains quand ils sont au bureau ou à la fac, le problème restera le même (à moins que j'aie compris quelque chose de travers, ce qui est encore possible).

Cela dit, si tes clients potentiels ont accès à ssh, alors tu peux directement t'en servir pour ouvrir un tunnel : jette un œil aux options -L et -R.

[Neckara]

Les tunnels sont assez intéressants, mais à moins d'avoir un compte sur le serveur mumble et en espérant que toutes les sockets soient en TCP, doute que ça m'avance dans ce cas là. Mais faudra que je retienne ces deux options^^

Je pensais plutôt à un ssh -X (si je ne me trompe pas) ainsi je pourrais théoriquement lancer des applications graphiques tel que mumble (?) et comme je passe par un port non bloqué pour le ssh ça devrait marcher.
Après, je ne pense pas que je pourrais parler, mais je pourrais au moins écouter et écrire ce qui est tout de même mieux que rien.

[Invité]

Super interventions Obsidian, merci, j'ai appris

Je bricole avec Linux depuis maintenant 3 mois, essentiellement pour les "aspects Networking"... Les iptables, il arrive un moment où on ne peut pas y échapper
J'ai essayé plusieurs GUI mais on n'arrivera jamais à un niveau de granularité qu'on peut avoir en faisant les choses à la mano.

Dans mes URL, j'ai cet excellent tuto en fraçais :

http://www.nbs-system.com/blog/howto-iptables.html

et puis il y a aussi le site de netfilter.org qui est pas mal du tout :

http://www.netfilter.org/documentation/

Steph