Pido disculpas de antemano si uso alguna palabra técnica de manera incorrecta. Todavía soy un novato en Linux/redes
He estado tratando de resolver este problema durante más de una semana y ninguna de las preguntas relacionadas que otros han hecho me ha ayudado. Recientemente construí un servidor web que se ejecuta en Apache2 para alojar mi propio sitio web. También tenía la intención de usarlo para SSH, FTP y VNC. Registré un dominio en GoDaddy, cokongwu.com. Se configuró una IP estática (192.168.0.105) para el servidor y también configuré el reenvío de puertos para los puertos 80, 21, 23, 53 y 443 a la IP estática. Al leer las guías sobre cómo configurar un servidor web de acceso público, pensé que esto era todo lo que se necesitaba, ya que al principio funcionaba perfectamente, pero, por supuesto, descubrí que una vez intenté acceder al servidor web usando el nombre de dominio fuera de la red. , No pude conectarme. Después de buscar un poco más, descubrí que necesitaba cambiar mi registro A en mi archivo de zona en GoDaddy a mi IP pública. Una vez que hice eso, descubrí que ya no podía conectarme a mi servidor web, ni dentro de la red, donde sería redirigido a la página del enrutador, ni fuera de la red, donde la conexión simplemente expiraría. Más tarde descubrí que, dado que mi IP pública no se podía configurar como estática, tenía que usar un servicio, específicamente Dyndns, para poder actualizar constantemente la IP cuando cambiara. Configuré el actualizador de dyndns desde el centro de actualización de software y configuro mi cuenta de dyndns, cokongwu.com, con un registro A que apunta a mi IP pública y un alias www.cokongwu.com que apunta a cokongwu.com. También configuré un nombre de host, cokongwu.dyndns.org, que también apunta a mi IP pública y agregué los servidores de nombres dyndns a los servidores de nombres de Godaddy. El registro A que tengo para cokongwu.com en godaddy todavía apunta a mi IP interna y los registros CName (www y cokongwu.com) apuntan a cokongwu.dyndns.org. (sin embargo, desde que reemplacé los servidores de nombres de godaddy con servidores de nombres de dyndns, ya no puedo administrar el archivo de zona para el dominio)
Después de todo esto, intentar acceder a hostname.com sigue generando los mismos problemas que antes. Acceder a él apunta a mi IP pública en lugar de a mi IP interna, pero dentro de la red simplemente me reenvían a la página de configuración de mi enrutador y fuera de la red simplemente se agota el tiempo de espera. No tengo ideas sobre cómo solucionar este problema, por lo que cualquier idea es bienvenida. ¿No debería redirigirse (la IP pública) a mi IP interna?
Una vez más, lo siento si estoy usando alguna de estas palabras técnicas de manera incorrecta, todavía soy muy nuevo en todo esto.
Conozco muchas preguntas relacionadas con esta publicación y ciertos comandos, así que haré lo mismo:
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
Respuesta1
Por lo que tengo entendido, estás teniendo los siguientes problemas:
1 - No se puede acceder al servidor web (usando el FQDN, "nombre de dominio completo" www.cokongwu.com) desdeadentrola LAN?
2 - No puedes verificar la funcionalidad del sitio web desde elafuera?
1 - Acceso al servidor web desde el interior mediante FQDN.
No veo en tu pregunta desde dónde estás intentando acceder al servidor web, así que asumiré que es desde un cliente separado dentro de la LAN.
Dado que lo más probable es que esté utilizando un servidor DNS externo, su solicitud de www.cokongwu.com resolverá el número de IP disponible públicamente, es decir, el exterior de su enrutador de Internet (ver más abajo). Dado que ese enrutador no enrutará el tráfico que llegaal número IP externodesde el interiorde vuelta al interior, el tráfico se detendrá en ese punto.
Para que las cosas funcionenadentrola red, www.cokongwu.com tendrá que resolverse como suinternoNúmero de IP (192.168.0.105). Puede intentar navegar por el servidor web usando el número de IP interno, pero como planea usar SSL, eventualmente será necesario que acceda al servidor web usando el FQDN o obtendrá errores de certificado.
La "forma difícil" de arreglar la resolución de nombres interna es configurar un servidor DNS interno, pero lo anterior funcionará para solucionar problemas e implementaciones a pequeña escala. Parece que no eres ajeno a Google y si quieres configurar un servidor DNS interno, hay muchas guías para ello en Internet.
Una vez que la resolución de nombres interna le proporcione la dirección IP interna, navegar hasta el servidor web le dará la misma respuesta que si fuera un cliente externo.
2 - acceso externo al servidor web.
Al resolver www.cokongwu.com dig www.cokongwu.com +noall +answerme dio la siguiente respuesta.
www.cokongwu.com. 0 EN CNAME cokongwu.com.
cokongwu.com. 59 EN UN 69.171.137.28
Esto demuestra que elwwwhost es un cname (alias) que apunta haciacokongwu.comque es un récord A. Haciendo una búsqueda inversa en69.171.137.28con dig -x 69.171.137.28 +shortda:
dsl-69-171-137-28.acanac.net
Esto parece un anfitrión dinámico. Si la actualización de Dyndns funciona, esa debería ser su dirección IP pública actual. Verifique esto con el siguiente comando en una línea de comando:
curl -s checkip.dyndns.org | sed -e 's/.*Current IP Address: //' -e 's/<.*$//'
(robado descaradamente deaquí) O navegando awww.whatismyip.com
Suponiendo que este es su actual, navegando hastawww.cokongwu.comdebería funcionar desde afuera...
Lo intenté y no funcionó, lo que podría significar cualquiera o una combinación de lo siguiente:
R - El servicio dyndns no ha actualizado su dirección IP
B - El reenvío en su enrutador externo no funciona
C - El servidor web no responde
Al realizar una prueba rápida, telnet <ip number> <port number>no se obtienen respuestas de ninguno de los números de puerto que enumeró anteriormente. Esto me llevaría a creer que el motivo debería ser A o B. Si es B, podría ser que no haya reenviado el puerto correctamente o que, si está utilizando un enrutador junto con su módem, no haya realizado el puente correctamente. el módem al enrutador para permitirle manejar todas las solicitudes de reenvío de puertos.
Algunas reflexiones adicionales
Noto que mencionastepuerto 53como uno de los puertos reenviados al servidor web.Puerto 53 UDPes el estándar para los entrantessolicitudes de dns. A menos que realmente tengas unservidor DNSejecutándose en la máquina del servidor web, puede cerrar este puerto de manera segura... de todos modos no servirá para ningún propósito.
También noté que mencionaste el uso de ssh y ftp, pero abrí los puertos 21 y 23 en el firewall y los reenvié al servidor web. El puerto 23 es elTelnetpuerto y el puerto 21 es elPuerto FTP. Recomiendo encarecidamente no utilizar ninguno de estos servicios, ya que ambos son protocolos inseguros que transmitirántodoen texto claro, incluidos nombres de usuario y contraseñas.
Recomiendo solo abrir y reenviar.puerto 22en el cortafuegos.Puerto 22es utilizado porssh, que es el reemplazo cifrado de telnet.Puerto 22también es utilizado por elscpservicio, que utiliza elservicio sshpara transferencia de archivos. Usandosshyscpen lugar de telnet y ftp mantendrá seguro todo el tráfico hacia y desde el servidor web.
Una recomendación adicional sería utilizar un puerto diferente para ssh entrante, preferiblemente un número de puerto superior a 1000, como el puerto 1522 (solo un ejemplo). Esto es para evitar que el servicio ssh entrante sea descubierto mediante escaneos de puertos externos. Simplemente cambie el puerto entrante de 22 a un número de puerto superior (es decir, 1522), pero aún así manténgalo reenviado apuerto 22en el servidor web. Luego acceda al servidor ssh desde el exterior utilizando el número de puerto alto (1522) y desde el interior utilizando el puerto 22.
Espero que esto te sea de alguna utilidad y que resuelvas tu problema =)