Ouvrir un port

Support Debian
#1

Ben oui, je sais, c’est tout bête, mais là je sèche. C’est trop empirique, j’ai galéré et j’ai besoin de quelqu’un qui sait.

Je veux donc ouvrir le port 42354.

  • Je coupe le pare-feu (script du forum, je l’ai même effacé à la fin pour les essais)
  • je mets hors jeu /etc/network/interfaces (idem, à la fin, effacé)
  • je n’ai que ce pc de branché, en filaire (un pc en wifi, mais pas relié par le réseau local, et en plus, éteint)
  • je redémarre le pc, il n’y a donc plus que wicd qui a la main, et le réglage de mon modem. En automatique sur eth0, wicd se connecte en 192.168.1.3

données du modem, une antiquité, Tecom AH4222

[code]Adresse IP du réseau distant (WAN) :
86.66.x.y
10.156.a.b

  • TX/RX: 0/0
  • Adresse du serveur DNS primaire : 109.0.66.10
  • Adresse du serveur DNS secondaire : 109.0.66.20
  • Adresse de la passerelle par défaut : 10.156.c.d [/code]

86.66.x.y est l’adresse ip de eth0
10.156.a.b est l’adresse de wlan0

Le réseau local

[code]Adresse IP 192.168.1.1
Masque de sous-réseau 255.255.255.0

X Activer l’UPnP
X Activer l’IGMP Snooping

Désactiver le serveur DHCP

X Activer le serveur DHCP

Adressage IP - Début: 192.168.1.2
Adressage IP - Fin: 192.168.1.196
Durée du bail(en heures): 168[/code]

Réglage de wicd, en ip fixe (propriétés) - j’ai fait les mêmes manips en automatique sans ip fixe, ça ne marchait pas.

X Utiliser des adresses IP statiques IP 192.168.1.3 masque sous réseau 255.255.255.0 passerelle 192.168.1.1 Toutes les cases DNS, sans nuance: 109.0.66.20

La connexion fonctionne avec ces réglages

Réglages du modem pour ouvrir le port, d’abord via NAT “serveurs virtuels”, dont il est dit “Le Serveur virtuel vous permet la redirection du trafic entrant du réseau distant (WAN) vers un serveur interne possédant une adresse IP privée sur le réseau local (LAN)”. Ca devrait passer par là, et on me demande ceci:

Port Externe - Début Port Externe - Fin Protocole Port interne - Début Port interne - Fin, où je rentre le numéro du port 42354, et une adresse ip du serveur virtuel, où j’ai rentré tout ce qui était possible entre 192.168.1.0 et 192.168.1.3, puis mon adresse ip 86.66.x.y

Rien.

Essai via NAT, port Trigerring, “NB: la fonction de port trigerring permet d’ouvrir dynamiquement un port du firewall, si une application locale exécute une requête TCP/UDP vers une application distante et inversement.”, OK, donc je rentre le numéro du port 42354

Application Trigger Ouvrir Supprimer Nom Protocole Plage des ports Protocole Plage des ports Début Fin Début Fin

Que dalle. J’ai essayé avec deux numéros de ports différents. Alors quoi ??

Pour info, le contenu de network/interfaces

[code]# This file describes the network interfaces available on your system

and how to activate them. For more information, see interfaces(5).

The loopback network interface

auto lo
iface lo inet loopback

The primary network interface

allow-hotplug eth0
iface eth0 inet dhcp
[/code]

et le script du parefeu modifié pouur ouvrir les ports:

[code]# Services que le système offrira au réseau, à séparer avec des espaces

ftp : 21, ssh : 22, serveur web : 80, cups : 631, jabber : 5222

TCP_SERVICES="42354"
UDP_SERVICES=“42354”

Services que le système utilisera du réseau

(défaut : autorise tout en sortie)

REMOTE_TCP_SERVICES="“
REMOTE_UDP_SERVICES=”"

Pour une machine faisant office de routeur avec NAT,

changer la valeur de la variable ISROUTERNAT à 1.

ISROUTERNAT=false[/code]

ifconfig -a

[code]eth0 Link encap:Ethernet HWaddr e0:cb:4e:f7:b6:6e
inet adr:192.168.1.3 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::xxx:xxx:xxx:b66e/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13575 errors:0 dropped:0 overruns:0 frame:0
TX packets:11808 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:12452549 (11.8 MiB) TX bytes:1409634 (1.3 MiB)
Interruption:43 Adresse de base:0xc000

lo Link encap:Boucle locale
LOOPBACK MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)[/code]

Je rappelle que j’avais désactivé le parefeu (avec un essai avec ISROUTERNAT=1, mais peut être pas dans les bonnes conditions) et /network/interfaces

Merci !

#2

Si tu ouvres dans Iptables, ça ne fonctionne pas ?

Puis rajeunir “mon_parefeu” ou autre nom donné par toi, avec :

#3

Avec la commande, parefeu rechargé ou éteint, /network/config conservé, les ports indiqués dans les “serveurs virtuels” et le port trigerring", ça n’ouvre pas. Testé via plusieurs sites net, et par ailleurs:

netstat -a Connexions Internet actives (serveurs et établies) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat tcp 0 0 *:41294 *:* LISTEN tcp 0 0 *:sunrpc *:* LISTEN tcp 0 0 192.168.1.3:36248 wb-in-f190.1e100.:https ESTABLISHED tcp6 0 0 [::]:sunrpc [::]:* LISTEN tcp6 0 0 [::]:45560 [::]:* LISTEN udp 0 0 192.168.1.3:56816 localhost:ntp ESTABLISHED

J’ai fait les tests parefeu coupé, mais avec ISROUTERNAT à “true”, faut-il bien laisser ces lignes en l’état (connection filaire=eth0) ?

[code]# ethx correspond à l’interface du LAN

ethy correspond à l’interface reliée à la truc-box

ethx="eth1"
ethy=“eth0”[/code]

#4

Ce qui “ouvre” un port, c’est qu’une application locale écoute dessus. D’après la sortie de netstat -a, ce n’est visiblement pas le cas du port 42354. Tout le reste (routeur, firewall) ne concerne que la redirection ou l’autorisation du port, pas l’ouverture.

Pourquoi veux-tu “ouvrir” ce port ?

#5

Pour utiliser bitorrent (proprement, et à la fin pour réussir à ouvrir le port, j’y ai passé deux heures…). Transmission m’indique que le port est fermé. En refaisant les manips ce matin, j’ai changé par erreur le numéro du port, qui est maintenant partout 43254

Si je laisse tourner, j’ai, avec netstat -a

tcp 0 0 *:41294 *:* LISTEN tcp 0 0 *:sunrpc *:* LISTEN tcp 0 0 *:43254 *:* LISTEN

Et c’est bien Transmission qui écoute

netstat -ap Connexions Internet actives (serveurs et établies) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name tcp 0 0 *:41294 *:* LISTEN 1971/rpc.statd tcp 0 0 *:sunrpc *:* LISTEN 1940/rpcbind tcp 0 0 *:43254 *:* LISTEN 1569/transmission-g

Si être écouté, c’est être ouvert, l’interface graphique de Transmission donnerait une fausse info ?

#6

Je ne connais pas transmission ni son fonctionnement.
En tout cas maintenant le port 43254 est ouvert en écoute sur ta machine.
Si la machine a un pare-feu, il faut autoriser ce port TCP en entrée (et pas 42354).
Si la machine est derrière un routeur NAT, il faut créer une redirection du port en TCP avec début/fin/externe/interne=43254 vers l’adresse de la machine, 192.168.1.3. Pas besoin de trigger.

#7

Merci, ça marche. Pas au début, mais en étant sûr de ce qu’il fallait faire, j’ai pu faire le tri dans les causes de plantages, en nettoyant le tout - plus de trigerring et seulement une redirection du port vers 192.168.1.3 (serveur virtuel dans le vocabulaire de mon routeur).

Le plus probable: il fallait déclarer l’ouverture des ports en tcp ET udp pour que Transmission détecte le port comme ouvert (j’ignore si c’était uniquement pour le test, ou pour son fonctionnement en général).

Moins probable: j’avais des restes d’anciennes règles de parefeu (j’utilisais guarddog avec squeeze), et j’ai tout nettoyé avec iptables -F, puis redémarré le parefeu.

#8

En tout cas avec netstat on ne voyait pas de port UDP ouvert par transmission.

#9

Oui, du coup j’ai vérifié, ça passe en TCP seul aussi, et ce sont sans doute d’anciennes règles iptables qui jouaient (je croyais avoir purgé Guarddog, pourtant).