Веб-сервер недоступен извне сервера.

Вопрос или проблема

У меня есть облачный сервер Hetzner на Debian, и я пытаюсь разместить на нем сайт, но, к сожалению, каждый раз, когда я пытаюсь получить к нему доступ, соединение просто истекает по времени.
Я пробовал как Apache2, так и Nginx и смог настроить оба так, чтобы я мог успешно получить доступ к сайту на сервере, используя команду curl [domain] (не IP, а домен), но выполнение того же на любой другой системе или в браузере не работает, и соединение просто истекает по времени.
Следующая команда ufw status:

To                         Action      From
--                         ------      ----
WWW                        ALLOW       Anywhere
22/tcp                     ALLOW       Anywhere
443                        ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
Nginx Full                 ALLOW       Anywhere
WWW (v6)                   ALLOW       Anywhere (v6)
22/tcp (v6)                ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
Nginx Full (v6)            ALLOW       Anywhere (v6)

Сам домен также настроен правильно, проверка его A или AAAA-записей указывает на IP моего облака Hetzner. Имена серверов находятся на Porkbun, а не на Hetzner, но это не должно быть проблемой, насколько я знаю.
Выполнение MTR дает следующее (первые несколько шагов удалены для конфиденциальности, но у них не было потерь данных):

|                          Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|---------------------------------------------------|------|------|------|------|------|------|
|                       decix-gw.hetzner.com -    0 |   81 |   81 |   10 |   11 |   12 |   11 |
|                    core12.nbg1.hetzner.com -    0 |   81 |   81 |   11 |   11 |   12 |   11 |
|            spine16.cloud1.nbg1.hetzner.com -    0 |   81 |   81 |   11 |   11 |   13 |   12 |
|             spine1.cloud1.nbg1.hetzner.com -    0 |   81 |   81 |   11 |   15 |   67 |   26 |
|                         Request timed out. -  100 |   17 |    0 |    0 |    0 |    0 |    0 |
|                      11236.your-cloud.host -    0 |   81 |   81 |   11 |   11 |   12 |   11 |
|static.76.42.203.116.clients.your-server.de -    0 |   81 |   81 |   11 |   12 |   31 |   12 |

Я также связался с поддержкой Hetzner, и они подтвердили, что с их стороны проблем нет.

Для уточнения вопроса: как я могу убедиться, что сайт на сервере может быть доступен без постоянного тайм-аута?

Только SSH кажется доступным извне (внутри портов ≥1000).

$ nmap static.76.42.203.116.clients.your-server.de -Pn
Starting Nmap 7.93 ( https://nmap.org ) at 2025-01-03 18:41 EET
Nmap scan report for static.76.42.203.116.clients.your-server.de (116.203.42.76)
Host is up (0.050s latency).
Not shown: 999 filtered tcp ports (no-response)
PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned in 9.04 seconds

Как вы написали, ваш внутренний брандмауэр имеет эти порты открытыми, но это, вероятно, проблема с внешним брандмауэром; статический брандмауэр Hetzner Online.

Ответ или решение

Проблема с недоступностью веб-сервера на вашем облачном сервере Hetzner может вызывать немало разочарований, особенно с учетом того, что сервер, судя по информации, корректно отвечает на запросы изнутри. Давайте разберем возможные причины и решения этой проблемы.

F – Fact (Факты):

Ваша конфигурация на сервере Debian, судя по описанию, настроена правильно: веб-серверы Apache2 и Nginx работают, и соединение через curl [domain] на самом сервере выполняется без проблем. Настроенные записи DNS также указывают на правильный IP-адрес сервера, а ufw показывает, что нужные порты (80, 443) открыты как для IPv4, так и для IPv6. Однако, тесты MTR и nmap показывают, что лишь SSH (порт 22) доступен извне, а остальные порты видятся как фильтрованные или недоступные.

O – Originality (Оригинальность):

Основной упор в этой ситуации стоит сделать на внешние факторы, так как внутренняя конфигурация подтверждена работоспособной. Вероятней всего, проблема связана с внешними факторами, одной из которых является стейтлесс-файрвол Hetzner. Данный файрвол может блокировать доступ к определенным портам по умолчанию.

R – Relevance (Релевантность):

Проверка Hetzner Firewall:
Перейдите в панель управления Hetzner и убедитесь, что в разделе настройки файрвола статайстического маршрутизатора нет ограничений на входящие соединения для портов 80 и 443. Откройте необходимые порты, если будет найдено, что они блокированы.
Проверьте DNS-кеш:
Убедитесь, что DNS-кеш на клиентской машине не устраивает старые некорректные записи, используя nslookup или dig, чтобы убедиться, что ваш домен действительно указывает на правильный IP-адрес.
Проверка конфигурации Nginx/Apache:
Хотя веб-сервер доступен изнутри, это не отключает необходимость удостовериться, что VirtualHost настроен правильно и не использует ограничения, такие как Listen или Allow для IP, отличных от всех (*).

E – Expertise (Экспертность):

Исходя из представленной информации и опыта, наиболее логичным объяснением является внешний файрвол Hetzner, блокирующий входящие подключение на порты 80 и 443. Проблема может быть связана и с дополнительными настройками сетевого оборудования или внешних DNS-сервисов.

S – Solution (Решение):

В первую очередь, проверьте и измените настройки стейтлесс-файрвола Hetzner, расширив список разрешенных портов для определенного IP-адреса или адресов.
Обновите DNS-кеш вашей системы или тестируйте из другой сети с обновленной маршрутизацией.
Перезапустите web-серверы после изменения конфигурации для применения всех изменений.

T – Tie-back (Заключение):

Следуя представленным шагам, вы сможете локализовать и устранить проблемы с соединением к вашему веб-серверу извне. Учитывая важность доступности веб-ресурсов, своевременное выявление и устранение причин тайм-аутов поможет обеспечить надежность и доступность вашего проекта.