Заранее извиняюсь, если я неправильно использую технические термины. Я все еще новичок в Linux/сетях.
Я пытаюсь решить эту проблему уже больше недели, и ни один из связанных вопросов, заданных другими, мне не помог. Недавно я построил веб-сервер, работающий на Apache2, для размещения своего собственного веб-сайта. Я также намеревался использовать его для SSH, FTP и VNC. Я зарегистрировал домен на GoDaddy, cokongwu.com. Для сервера был настроен статический IP (192.168.0.105), и я также настроил переадресацию портов для портов 80, 21, 23, 53 и 443 на статический IP. Прочитав руководства по настройке общедоступного веб-сервера, я подумал, что это все, что нужно, так как сначала все работало отлично, но, конечно, я обнаружил, что как только я попытался получить доступ к веб-серверу, используя доменное имя вне сети, я не смог подключиться. После некоторых дополнительных поисков я обнаружил, что мне нужно изменить мою запись A в моем файле зоны на GoDaddy на мой общедоступный IP. Как только я это сделал, я обнаружил, что больше не могу подключиться к своему веб-серверу, ни внутри сети, где меня вместо этого перенаправляли на страницу маршрутизатора, ни за пределами сети, где соединение просто истекало по тайм-ауту. Позже я понял, что поскольку мой публичный IP не может быть установлен как статический, мне нужно использовать службу, в частности dyndns, чтобы она могла постоянно обновлять IP при его изменении. Я настроил обновление dyndns из центра обновления программного обеспечения и настроил свою учетную запись dyndns, cokongwu.com, с записью A, которая указывает на мой публичный IP, и псевдонимом www.cokongwu.com, который указывает на cokongwu.com. Я также настроил имя хоста, cokongwu.dyndns.org, которое также указывает на мой публичный IP, и добавил серверы имен dyndns к серверам имен Godaddy. Запись A для cokongwu.com на Godaddy по-прежнему указывает на мой внутренний IP-адрес, а записи CName (www и cokongwu.com) указывают на cokongwu.dyndns.org. (Однако, поскольку я заменил серверы имен Godaddy на серверы имен dyndns, я больше не могу управлять файлом зоны для домена)
После всего этого попытка доступа к hostname.com по-прежнему приводит к тем же проблемам, что и раньше. Доступ к нему указывает на мой публичный IP вместо моего внутреннего IP, но внутри сети я просто перенаправляюсь на страницу настроек моего маршрутизатора, а вне сети просто истекает время ожидания. У меня нет идей, как это исправить, поэтому любые идеи приветствуются. Разве его (публичный IP) не следует перенаправить на мой внутренний IP?
Еще раз извините, если я использую какие-либо технические термины неправильно, я все еще новичок во всем этом.
Я знаю много вопросов, связанных с этим постом и некоторыми командами, поэтому я сделаю то же самое:
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 :::* -
уфв:
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
решение1
Насколько я понимаю, у вас возникли следующие проблемы:
1 - Невозможно получить доступ к веб-серверу (используя полное доменное имя, «полное доменное имя» www.cokongwu.com) извнутриLAN?
2 - Вы не можете проверить функциональность веб-сайта изснаружи?
1 — Доступ к веб-серверу изнутри с использованием полного доменного имени.
Из вашего вопроса я не вижу, откуда вы пытаетесь получить доступ к веб-серверу, поэтому предполагаю, что это происходит с отдельного клиента внутри локальной сети.
Поскольку вы, скорее всего, используете внешний DNS-сервер, ваш запрос на www.cokongwu.com разрешит общедоступный IP-адрес, то есть вне вашего интернет-маршрутизатора (см. ниже). Поскольку этот маршрутизатор не будет маршрутизировать трафик, входящийна внешний IP-номеризнутривернуться внутрь, в этом месте движение прекратится.
Чтобы все работаловнутрисеть, www.cokongwu.com должен быть разрешен как вашвнутреннийIP-номер (192.168.0.105). Вы можете попробовать просмотреть веб-сервер, используя внутренний IP-номер, но поскольку вы планируете использовать SSL, в конечном итоге вам потребуется получить доступ к веб-серверу, используя полное доменное имя, иначе вы получите ошибки сертификата.
"Трудный способ" исправить внутреннее разрешение имен - настроить внутренний DNS-сервер, но вышесказанное будет работать для устранения неполадок и мелкомасштабных развертываний. Вы, кажется, не новичок в Google, и если вы хотите настроить внутренний DNS-сервер, в Интернете есть много руководств по этому вопросу.
Как только внутреннее разрешение имен даст вам внутренний IP-адрес, при переходе на веб-сервер вы получите тот же ответ, как если бы вы были клиентом, заходящим извне.
2 - внешний доступ к веб-серверу.
Разрешение www.cokongwu.com dig www.cokongwu.com +noall +answerдало мне следующий ответ.
www.cokongwu.com. 0 В CNAME cokongwu.com.
cokongwu.com. 59 В A 69.171.137.28
Это показывает, чтоwwwхост — это cname (псевдоним), указывающий наcokongwu.comчто является записью A. Выполнение обратного поиска по69.171.137.28с dig -x 69.171.137.28 +shortдает:
dsl-69-171-137-28.acanac.net
Похоже на динамический хост. Если обновление dyndns работает, это должен быть ваш текущий публичный IP-адрес. Проверьте это с помощью следующей команды в командной строке:
curl -s checkip.dyndns.org | sed -e 's/.*Current IP Address: //' -e 's/<.*$//'
(позорно украдено изздесь) Или перейдя по ссылкеwww.whatismyip.com
Предполагая, что это ваш текущий просмотрwww.cokongwu.comдолжно работать снаружи...
Я попробовал, но это не сработало. Это может означать любую из следующих причин или их комбинацию:
A - Служба dyndns не обновила ваш IP-адрес.
B — Переадресация на внешнем маршрутизаторе не работает
C - Веб-сервер не отвечает
Выполнение быстрого теста с помощью telnet <ip number> <port number>не дает ответов ни с одного из номеров портов, которые вы перечислили выше. Это навело бы меня на мысль, что причина должна быть A или B. Если это B, то это может быть либо то, что вы неправильно перенаправили порт, либо, если вы используете маршрутизатор в сочетании с вашим модемом, вы не правильно подключили модем к маршрутизатору, чтобы позволить ему обрабатывать все запросы на переадресацию портов.
Еще несколько мыслей
Я заметил, что вы упомянулипорт 53как один из портов, перенаправленных на веб-сервер.Порт 53 UDPявляется стандартом для входящихDNS-запросы. Если только у вас на самом деле нетDNS-серверработая на машине веб-сервера, вы можете безопасно закрыть этот порт... он в любом случае не будет служить никакой цели.
Я также заметил, что вы упомянули использование ssh и ftp, но открыли порты 21 и 23 в брандмауэре и перенаправили на веб-сервер. Порт 23 — этотелнетпорт и порт 21 этоFTP-порт. Я настоятельно не рекомендую использовать ни один из этих сервисов, поскольку они оба являются небезопасными протоколами, которые будут передаватьвсеоткрытым текстом, включая имена пользователей и пароли.
Я рекомендую только открывать и пересылатьпорт 22в брандмауэре.Порт 22используетсясш, который является зашифрованной заменой telnet.Порт 22также используетсяscpсервис, который используетssh-сервисдля передачи файлов. Использованиесшиscpвместо telnet и ftp будет держать весь ваш трафик к и от веб-сервера в безопасности.
Еще одной рекомендацией будет использование другого порта для входящего ssh, желательно с номером порта больше 1000, например, порт 1522 (просто пример). Это необходимо для того, чтобы избежать обнаружения входящего сервиса ssh внешним сканированием портов. Просто измените входящий порт с 22 на порт с большим номером (например, 1522), но все равно оставьте его перенаправленным напорт 22на веб-сервере. Затем подключитесь к ssh-серверу извне, используя высокий номер порта (1522), и изнутри, используя порт 22.
Надеюсь, это будет вам полезно и вы решите свою проблему =)