Виртуальные хосты Apache недоступны публично после переадресации портов

Виртуальные хосты Apache недоступны публично после переадресации портов

Я решил установить Proxmox на своем новом сервере для размещения веб-серверов, серверов электронной почты и VPS. Таким образом, я могу настроить несколько виртуальных машин для каждого типа сервера.

Я выбрал Debian 9 для своего веб-сервера Apache. И мне уже удалось импортировать мои сайты WordPress, импортированные с помощью плагина duplicator, и это работало безупречно. Я отредактировал таблицу WP_Options в PHPMyAdmin на https вместо HTTP в качестве URL сайта, затем я настроил свой виртуальный хост Apache следующим образом (mydomain.com.conf)

<VirtualHost *:80>
    ServerName mydomain.com
    ServerAdmin root@localhost
    Redirect "/" "https:// mydomain.com"
</VirtualHost>

<VirtualHost *:443>
    ServerAdmin root@localhost
    DocumentRoot /var/www/mydomain.com
    ServerName mydomain.com
    ServerAlias www.mydomain.com
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/mydomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.com/privkey.pem

    <Directory /var/www/mydomain.com>
        AllowOverride All
        DirectoryIndex index.php
        Require all granted
    </Directory>

</VirtualHost>

Я могу получить доступ к своему веб-сайту локально, установив правило в файле hosts Windows следующим образом:

192.168.10.104      mydomain.com

Я также установил статический IP, чтобы избежать получения веб-сервером нового IP-адреса. Я сделал это в /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
iface ens18 inet static
address 192.168.10.104
netmask 255.255.255.0
gateway 192.168.10.1

# This is an autoconfigured IPv6 interface
iface ens18 inet6 auto

Хочу отметить, что я создал виртуальный хост для своего [публичного IP-адреса][1].

Чтобы избежать конфликтов, я отключил брандмауэр UFW и удалил fail2ban. Пока что.

На мой взгляд, DNS, серверы имен и переадресация портов настроены правильно. Однако я могу ошибаться.

[Конфигурации NS моего регистратора доменов][2]

[Мои конфигурации DNS на DigitalOcean][3]

[Мои конфигурации переадресации портов][4]

Если я пытаюсь зайти на свой сайт с помощью [UpTrends][5], я получаю сообщение "TCP Connection Failed". С моей локальной точки зрения на сайте также нет проблем с моим SSL-сертификатом.

Любой совет?

решение1

Окончательно!

Оказалось, что для решения проблемы достаточно было просто перезапустить маршрутизатор (отключив питание на 10 секунд) в дополнение к перезапуску сервера.

Иногда проблемы можно решить простым, но неожиданным способом:)

решение2

Ваша конфигурация DNS верна, и при посещении http://example.comуспешно устанавливается соединение с publicip:80 и выполняется HTTP-перенаправление.

Однако подключение к publicip:443 (т.е. https://example.com) возвращает ICMP-сообщение «Хост недоступен», которое в данном случае должно исходить либо от вашего маршрутизатора (устройства с публичным IP-адресом, будь то хост Proxmox или выделенный маршрутизатор — неважно), либо от самого веб-сервера.

Поскольку ошибка ICMP возникает с задержкой, онавероятнопоступает от маршрутизатора и указывает на то, что правило переадресации порта для :443 указывает на неправильный IP-адрес (который не используется, т.е. истекло время ожидания ответа ARP).

(Если бы это была блокировка брандмауэра, попытка подключения немедленно вернула бы ошибку RST или ICMP, или вообще ничего.)

Если настройкисмотретьправильно, используйте tcpdump, чтобы взглянуть на то, что естьна самом делепроисходит. Запуск tcpdump -e -n -i <interface> "arp or port 443"на хосте Proxmox (на интерфейсе, обращенном к вашей веб-виртуальной машине) покажет фактический IP-адрес, к которому пытается обратиться правило переадресации портов.


То же самое применимо и в целом; недостаточно просто выключить что-то. Вам также нужно посмотреть натекущийправила брандмауэра (фактический брандмауэр — это либо iptables, либо nft); т. е. проверка того, соответствует ли текущее состояние запрошенному состоянию. Вы не можете быть уверены, что отключение ufw оставило брандмауэр полностью пустым, пока не проверите с помощью iptables-save, iptables-legacy-save, nft list ruleset.

Связанный контент