- État Nouveau
- Pourcentage achevé
- Type Anomalie
- Catégorie LAN → NAT (redirections, DMZ)
- Assignée à Personne
- Système d'exploitation Freebox Server Mini 4K
- Sévérité Haute
- Priorité Très Basse
- Basée sur la version 4.2.0
- Due pour la version Non décidée
-
Échéance
Non décidée
-
Votes
1
- BigDong (27/10/2020)
- Privée
Ouverte par BigDong - 26/10/2020
FS#32921 - Redirection de port non affecté à la bonne IP si deux carte réseaux sont connectés à la freebox
Bonjour,
Je suis nouvel abonné et possède une freebox mini 4k.
Sur son réseau, j’ai branché un serveur avec deux interfaces réseaux:
kopax@master-letort-01:[~]: ip -color a | grep 192
inet 192.168.1.101/24 brd 192.168.1.255 scope global dynamic enp2s0 inet 192.168.1.102/24 brd 192.168.1.255 scope global dynamic wlp1s0
Je précise que ces IPS sont fixé sur la freebox.
Coté freebox server, j’ai configuré ces deux redirections de ports:
10023 → 192.168.1.101
10024 → 192.168.1.102
J’ai eu un soucis de montage NFS depuis un NAS synology sur le réseau freebox avec l’erreur suivante :
2020-10-25T22:39:05+01:00 nas mountd[15563]: refused mount request from 192.168.1.102 for /volume4/DKA_MEDIA (/volume4/DKA_MEDIA): unmatched host
Effectivement, l’host en question doit pointé vers 192.168.1.101 , pour cette raison, je décide de couper l’interface wifi 192.168.1.102.
La connection sur le port SSH vers le port SSH 10024 fonctionne plus comme je l’attendais, mais je perd ensuite ma connection SSH sur le port 10023.
Heureusement via UN SSH sur le NAS, je peu récuperer l’accès a mon serveur en faisant un SSH local.
Il s’avère que la redirection de port 10023 pointais vers la mauvaise interface. Je viens de vérifier les réglages saisies dans l’interface freebox serveur, c’est bien un bug, la freebox me redirigeait vers la mauvaise interface pour le port 10023.
Je n’explique toujours pas pourquoi le NAS à reçu l’IP 192.168.1.102 lors du montage, comme l’indique la commande `ip -color a`, les addresses IP de l’interface vers laquel je monte aurait du être 192.168.1.101 et non 192.168.1.102, mais cela n’a rien à voir avec la redirection de port de la freebox serveur qui était mauvaise. Après redémarrage du serveur sans l’interface wifi 192.168.1.102, la connection SSH à été mapper correctement.
Mon fix: désactiver le WIFI en attendant que free corrige ce bug.
Cordialement,
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
PS: quand vous aurez validé le bug, je veux bien un geste commercial pour le temps passé.
Bien à vous,
DK
absolument rien compris à votre message qui n'est pas clair... (que vient faire votre histoire de montage NFS là dedans ?)
La question est surtout: comment avez vous mis en place votre redirection de port ? Via la console free (sur free.fr) ou via freeboxOS ?
Bonjour loggoi,
Merci pour votre effort de lecture et le temps passé à répondre.
La redirection de port à été faites via freebox OS, voici les captures:
!
Interface ethernet:
Interface wifi:
Avec une tel configuration, sauriez vous m'expliquer comment en coupant l'interface wifi, et bien la connexion SSH via le port 10023 tombe ? Comment la redirection sur le port 10023 peux elle attérir sur l'interface Wi-Fi ?
J'ai pu effectuer ma connection SSH à distance mais en utilisant un autre port SSH exposé par la freebox d'un autre serveur sur le même intranet, la connexion ethernet à toujours été up.
Concernant votre remarque sur le NFS, c'est le symptome qui m'a mené au problème. Le montage NFS necessite l'utilisation d'une interface spécifique à moins de le démonter, hors la redirection de port redirigais vers une interface spécifique qui n'était pas la bonne. Si ça ne vous intéresse pas de parler des conséquences, vous pouvez trouveer plus de détail ici : https://askubuntu.com/questions/632262/nfs-client-reconnect-after-interface-change
Cordialement,
DK
et comment affectez vous l'adresse IP à chaque interface du serveur ? En dur sur le serveur, ou via DHCP ? Et la configuration DHCP est correcte ?
Bonjour, j'affecte des IP static via le serveur DHCP de la freebox, voici la configuration
Pour compléter, voici le fichier `/etc/network/interfaces` du server (Debian Buster)
kopax@master-letort-01:[~]: cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto enp2s0
iface enp2s0 inet dhcp
# The wifi network interface
# allow-hotplug wlp1s0
# iface wlp1s0 inet dhcp
# wpa-ssid KOPAX_LETORT
# wpa-psk something
Noter que si l'interface wifi est maintenant commenté, c'est à cause de ce problème.
Je viens de constater quelque chose de très étrange :
kopax@master-letort-01:[~]: ip -color a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
3: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
L'adresse MAC de l'interface Wifi ne correspond pas à celle saisi dans le serveur DHCP.
VRAI: 5e:db:ae:0d:c8:cc
FAUX: 50:3E:AA:DC:EA:73
Pourtant, cela n'explique pas le problème de redirection du port 10023 attérissant sur cette interface, d'autant plus que le serveur DHCP à bien résérvé l'IP et attribuer à l'interface wifi (voir le premier `ip a` tout en haut).
Il n'y a pas d'autres interface physique sur ce serveur que ces deux la.
@BigDong : J'ai déjà eu un bug similaire à plusieurs reprises, je viens de faire un ticket : https://dev.freebox.fr/bugs/task/32934.
J'avais oublié de le faire, merci de m'y avoir fait penser.
Lorsque l’on fait une redirection de ports vers une machine qui a une IPv4 automatique via le serveur DHCP de la Freebox, puis que l’on ajoute un bail IPv4 statique à cette même machine, puis que l’on fasse le reboot de la machine ou la désactivation puis réactivation de la carte réseau (pour prise en compte), la redirection de port ne fonctionne pas.
Il faut supprimer la redirection de ports que nous venons de créer puis la refaire pour qu’elle fonctionne.
Par contre, je n’ai pas refait le test avec un nouveau changement du bail IPv4 statique de la dite machine.
@Neustradamus, merci également pour ton commentaire, bien que je ne crois pas que ça soit le même problème.
Mon problème est un mauvais routage NAT puisque la redirection ne devrait en aucun cas pointer vers le mauvaise IP du même hostname, je suspecte que le script NAT utilise le hostname pour determiner l'IP alors qu'il ne devrait pas.
J'attends l'expertise de @loggoi,
PS : je ne suis pas de chez free, je ne suis que simple abonné.
@loggoi: Oui oui, nous attendons le retour de @mbizon et @Thibaut Freebox.
Ainsi que pour le bug: https://dev.freebox.fr/bugs/task/32934
@BigDong, @loggoi : Si vous avez quelques minutes pour faire l'essai du bug précédemment cité et de le confirmer, ça serait cool aussi :)
@loggoi: Avez-vous des nouvelles ?