Adressage IP réseau correct si vos utilisateurs ont la possibilité de VPN dans

Mon réseau interne est 192.168.0.x avec une passerelle de 192.168.0.1.

J'ai des utilisateurs qui VPN dans notre pare-feu qui les ajoute ensuite essentiellement au réseau.

Cependant, si leur routeur domestique a une adresse IP de 192.168.0.1, nous avons bien sûr toutes sortes de problèmes.

Alors, quelle est la configuration d'adresse réseau idéale pour éviter cela? J'ai vu des configurations où les utilisateurs distants ont des adresses de routeur dans la plage 10.x, donc je ne sais pas trop ce que je peux faire pour éviter cela.

Tous les commentaires sont les bienvenus!

Techspot dispose d' une liste d'adresses IP de routeur par défaut communes qui vous aide à cet égard . Habituellement, les routeurs domestiques utilisent des /24sous-réseaux. De nos jours, les téléphones mobiles sont souvent utilisés pour partager la connexion réseau, nous devons donc également tenir compte de ces plages. Selon la liste que nous pouvons déduire, nous devons éviter :

• 192.168.0.0/19- la plupart des routeurs semblent en utiliser certains ci-dessus 192.168.31.255.
• 10.0.0.0/24est également largement utilisé, et Apple utilise 10.0.1.0/24.
• 192.168.100.0/24 est utilisé par Motorola, ZTE, Huawei et Thomson.
• Motorola utilise (en plus) 192.168.62.0/24et 192.168.102.0/24.
• 192.168.123.0/24 est utilisé par LevelOne, Repotec, Sitecom et US Robotics (moins courant)
• Certains D-Links ont 10.1.1.0/24et 10.90.90.0/24.

Nous avons trois gammes réservées aux réseaux privés ; nous avons encore beaucoup d'espace pour les éviter dans:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

Une plage supérieure aléatoire 10.0.0.0/8pourrait être le choix le plus sûr pour éviter les collisions. Vous pouvez également éviter le nombre 42dans n'importe quelle partie de la plage d'adresses IP: il peut s'agir du nombre "aléatoire" le plus courant, car il s'agit de la réponse à la question ultime de la vie, de l'univers et de tout .

Le mieux que vous puissiez faire est d'utiliser une plage pour le réseau auquel vous donnez accès à vpn, que vous attendez qu'aucun de vos utilisateurs n'utilise. Il y a de fortes chances que beaucoup de vos utilisateurs n'aient pas changé que leurs routeurs utilisent 192.168.0.0/24 ou 192.168.1.0/24 (les deux gammes que j'ai vues le plus dans les équipements grand public), si vous avez une idée de certains qui pourraient avoir choisi d'utiliser une plage différente, demandez-leur ce qu'ils utilisent, mais les utilisateurs qui l'ont fait sauront également comment modifier la configuration de leur propre routeur pour éviter le conflit.

Vous ne pouvez jamais être sûr à 100%, mais vous pouvez minimiser le risque en évitant d'utiliser les mêmes sous-réseaux que tout le monde.

J'éviterais d'utiliser les sous-réseaux au bas des blocs car de nombreuses personnes commencent à numéroter leurs réseaux depuis le début d'un bloc.

IMO, votre pari le plus sûr pour éviter les conflits est d'utiliser un sous-réseau quelque part au milieu du bloc 172.16.0.0/12. Je n'ai jamais vu un routeur domestique préconfiguré avec un sous-réseau de ce bloc.

Un sous-réseau aléatoire de 10.0.0.0/8 est également relativement sûr, mais j'ai utilisé une fois un routeur domestique qui a alloué la totalité de 10.0.0.0/8 au réseau par défaut et n'autorisait que les masques correspondant à la valeur par défaut de la classe.

192.168 est le plus vulnérable aux conflits car il s'agit d'un bloc relativement petit et largement utilisé sur les routeurs domestiques.

Pour éviter tous les problèmes mentionnés ci-dessus, je préférerais certainement une plage IP dans la plage 172.16.nn ou 10.nnn. Par exemple, dans le fichier de configuration du serveur pour le serveur VPN, j'allouerais une plage d'adresses IP de 10,66.77.0, par exemple, avec le masque 255.255.255.0 - le serveur VPN lui-même prendra 10.66.77.1, chaque client VPN obtiendra le suivant IP libre au-dessus de cela. Fonctionne pour moi, pas de conflits de connexions en utilisant des routeurs «domestiques», qui sont principalement dans la plage 192.168.nn.

C'est un peu déroutant pour moi car dans la plupart des environnements que j'ai rencontrés pour que les utilisateurs distants aient un accès VPN, l'administrateur doit avoir le contrôle / la gestion des connexions des utilisateurs pour s'assurer que le réseau reste sécurisé. Cela signifie un accès administratif, un contrôle, etc ... de la connexion des machines et des utilisateurs. Cela signifie que l'administrateur peut contrôler la plage d'adresses IP, ce qui signifie que les chances de ce que vous décrivez sont pratiquement impossibles.

Cela dit, votre solution semble réalisable mais très difficile en ce qui concerne l'utilisation de différentes plages IP.

Une option consiste à créer un script que vous exécutez sur les systèmes de connexion pour remplacer les tables de routage afin de réduire les risques de conflit potentiel (je suis conscient que certaines solutions VPN sont capables de le faire). En effet, la configuration du réseau organisationnel aura priorité sur la configuration du réseau local.

/unix/263678/openvpn-understand-the-routing-table-how-to-route-only-the-traffic-to-a-spec

client openvpn remplacer la passerelle par défaut pour vpn sever

Cela conduit à d'autres possibilités. En supposant que les utilisateurs ne se connectent pas directement aux adresses IP, vous pouvez modifier les configurations DNS / entrées de fichier hôte afin qu'elles remplacent techniquement la configuration du réseau local existant.

https://hostsfileeditor.codeplex.com/

https://support.rackspace.com/how-to/modify-your-hosts-file/

Une autre façon consiste à modifier la configuration de votre organisation pour avoir un réseau d'adresses IP moins commun. Puisque vous avez un accès administratif, vous devriez pouvoir le faire rapidement et facilement (bien que j'ai lu depuis un autre commentaire qui met en jeu le problème IPv6).

Évidemment, vous devrez changer le type de configuration VPN dont vous disposez pour vous donner certaines des options que je décris ci-dessus si vous ne les avez pas déjà.