Accéder à la propriété intellectuelle interne en utilisant la propriété intellectuelle publique

Le problème est que la réécriture des paquets ne peut généralement avoir lieu qu'en traversant le pare-feu. En général, les routeurs ne peuvent pas effectuer la réécriture nécessaire lorsque la requête arrive du même réseau que celui sur lequel la requête serait réécrite. La solution courante à ce problème est de placer un proxy web en dehors du réseau qui renvoie la demande à travers votre pare-feu.

Je suppose que votre problème spécifique est que vous souhaitez accéder au site web via son nom d'hôte DNS. Vous pouvez régler ce problème en utilisant un DNS “à double horizon”, qui tient compte de la provenance de la demande et y répond de manière appropriée : Si la demande provient de votre réseau, il distribue le 192.168.0.50 aux demandes provenant de votre réseau et l'IP publique à tous les autres.

L'une ou l'autre de ces suggestions pourrait être mise en œuvre sur n'importe quel hôte en dehors de votre réseau, comme une micro instance (gratuite) d'Amazon EC2.

Je dirais que @Insyte est sur quelque chose quand il/elle dit que le problème est un problème de résolution DNS … ce qui signifie alors que le problème est la réécriture de paquets (lisez à nouveau @Insyte post pour cette explication).

En supposant que vous avez la configuration suivante :

1. IP publique : 201.206.x.y
2. IP privée : 192.168.0.50
3. Redirection de port pour les 80 (et 443 si vous faites du SSL) sur l'IP 201.206.x.y → 192.168.0.50

Vous tapez ensuite ce qui suit dans votre navigateur, alors que vous êtes dans votre réseau interne :

http://www.yourwebsite.com

et l'erreur se produit. Donc, solution : piratez le fichier de votre hôte.

Sur Windows, allez à C:\windows\system32\drivers\etc\hosts (remarquez, il n'y a pas d'extension sur ce fichier). Sous Linux, le fichier est situé dans /etc/hosts.

Si vous ouvrez ce fichier dans le Bloc-notes, vous pouvez alors voir toutes les entrées qui sont utilisées pour outrepasser le DNS. Si vous souhaitez mettre à jour ce fichier, vous devrez ouvrir Notepad (ou tout autre programme que vous utilisez pour modifier le fichier) avec des droits d'administrateur - sinon vous ne pourrez pas enregistrer le fichier.

Ajoutez ce fichier à votre fichier d'hôtes :

192.168.0.50 www.yourwebsite.com

Puis redémarrez votre navigateur, entrez l'URL et violà ! Ça marche. Cela signifie donc que votre navigateur ne dépend pas de votre DNS pour résoudre votre domaine vers l'IP. Au lieu de cela, on passe outre et on dit : Navigateur, allez à mon IP interne pour ce nom de domaine, au lieu de demander au DNS l'adresse IP_.

Si vous êtes dans un bureau, alors vous pouvez demander à toutes les personnes qui ont besoin d'accéder à ce site web interne, de pirater leur fichier d'hôtes, ou si vous avez un DNS interne, alors vous pouvez ajouter une entrée dans celui-ci.

Une autre idée est d'avoir un serveur proxy interne (pour toute navigation sur le web, etc.) et de pirater ensuite le fichier hosts sur le serveur proxy. Cela signifie que votre navigateur dira Proxy, pouvez-vous s'il vous plaît me donner la ressource http://www.mywebsite.com et le proxy dira Sure, et parce qu'on m'a dit d'ignorer le DNS pour ce domaine, je donnerai juste l'IP qui a été codée en dur dans mon fichier hosts.

C'est un problème courant dans la manière dont certains routeurs traitent le trafic destiné à leur adresse publique à partir d'une adresse interne - ils ne suivent pas les mêmes règles de transfert de port que les demandes provenant de l'extérieur du réseau. Ce que vous devez rechercher dans vos routeurs, c'est la réflexion NAT. Cela permettra au routeur de traiter les demandes internes pour l'adresse IP publique afin d'utiliser les mêmes règles de redirection de port que si la demande provenait de l'extérieur du réseau.

Je pourrais mieux vous aider si vous pouviez me donner la marque et le modèle de votre modem…

Mais ce qui se passe ici, c'est que normalement une page de configuration du routeur ou du modem ne devrait apparaître que lors de la visite de leur IP interne (192.168.0.1)

Mais ce qui semble se passer ici, c'est qu'elle identifie la requête entrante (201.206.x.x) Comme elle vient de l'intérieur, elle décide de vous donner la page de configuration au lieu de la route normale vers votre serveur web…

Maintenant si vous utilisez un modem de niveau Consommateur, vous ne pouvez probablement pas changer cela (désolé)

Mais peut-être que vous pouvez : Essayez de voir s'il y a des paramètres d'écoute dans votre page de configuration d'administration

Là, vous pouvez essayer soit de changer votre page d'administration pour un autre port, soit de limiter les adresses qu'elle écoute

Le problème est peut-être que l'administration à distance est autorisée.

Vous pouvez ajouter une route pour accéder à l'adresse IP publique du serveur directement par son adresse IP locale. Sous Windows, la commande est du type

route add [public IP] mask 255.255.255.255 [the server's local IP]

Pour ajouter une route persistante, ajoutez le paramètre -p à la commande ci-dessus.

Ensuite, à chaque fois que vous visiterez l'IP publique, l'ordinateur passera par l'IP locale du serveur comme passerelle. Comme le serveur connaît sa propre adresse IP publique, il traite le paquet lui-même au lieu de le transmettre au réseau local.

Vous devez vous assurer que l'IP locale du serveur est statique.

Avoir ce même problème. J'ai pu y remédier en ajoutant le nom d'hôte DNS à la liste de mappage des hôtes DNS de mon routeur. J'ai trouvé ces paramètres dans la liste des options avancées de mon routeur.

Sur mon routeur, j'ai dû désactiver l’“accélération NAT” (Cut Through Forwarding) car cela a cassé le loopback NAT…