Probleme de firewall Debian 11 [Résolu]

Nouh · 15 mars 2022

Bonjour a tous, tout nouveau sur le forum, je viens pour vous demander de l' aide !

Avec un ami, nous nous sommes mis en tete de faire un petit serveur que nous avons monté ensemble et qui réside dans ma cave. Il est sous Debian 11 et nos seules connaissances en Linux étant nos cours de BTS SIO, autant vous dire qu'on avance au pas a pas.

Nous avons fais un raid, fais notre acces SSH ( port 2222 ), un partage de fichier avec FUSE en SFTP, et nous souhaitons désormais faire un petit serveur Minecraft. Le probleme est que j'ai ouvert le port 25565 avec iptables en OUTPUT et INPUT en TCP et UDP, impossible de me connecter au serveur. Pourtant avec la commande "ss -tulpn", ce dernier m'indique que le serveur écoute bien sur le port 25565. J'ai également installer UFW et tenter d'ouvrir le port avec ce dernier, un simple message "skipping existing rule" apparait. J'enregistre également bien les regles avec la commande "/sbin/iptables-save > /etc/iptables/rules.v4"

J'ai mis cela de coté et ai voulu créer un second partage de fichier, cette fois ci avec samba, qui est censé accueillir des backups de mon pc fixe et portable qui sont sur une windows 10. La encore, impossible de me connecter alors que j'ai essayer d'ouvrir les ports comme pour le serveur Minecraft.

Cependant, lorsque je désactive le firewalld et iptables, il est alors possible de me connecter au serveur MC et de mapper le partage de fichier Samba a mon explorateur de fichier sur mes PCs. Le probleme vient donc bel et bien du firewall. Pourtant le ssh fonctionne correctement aussi bien pour me connecter au shell que pour mon partage de fichier en SFTP.

Est-ce que quelqu'un aurai une idée ?

Je remercie en tout cas tout ceux qui ont pris le temps de lire mon problème

Malakai · 15 mars 2022

Salut,

Dans un premier temps il nous faudrait la liste de tes règles de pare-feu.
Tu peux les voir avec un iptables -nvL par exemple.
En les copiant collant sur le forum n’oublie pas de les insérer en tant que code avec un ` avant et après le texte.

Sinon, avis personnel, si le serveur se trouve dans ton réseau personnel (non connecté directement à Internet) tu peux désactiver le pare-feu, car si tu es derrière une box, tu seras de toute façon protégé (normalement) par le pare-feu de la box. Moi par exemple pour mon serveur que j'ai à la maison toutes les politiques du pare-feu sont sur ACCEPT.
Si c'est par contre un serveur directement accessible par Internet, alors le pare-feu est indispensable.

Nouh · 16 mars 2022

Hello, le serveur doit etre joignable depuis l'exterieur en ssh, en partage de fichier, pour Minecraft et pour le futur Plex, et pour heberger des futures portfolio, donc pas trop le choix ...

Le serveur s'eteint la nuit et se rallume le matin mais les regles sont normalement sauvegardées.

Voici ce que j'obtiens avec la commande que tu m'as demandé de faire :

 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 3262 packets, 366K bytes)
 pkts bytes target     prot opt in     out     source               destinatio ```

Avec la commande ss -tulpn, le serveur indique qu'il écoute bien sur les ports que j'ai ouvert si cette info peut aider.

Malakai · 16 mars 2022

Dans ta sortie on ne voit pas la politique du pare-feu pour la chaîne INPUT, par contre dans le mail de notification que j'ai reçu suite à ta réponse on voit ACCEPT, ce qui veut dire que dans l’état tout est ouvert (il n'y a aucune restriction au niveau du pare-feu).
Le problème viendrait donc d'autre part.
Peux-tu mettre la sortie de ss -tulpn (ou netstat -tupan ; mais il faut avoir le paquet net-tools installé) pour voir ce qui écoute exactement?

Nouh · 16 mars 2022

La commande ss -tulpn donne ceci une fois que le serveur est lancé :

udp     UNCONN   0        0                0.0.0.0:68             0.0.0.0:*
tcp     LISTEN   0        128              0.0.0.0:2222           0.0.0.0:*
tcp     LISTEN   0        50             127.0.0.1:445            0.0.0.0:*
tcp     LISTEN   0        50             127.0.0.1:139            0.0.0.0:*
tcp     LISTEN   0        128                 [::]:2222              [::]:*
tcp     LISTEN   0        511                    *:80                   *:*
tcp     LISTEN   0        4096                   *:25565                *:* ```

Nouh · 16 mars 2022

La commande netsat -tupan donne également cela :

tcp        0      0 0.0.0.0:2222            0.0.0.0:*               LISTEN      740/sshd: /usr/sbin
tcp        0      0 127.0.0.1:445           0.0.0.0:*               LISTEN      870/smbd

tcp        0      0 127.0.0.1:139           0.0.0.0:*               LISTEN      870/smbd

tcp        0     52 192.168.1.11:2222       192.168.1.81:1058       ESTABLISHED 1123/sshd: Noe [pri
tcp        0      0 192.168.1.11:57734      212.27.32.66:80         TIME_WAIT   -

tcp        0      0 192.168.1.11:59220      199.232.82.132:80       TIME_WAIT   -

tcp        0      0 192.168.1.11:57728      212.27.32.66:80         TIME_WAIT   -

tcp        0      0 192.168.1.11:59222      199.232.82.132:80       TIME_WAIT   -

tcp        0      0 192.168.1.11:2222       192.168.1.81:1281       ESTABLISHED 1012/sshd: Noe [pri
tcp        0      0 192.168.1.11:2222       192.168.1.81:49679      ESTABLISHED 979/sshd: Noe [priv
tcp6       0      0 :::2222                 :::*                    LISTEN      740/sshd: /usr/sbin
tcp6       0      0 :::80                   :::*                    LISTEN      741/apache2
tcp6       0      0 :::25565                :::*                    LISTEN      1030/java

udp        0      0 0.0.0.0:68              0.0.0.0:*                           708/dhclient ```

Malakai · 16 mars 2022

Déjà ton samba n’écoute que sur l'adresse localhost (127.0.0.1), tu ne risques donc pas de pouvoir joindre le service depuis le réseau.
Vérifie ta conf samba (normalement /etc/samba/smb.conf) s'il n'est pas mentionné le fait de n’écouter que sur l'interface lo (au pire colle ta conf ici, en mettant des xxx à la place de toute info qui pourrait sembler sensible).
Sinon il arrive parfois que le service démarre avant que le réseau ne soit disponible ce qui fait que le service n’écoute que sur l'interface lo. Essaye de faire un systemctl restart smbd et regarde à nouveau avec netstat -tupan si cette fois ci à la ligne indiquant smbd tu a autre chose à la place de 127.0.0.1 (normalement 0.0.0.0)
Pour ce qui est de l'autre service qui écoute sur le port 25565, fait un nc -vz 192.168.1.11 25565 depuis une autre machine Linux pour voir s'il arrive bien à communiquer sur ce port et colle la sortie ici.

Nouh · 16 mars 2022

Oui j'ai trifouillé dans le fichier de conf pour essayer deux trois trucs pour samba j'avais décommenté la ligne qui faisait ecouter le serveur qu'en localhost ! Mais c'est pas ca qui fait que ca ne fonctionne pas en tout cas j'ai recorrigé et le serveur samba reécouter bien sur n'importe quelle @IP !

Voila ce que ca donne quand je fais la commande nc -vz 192.168.1.11 25565 sur le WSL de mon PC : nc: connect to 192.168.1.11 port 25565 (tcp) failed: No route to host

Le message est identique sur les ports 139 et 445 qu'utilisent samba et meme le port 80 de apache !

Par contre j'ai un Connection to 192.168.1.11 2222 port [tcp/*] succeeded! pour mon ssh.
Peut etre que cela vient de ma facon d'ouvrir mes ports mais je ne vois pas comment puisque j'ai utilisé la même commande pour le ssh qui fonctionne ...

Malakai · 17 mars 2022

No route to host veut dire que tu ne te trouve pas sur le même réseau que la machine de destination (192.168.1.11) et que tu n'a aucune route pour la joindre.
Par contre si en ssh ça marche c'est vraiment bizarre.
Quelle est l'ip de la machine depuis laquelle tu essaye de joindre le serveur et quelles sont ses routes (colle la sortie des commandes ip a et ip r).

Nouh Peut etre que cela vient de ma facon d'ouvrir mes ports

Que veux-tu dire par là?
Comment est-ce que tu ouvres tes ports?

Nouh · 18 mars 2022

Malakai Le serveur est sur le meme réseau local en 192.168.1.X, il est juste dans une DMZ sur ce réseau.

J'ouvre mes ports avec la commande classique iptables -A INPUT -p tcp --dport XXXX -j ACCEPT

En input, en output, en TCP et UDP. J'ai aussi essayé la commande ufw allow XXXX

Je te donne le résultat des deux commandes que tu m'as cité des que je rentre chez moi ce soir.

Nouh · 18 mars 2022

Je peux te dire de suite ce que les deux commandes font sur le serveur par contre.

ip a : 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 8c:f6:a9:9a:4c:66 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.11/24 brd 192.168.1.255 scope global dynamic enp7s0
       valid_lft 77965sec preferred_lft 77965sec
    inet6 fe80::8ef6:a9ff:fe9a:4c66/64 scope link
       valid_lft forever preferred_lft forever```

ip r : 
default via 192.168.1.254 dev enp7s0
192.168.1.0/24 dev enp7s0 proto kernel scope link src 192.168.1.11

Je te fais la machine cliente ce soir ^^ Merci de ton aide en tout cas c'est super gentil de ta part !

Nouh · 18 mars 2022

Et voici ip a sur la machine cliente :

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether fa:e9:72:df:20:fa brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 2a:29:18:1a:f4:c9 brd ff:ff:ff:ff:ff:ff
4: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:37:1f:49 brd ff:ff:ff:ff:ff:ff
    inet 172.20.100.62/20 brd 172.20.111.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe37:1f49/64 scope link
       valid_lft forever preferred_lft forever ```

Nouh · 18 mars 2022

et ip r :

172.20.96.0/20 dev eth0 proto kernel scope link src 172.20.100.62 ```

Nouh · 18 mars 2022

Les réponses sont tres bizarres, c'est WSl que j'utilise sur mon Windows mais quand je fais un ipconfig /all j'obtiens ca :


   Connection-specific DNS Suffix  . : lan
   Description . . . . . . . . . . . : Realtek PCIe GbE Family Controller
   Physical Address. . . . . . . . . : 70-85-C2-F2-31-6C
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::310d:72df:5304:f5c4%7(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.1.81(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Wednesday, March 16, 2022 11:05:06 PM
   Lease Expires . . . . . . . . . . : Saturday, March 19, 2022 8:19:44 PM
   Default Gateway . . . . . . . . . : 192.168.1.254
   DHCP Server . . . . . . . . . . . : 192.168.1.254
   DHCPv6 IAID . . . . . . . . . . . : 108037570
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-29-AD-97-F1-70-85-C2-F2-31-6C
   DNS Servers . . . . . . . . . . . : 192.168.1.254
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter vEthernet (WSL):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
   Physical Address. . . . . . . . . : 00-15-5D-FD-76-7C
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::e499:f14e:8c18:9a09%21(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.20.96.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 352327005
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-29-AD-97-F1-70-85-C2-F2-31-6C
   NetBIOS over Tcpip. . . . . . . . : Enabled ``` 

Donc enfaite le WSL donne des infos bizarre sur une nouvelle interface internet. 
Je précise que j'utilise pas WSL de base mais uniquement pour essayer de me decoincé de cette solution

Malakai · 18 mars 2022

Déjà ton adresse ip sur le WSL (172.20.100.62/20) est vraiment bizarre (d'habitude c'est du /24, mais c'est pas vraiment ça qui pourrait poser problème).

Nouh

Pour ce qui est des routes c'est bizarre.... soit tu n'as pas tout copier collé, soit il n'y a pas de route par défaut (et là ça pourrait poser problème).

En ce qui concerne ta méthode d'ouverture des ports, comme je le disais, la politique de la chaîne INPUT est ACCEPT, ce qui veut dire que tout est ouvert par défaut, donc tes règles ne servent pas a grand chose.

Si tu veux on peut essayer de trouver un créneau pour que je me connecte par VNC / Teamviewer à ton PC client et qu'on essaye de voir ensemble pourquoi tu ne peux pas joindre ton serveur... parce que là, juste avec les infos que j'ai à présent c'est pas évident de se rendre compte (et ça nous permettra également d'avancer plus vite dans la résolution du problème).

Nouh · 18 mars 2022

Oui je veux bien, voici mon discord pour qu'on s'organise ca : Nouh#1613

Je n'ai pas trouvé comment t'envoyer de MP sur la plateforme ^^'

Malakai · 18 mars 2022

Je n'ai malheureusement de compte sur aucun réseau "commerciale" (j'ai des comptes personnels de Jabber/XMPP ou bien NextCloud Talk -> donc que du auto-hébergé), mais je te propose de nous connecter en simultané sur le lien suivant, demain (samedi 19/03/2022) à 14h : https://meet.jit.si/fwdebian11
Dis moi si ça te va pour que je me connecte à l'heure précisée.

Nouh · 18 mars 2022

Malakai Pas de probleme de mon coté c'est noté ! Merci beaucoup et a demain 14h

Nouh · 19 mars 2022

Malakai hello, je suis dans le meeting