Comment savoir si une règle de pare-feu ou de NAT bloque une connexion entrante vers un serveur domestique

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

How to Tell Whether a Firewall or NAT Rule Is Blocking an Incoming Home Server Connection - Zima Store Online

Testez depuis l'extérieur du réseau domestique et suivez la connexion vers l'intérieur jusqu'à ce que le paquet disparaisse.

Une connexion entrante vers une application auto-hébergée peut échouer parce que le service n'écoute pas, le pare-feu de l'hôte la rejette, le routeur redirige le mauvais port ou la mauvaise adresse, le WAN est derrière un CGNAT ou un double NAT, ou la réponse sort par la mauvaise passerelle. Le diagnostic le plus sûr limite l'exposition publique, vérifie un service TCP ou UDP à la fois, et utilise la sortie du listener, les compteurs du routeur, les journaux du pare-feu et les captures de paquets pour identifier la première étape manquante.

Confirmez que le service écoute sur l'interface attendue

Commencez par le serveur domestique lui-même. Vérifiez que le processus est en cours d'exécution, que le port TCP ou UDP prévu est ouvert, et que le listener est lié à l'adresse LAN ou à toutes les interfaces requises plutôt qu'à 127.0.0.1 ou un réseau réservé aux conteneurs.

Le guide de Baeldung sur le test des ports explique qu'une socket en mode LISTEN est prête à accepter des connexions, mais l'adresse de liaison détermine encore quelles interfaces peuvent y accéder.

Testez le service depuis un autre appareil du LAN en utilisant l'IP privée du serveur et le port exact. Si cela échoue, arrêtez-vous au serveur ou au chemin VLAN local ; une règle NAT ne peut pas rediriger le trafic avec succès vers un service inaccessible depuis le côté routeur du LAN.

Utilisez un client externe plutôt que de tester depuis le même LAN

Déconnectez un téléphone du Wi-Fi ou utilisez un système sur une autre connexion internet. Testez l'IP publique ou le domaine, le port externe et le protocole correct pendant que le service cible écoute activement.

Le guide de Lifewire sur le transfert de port note que la règle du routeur et le pare-feu de l'ordinateur doivent tous deux autoriser la connexion, et recommande de vérifier les ports ouverts depuis l'extérieur du réseau plutôt que de se fier à un navigateur local qui peut rencontrer un comportement de NAT-loopback.

Notez si le client voit un délai d'attente, un refus immédiat, une erreur TLS ou une réponse de l'application. Un refus signifie souvent qu'un hôte accessible n'a pas de service acceptant sur ce chemin ; un délai d'attente silencieux est plus cohérent avec un filtrage, un transfert manquant, un NAT en amont ou une destination inaccessible.

Comparez l'adresse WAN du routeur avec l'adresse publique

Lisez l'adresse WAN affichée par le routeur domestique et comparez-la avec l'adresse publique rapportée par un service externe. Elles doivent correspondre pour un transfert de port IPv4 ordinaire, sauf si un autre routeur en amont effectue le premier NAT.

Si l'adresse WAN du routeur est privée, partagée ou différente de l'adresse publique, la règle de transfert peut se trouver derrière un double NAT ou un NAT de niveau opérateur. Dans ce cas, le paquet n'atteint jamais la règle du routeur, peu importe les modifications du pare-feu local.

Transférez le même port sur la passerelle en amont si vous la contrôlez, demandez une adresse publique utilisable à l'ISP, ou choisissez un VPN, un tunnel sortant ou un relais lorsque le transfert entrant est indisponible. Ne fragilisez pas le pare-feu du serveur pour compenser un paquet qui n'atteint jamais le routeur domestique.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

Surveillez les compteurs NAT et les journaux du pare-feu pendant un test

Réinitialisez ou enregistrez les compteurs pertinents du routeur, activez la journalisation sur la règle de test restreinte, puis envoyez une tentative de connexion externe. La question utile est de savoir si le paquet WAN correspond à la règle NAT et si le paquet traduit correspond à la règle d'autorisation.

Un cas de dépannage MikroTik illustre l'exigence commune d'avoir à la fois une règle NAT et une règle de pare-feu. La traduction modifie la destination ; elle ne garantit pas que le pare-feu autorise le flux transféré.

Si aucun compteur ne change, inspectez l'adresse publique, le port externe, l'interface et le NAT en amont. Si le NAT augmente mais pas la règle d'autorisation, vérifiez l'ordre des règles et la destination traduite. Si les deux augmentent, capturez sur le serveur pour voir si le paquet arrive.

Vérifiez la cible interne, le protocole et le chemin de retour

Confirmez que la règle NAT pointe vers l'adresse réservée actuelle du serveur et le port interne correct. Vérifiez si l'application attend TCP, UDP ou les deux, car un test TCP réussi ne garantit rien pour un service uniquement UDP.

Les conseils de dépannage de PortForward soulignent deux erreurs fréquentes : transférer vers le mauvais ordinateur et laisser un pare-feu logiciel bloquant l'application après la création de la règle du routeur.

Lorsque le paquet atteint le serveur mais qu'aucune réponse ne revient, inspectez la passerelle du serveur, le routage politique, le réseau des conteneurs et le chemin multi-NIC asymétrique. Le service doit renvoyer sa réponse par une route qui préserve l'état du pare-feu et du NAT créé par le paquet entrant.

Supprimez la règle de test lorsqu'elle n'a pas besoin de rester publique

Une fois la couche défaillante identifiée, appliquez la correction la plus petite et répétez le même test de l'extérieur vers l'intérieur. N'ouvrez pas une plage de ports ni ne désactivez tout le pare-feu simplement pour voir si quelque chose change.

Le guide ZimaSpace pour vérifier l'exposition du serveur domestique fournit la vérification de sécurité suivante après qu'une règle de transfert commence à fonctionner.

Gardez une règle publique uniquement lorsque le service est intentionnellement accessible depuis internet, authentifié, patché, journalisé et isolé des interfaces de gestion. Pour les tableaux de bord privés, SSH, SMB et fichiers personnels, un VPN ou un tunnel authentifié est généralement une frontière plus claire qu'un port transféré en permanence.