L’adresse 172.30.1.1 appartient à la plage privée définie par la RFC 1918 (172.16.0.0/12). Par conception, les routeurs Internet ne transportent pas les paquets destinés à cette plage. La question du blocage depuis l’extérieur semble donc réglée d’avance, mais la réalité réseau est plus nuancée qu’un simple standard sur le papier.
Adresse privée RFC 1918 et exposition réelle : ce que le routage public garantit (ou pas)
Les plages privées RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) ne sont jamais routées sur Internet public. Un paquet à destination de 172.30.1.1 émis depuis un réseau distant sera abandonné par les routeurs de transit avant d’atteindre votre infrastructure.
A lire aussi : Comment fonctionne un vpn et pourquoi l'utiliser en 2025
Cette protection par le routage ne couvre qu’un seul scénario : la tentative de connexion directe à l’adresse privée. Elle ne protège pas contre une redirection configurée sur votre propre équipement de bordure.
| Scénario | 172.30.1.1 joignable depuis l’extérieur ? | Risque |
|---|---|---|
| Aucune règle NAT, aucun port-forwarding | Non | Nul |
| Port-forwarding d’un port externe vers 172.30.1.1 | Oui, via l’IP publique du routeur | Élevé |
| VPN site-to-site mal cloisonné | Oui, depuis le réseau distant | Moyen à élevé |
| Interface d’administration exposée sur le WAN | Oui, si le firmware le permet | Critique |
Le tableau montre que la protection ne repose pas sur le caractère privé de l’adresse, mais sur la configuration active de vos équipements. Une simple règle de redirection de port transforme une adresse théoriquement invisible en cible accessible.
A lire aussi : Bloquer les appels 0162 : solutions efficaces pour stopper ces appels indésirables
Port-forwarding et NAT : le vrai vecteur d’exposition de 172.30.1.1
Sur la plupart des box Internet et routeurs domestiques ou professionnels, la fonction de redirection de port (port-forwarding) permet d’associer un port de l’adresse IP publique à un couple IP:port interne. Si 172.30.1.1 héberge une interface d’administration, un serveur web ou un service de supervision (cas fréquent avec certaines passerelles photovoltaïques ou contrôleurs réseau), une redirection mal maîtrisée ouvre un accès complet depuis Internet.
Le risque ne se limite pas à une redirection volontaire. Certains équipements activent l’UPnP (Universal Plug and Play) par défaut, ce qui autorise n’importe quel appareil du réseau local à créer des règles NAT sans validation manuelle.
- Vérifiez la table NAT de votre routeur : chaque entrée associant un port externe à 172.30.1.1 doit correspondre à un besoin documenté et temporaire
- Désactivez l’UPnP si vous n’avez pas besoin qu’un logiciel crée automatiquement des redirections de port
- Auditez les règles de pare-feu en entrée (chaîne INPUT ou équivalent) : une règle explicite de blocage vers 172.30.1.1 en provenance du WAN reste utile comme filet de sécurité, même si aucune redirection n’existe
L’ajout d’une règle de pare-feu dédiée relève du principe de défense en profondeur. Si une erreur de configuration crée un jour une redirection non souhaitée, la règle de blocage empêche l’exploitation.
Pare-feu et règles iptables : bloquer l’accès entrant vers une adresse privée
Sur un système Linux faisant office de routeur ou de pare-feu, une règle iptables suffit à interdire tout trafic entrant depuis l’interface WAN vers 172.30.1.1. Le principe est de filtrer sur la chaîne FORWARD les paquets dont la destination correspond à cette adresse et dont l’interface d’entrée est celle connectée à Internet.
Le filtrage sur la chaîne FORWARD empêche le transit, pas seulement la réception locale. C’est la chaîne pertinente quand le pare-feu protège un réseau derrière lui, et non ses propres services.
Segmentation réseau et VLAN comme complément
Bloquer un accès ne se réduit pas au pare-feu périmétrique. Si 172.30.1.1 est l’adresse d’un équipement sensible (passerelle domotique, contrôleur d’onduleurs, NAS), le placer dans un VLAN dédié ajoute une couche d’isolation. Les communications entre VLAN passent alors par le routeur, où des ACL (listes de contrôle d’accès) filtrent le trafic autorisé.
Cette segmentation limite aussi les mouvements latéraux : un appareil compromis sur le réseau invité ou IoT ne peut pas atteindre 172.30.1.1 sans traverser une règle de routage inter-VLAN explicitement autorisée.
Interface d’administration sur le WAN : le piège le plus courant
Plusieurs routeurs et passerelles proposent d’activer l’accès à leur interface d’administration depuis le port WAN. Si l’équipement situé en 172.30.1.1 est le routeur lui-même, cette option rend la page de connexion accessible à quiconque connaît l’IP publique.
Désactiver l’administration distante via le WAN est la première mesure à prendre. Si un accès distant est nécessaire pour la maintenance, un tunnel VPN reste le seul canal acceptable : il chiffre le trafic et authentifie l’utilisateur avant toute interaction avec l’interface.
- Vérifiez dans les paramètres du routeur si l’option « Remote Management » ou « Accès distant » est activée, et désactivez-la
- Si un VPN site-to-site existe, contrôlez que les sous-réseaux autorisés à transiter ne donnent pas un accès non souhaité à 172.30.1.1
- Changez les identifiants par défaut de l’interface d’administration, même si l’accès WAN est coupé : une vulnérabilité côté LAN reste exploitable
Réseau domestique ou professionnel : adapter la stratégie de filtrage
Sur un réseau domestique avec une box opérateur, les options de filtrage se limitent souvent à la suppression des règles de redirection de port et à la désactivation de l’UPnP. Le pare-feu intégré bloque par défaut le trafic entrant non sollicité, ce qui protège 172.30.1.1 tant qu’aucune redirection n’est créée.
En environnement professionnel, la surface d’exposition est plus large. Les tunnels VPN, les accès partenaires, les interconnexions cloud ajoutent autant de chemins potentiels vers le réseau interne. Chaque chemin d’accès entrant doit faire l’objet d’une règle de filtrage spécifique mentionnant explicitement les sous-réseaux de destination autorisés.
En revanche, sur un réseau segmenté avec un pare-feu de nouvelle génération, le filtrage peut aller plus loin : inspection applicative, détection d’anomalies sur les flux vers les adresses d’administration, journalisation des tentatives d’accès.
L’adresse 172.30.1.1 n’est pas joignable depuis Internet par défaut, et c’est précisément cette fausse impression de sécurité qui crée le risque. Une règle de pare-feu explicite bloquant tout accès entrant vers cette adresse ne coûte rien en performance et protège contre les erreurs de configuration futures. La vraie protection d’un réseau ne repose jamais sur une seule couche, qu’il s’agisse du routage, du NAT ou du pare-feu.
