Апачская локальная сеть внешней стороны/внутренней части веб-сервера доступа наклона

Я приношу извинения заранее, если я использую какие-либо технические слова неправильным способом. Я - все еще новичок к Linux/сетям

Я пытался выяснить эту проблему больше недели, и ни один из связанных других вопросов не попросил помогать мне. Я недавно создал веб-сервер, работающий apache2 для хостинга моего собственного сайта. Я также намеревался использовать его для SSH, FTP и VNC. Я зарегистрировал домен в GoDaddy, cokongwu.com. Статический IP (192.168.0.105) был установкой для сервера, и у меня есть установка portforwarding также для порта 80, 21, 23, 53 и 443 к статическому IP, читая руководства по тому, как установить публично доступный веб-сервер, я думал, что это было всем, что было необходимо, поскольку это работало отлично сначала, но конечно я узнал, что, после того как пытался получить доступ к веб-серверу с помощью доменного имени вне сети, я не мог соединиться. Еще после некоторого поиска я узнал, что должен был изменить мой запись в моем зональном файле в GoDaddy к моему общедоступному IP, После того как я сделал это, я нашел, что больше не смог соединиться со своим веб-сервером вообще, любая внутренняя часть сеть, где я вместо этого буду redirecred к странице маршрутизатора, а также вне сети, где соединение просто испытало бы таймаут. Я позже выяснил, что, так как мой общедоступный IP не мог быть установлен на помехи, я должен был использовать сервис, конкретно dyndns так, чтобы это смогло постоянно обновить IP, когда это изменится. Я устанавливаю dyndns updater от обновления программного обеспечения, центрируют и устанавливают мою учетную запись dyndns, cokongwu.com, с запись, которая указывает на мой общедоступный IP и псевдоним на www.cokongwu.com, который указывает на cokongwu.com. Я также устанавливаю имя хоста, cokongwu.dyndns.org, который также указывает на мой общедоступный IP и добавил dyndns серверы имен к серверам имен Godaddy. Запись у меня есть для cokongwu.com в godaddy неподвижных точках к моему внутреннему IP и записям CName (www и cokongwu.com) обе точки на cokongwu.dyndns.org. (однако, так как я заменил godaddys серверы имен dyndns серверами имен, я больше не могу управлять зональным файлом для домена),

В конце концов, это, пытаясь получить доступ к hostname.com все еще обеспечивает те же проблемы как прежде. Доступ к нему указывает на мой общедоступный IP вместо моего внутреннего IP, но в сети я просто передаюсь своей странице установки маршрутизаторов, и вне сети это просто испытывает таймаут. Я вне идей относительно того, как зафиксировать это, таким образом, любые идеи приветствуются. Shouldnt это (общедоступный 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                :::*                                -       

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
3
задан 15 March 2015 в 19:50

1 ответ

Из того, что я понимаю, что у Вас есть следующие проблемы:

1 - Невозможно получить доступ к веб-серверу (использующий FQDN, "полностью определенное доменное имя" www.cokongwu.com) из LAN?
2 - Вы не можете проверить функциональность веб-сайта с внешней стороны?

1 - Доступ к веб-серверу от внутреннего использования FQDN.
Я не вижу в Вашем вопросе от того, где Вы пытаетесь получить доступ к веб-серверу, таким образом, я предположу, что это от отдельного клиента в LAN.

Так как Вы, скорее всего, используете внешний сервер DNS, Ваш запрос на www.cokongwu.com разрешит общедоступный IP-адрес, означая за пределами Вашего Вашего маршрутизатора интернета (см. ниже). Начиная с того трафика маршрута привычки маршрутизатора, приходящего к внешнему IP-адресу от внутренней спины до внутренней части, трафик остановится в той точке.

Чтобы вещи работали в сети, www.cokongwu.com wil должен быть разрешен как Ваш внутренний IP-адрес (192.168.0.105). Можно попытаться просмотреть веб-сайты сервер с помощью внутреннего IP-адреса, но так как Вы планируете использовать SSL, в конечном счете который потребует, чтобы Вы получили доступ к веб-серверу с помощью FQDN, или Вы получите ошибки сертификата.

"Твердый путь" для фиксации внутреннего определения имен состоит в том, чтобы установить внутренний сервер DNS, но вышеупомянутое будет работать стрельба проблемы и мелкомасштабное развертывание. Вы не кажетесь никаким незнакомцем Google и если Вы хотите настроить внутренний сервер DNS, существуют многие руководства по этому в Интернете.

После того как внутреннее определение имен дает Вам, внутренний IP-адрес, просматривая к веб-серверу даст тот же ответ, как будто Вы мы - клиент, приезжающий из внешней стороны.

2 - внешний доступ к веб-серверу.
Разрешение www.cokongwu.com с dig www.cokongwu.com +noall +answer дал мне следующий ответ.

www.cokongwu.com. 0 В cokongwu.com CNAME.
cokongwu.com. 59 В 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, могло бы случиться так, что Вы или не портировали вперед правильно или если Вы используете маршрутизатор в сочетании со своим модемом, Вы правильно не соединили модем мостом к маршрутизатору, чтобы позволить этому обрабатывать все portforwarding запросы.

Некоторые дальнейшие размышления
Я замечаю, что Вы упомянули порт 53 как один из портов, переданных веб-серверу. Порт 53 UDP является стандартом для входящих запросов DNS. Если у Вас на самом деле нет сервера DNS, работающего на машине веб-сервера, можно безопасно закрыть этот порт... она, привычка служит любой цели так или иначе.

Я также заметил, что Вы упоминаете, что использовали ssh и ftp, но открытый порт 21 и 23 в брандмауэре и переданный веб-серверу. Порт 23 является портом telnet, и порт 21 является портом FTP. Я настоятельно рекомендовал бы не использовать ни один из этих сервисов, так как они - и небезопасные протоколы, которые передадут все в открытом тексте, включая имена пользователей и пароли.

Я рекомендую только открыться и порт пересылки 22 в брандмауэре. Порт 22 используется ssh, который является encryopted заменой к telnet. Порт 22 также используется scp сервисом, которые используют ssh сервис для передачи файлов. Используя ssh и scp вместо telnet и ftp сохранит весь Ваш трафик к и от веб-сервера безопасным.
Дальнейшая рекомендация состояла бы в том, чтобы использовать другой порт для поступления ssh, предпочтительно номер порта более чем 1 000, как порт 1522 (просто пример). Это должно избежать поступления ssh сервис, который будет обнаружен сканированиями внешнего порта. Просто измените входящий порт от 22 до более высокого номера порта (т.е. 1522), но все еще сохраните переданным для портирования 22 на веб-сервере. Затем получите доступ к ssh серверу от внешнего использования высокого номера порта (1522) и от внутреннего порта использования 22.

Я надеюсь, что это имеет любое применение для Вас и надежды, Вы решаете свою проблему =)

2
ответ дан 1 December 2019 в 17:03

Другие вопросы по тегам:

Похожие вопросы: