Impossible d'accéder au serveur Web Apache à l'extérieur / à l'intérieur du réseau local
Je m'excuse par avance si j'utilise des termes techniques de manière inappropriée. Je suis toujours un débutant sur Linux/réseau
J'essaie de résoudre ce problème depuis plus d'une semaine et aucune des questions connexes posées par d'autres ne m'a aidé. J'ai récemment construit un serveur Web fonctionnant sur Apache2 pour héberger mon propre site Web. J'avais également l'intention de l'utiliser pour SSH, FTP et VNC. J'ai enregistré un domaine chez GoDaddy, cokongwu.com. Une adresse IP statique (192.168.0.105) a été configurée pour le serveur et j'ai également configuré le transfert de port pour le port 80, 21, 23, 53 et 443 sur l'adresse IP statique. En lisant les guides sur la configuration d’un serveur Web accessible au public, j’ai pensé que c’était tout ce qui était nécessaire, car cela fonctionnait parfaitement au début, mais j’ai bien sûr découvert que j’ai essayé d’accéder au serveur Web en utilisant le nom de domaine en dehors du réseau. , Je ne pouvais pas me connecter. Après quelques recherches supplémentaires, j'ai découvert que je devais changer mon enregistrement A dans mon fichier de zone chez GoDaddy en mon adresse IP publique. Une fois que j’ai fait cela, j’ai constaté que je ne pouvais plus du tout me connecter à mon serveur Web, que ce soit à l’intérieur du réseau, où je devrais plutôt être redirigé vers la page du routeur, ainsi qu’à l’extérieur du réseau, où la connexion expirerait tout simplement. J'ai plus tard compris que, comme mon adresse IP publique ne pouvait pas être définie sur statique, je devais utiliser un service, plus précisément dyndns, de manière à pouvoir la mettre à jour en permanence lorsque celle-ci change. J'ai configuré le programme de mise à jour dyndns à partir du centre de mise à jour logicielle et mon compte dyndns, cokongwu.com, avec un enregistrement A pointant sur mon adresse IP publique et un alias www.cokongwu.com pointant vers cokongwu.com. J'ai également configuré un nom d'hôte, cokongwu.dyndns.org, qui pointe également vers mon adresse IP publique et a ajouté les serveurs de noms dyndns aux serveurs de noms de Godaddy. L’enregistrement A que j’ai pour cokongwu.com chez Godaddy indique toujours mon adresse IP interne et les enregistrements CName (www et cokongwu.com) renvoient tous deux à cokongwu.dyndns.org. ne peut plus gérer le fichier de zone du domaine)
Après tout cela, essayer d'accéder à hostname.com fournit toujours les mêmes problèmes qu'avant. Son accès pointe sur mon adresse IP publique au lieu de mon adresse IP interne, mais sur le réseau, je suis simplement redirigé vers la page de paramétrage de mes routeurs et en dehors du réseau, le délai expire. Je suis à court d'idées sur la façon de résoudre ce problème, alors toutes les idées sont les bienvenues. Ne devrait-il pas (l'adresse IP publique) être redirigé vers mon adresse IP interne?
Encore une fois désolé si j'utilise n'importe lequel de ces mots techniques de la mauvaise façon, je suis encore très novice dans ce domaine.
Je connais beaucoup de questions liées à ce poste certaines commandes alors je vais faire la même chose:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:5556 0.0.0.0:* LISTEN 3387/dyn_updater
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 2729/vino-server
tcp6 0 0 :::80 :::* LISTEN -
tcp6 0 0 :::21 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 ::1:631 :::* LISTEN -
tcp6 0 0 :::5800 :::* LISTEN 2729/vino-server
tcp6 0 0 :::5900 :::* LISTEN 2729/vino-server
udp 0 0 0.0.0.0:5353 0.0.0.0:* -
udp 0 0 127.0.1.1:53 0.0.0.0:* -
udp 0 0 0.0.0.0:39124 0.0.0.0:* -
udp 0 0 0.0.0.0:631 0.0.0.0:* -
udp6 0 0 :::5353 :::* -
udp6 0 0 :::53973 :::* -
ufw:
Sudo ufw status
[Sudo] password for fender:
Status: inactive
000-default.conf:
<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual Host. For the default virtual Host (this file) this
# value is not decisive as it is used as a last resort Host regardless.
# However, you must set it for any further virtual Host explicitly.
ServerName cokongwu.com
ServerAlias www.cokongwu.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${Apache_LOG_DIR}/error.log
CustomLog ${Apache_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual Host. For example the
# following line enables the CGI configuration for this Host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
</VirtualHost>
# vim: syntax=Apache ts=4 sw=4 sts=4 sr noet
De ce que je comprends, vous rencontrez les problèmes suivants:
1 - Impossible d'accéder au serveur Web (à l'aide du nom de domaine complet, "nom de domaine pleinement qualifié" www.cokongwu.com) depuis à l'intérieur du réseau local?
2 - Vous ne pouvez pas vérifier les fonctionnalités du site Web depuis en dehors de ?
1 - Accès au serveur Web de l'intérieur à l'aide d'un nom de domaine complet.
Je ne vois pas dans votre question d'où vous essayez d'accéder au serveur Web. Je suppose donc que cela provient d'un client distinct à l'intérieur du réseau local.
Étant donné que vous utilisez probablement un serveur DNS externe, votre demande concernant www.cokongwu.com résoudra le numéro IP disponible au public, ce qui signifie l'extérieur de votre routeur Internet (voir ci-dessous). Depuis ce routeur ne routera pas le trafic venant vers le numéro IP externe de l'intérieur vers l'intérieur , le trafic s’arrêtera à cet endroit.
Pour que les choses fonctionnent à l'intérieur du réseau, www.cokongwu.com doit être résolu en tant que votre internal Numéro IP (192.168.0.105). Vous pouvez essayer de naviguer sur le serveur Web en utilisant le numéro IP interne, mais puisque vous envisagez d'utiliser SSL, vous devrez éventuellement accéder au serveur Web à l'aide du nom de domaine complet ou vous obtiendrez des erreurs de certificat.
La "solution" pour résoudre le problème de résolution de nom interne consiste à configurer un serveur DNS interne, mais la procédure ci-dessus résoudra les problèmes de dépannage et de déploiement à petite échelle. Vous ne semblez pas étranger à Google et si vous souhaitez configurer un serveur DNS interne, il existe de nombreux guides à ce sujet sur Internet.
Une fois que la résolution de nom interne vous a donné l’adresse IP interne, la navigation sur le serveur Web donnera la même réponse que si vous êtes un client venant de l’extérieur.
2 - accès externe au serveur Web.
La résolution de www.cokongwu.com avec Dig www.cokongwu.com +noall +answer m’a donné la réponse suivante.
www.cokongwu.com. 0 DANS CNAME cokongwu.com.
cokongwu.com. 59 IN A 69.171.137.28
Cela montre que l'hôte www est un cname (alias) pointant vers cokongwu.com qui est un enregistrement A. Effectuer une recherche inversée sur 69.171.137.28 avec Dig -x 69.171.137.28 +short donne:
dsl-69-171-137-28.acanac.net
Cela ressemble à un hôte dynamique. Si la mise à jour de dyndns fonctionne, il devrait s'agir de votre adresse IP publique actuelle. Vérifiez cela avec la commande suivante sur une ligne de commande:
curl -s checkip.dyndns.org | sed -e 's/.*Current IP Address: //' -e 's/<.*$//'
(Shamelesly volé de ici ) Ou en naviguant jusqu'à www.whatismyip.com
En supposant qu’il s’agisse de votre situation actuelle, naviguer vers www.cokongwu.com devrait fonctionner de l’extérieur ...
J'ai essayé cela et cela n'a pas fonctionné, ce qui pourrait vouloir dire tout ou partie des éléments suivants:
A - Le service dyndns n'a pas mis à jour votre adresse IP
B - Le transfert dans votre routeur extérieur ne fonctionne pas
C - Le serveur Web ne répond pas
Faire un test rapide en utilisant telnet <ip number> <port number> ne donne aucune réponse à l’un des numéros de port que vous avez énumérés ci-dessus. Cela me ferait croire que la raison devrait être A ou B. Si c'est B, il se peut que vous n'ayez pas transféré le port correctement ou que vous utilisiez un routeur en conjonction avec votre modem, vous n'avez pas correctement ponté. modem au routeur pour lui permettre de gérer toutes les demandes de transfert de port.
Quelques réflexions supplémentaires
Je remarque que vous avez mentionné le port 53 comme l'un des ports transférés au serveur Web. Le port 53 UDP est la norme pour les demandes de DNS entrantes . Sauf si un serveur DNS est exécuté sur la machine du serveur Web, vous pouvez fermer ce port en toute sécurité ... de toute façon.
J'ai également remarqué que vous avez mentionné l'utilisation de ssh et ftp, mais que vous avez ouvert les ports 21 et 23 dans le pare-feu et que ceux-ci ont été transmis au serveur Web. Le port 23 est le telnet et le port 21 est le port FTP . Je conseillerais fortement de n'utiliser aucun de ces services, car ce sont deux protocoles non sécurisés qui transmettent tout en texte clair, y compris les noms d'utilisateur et les mots de passe.
Je recommande uniquement l'ouverture et le transfert du port 22 dans le pare-feu. Le port 22 est utilisé par ssh , qui est le remplacement crypté de telnet. . Le port 22 est également utilisé par le service scp , qui utilise le service Service SSH pour le transfert de fichiers. Utiliser ssh et scp à la place de telnet et ftp gardera tout votre trafic vers et depuis le serveur Web sécurisé.
Une autre recommandation serait d’utiliser un port différent pour le SSH entrant, de préférence un numéro de port supérieur à 1000, comme le port 1522 (juste un exemple). Ceci permet d'éviter que le service ssh entrant ne soit découvert par des analyses de ports externes. Modifiez simplement le port entrant de 22 à un numéro de port supérieur (c'est-à-dire 1522), mais conservez-le toujours transféré vers le port 22 sur le serveur Web. Accédez ensuite au serveur ssh de l’extérieur à l’aide du numéro de port élevé (1522) et de l’intérieur à l’aide du port 22.
J'espère que cela vous sera utile et j'espère que vous résolvez votre problème =)