
У меня есть сервер, на котором размещен веб-сайт, работающий по протоколу https на порту 443. Веб-сайт не открыт напрямую для публичного Интернета, но трафик направляется через VPN с экземпляра EC2, имеющего публичный IP-адрес.
Доступ к веб-сайту возможен с хост-сервера, компьютеров в той же внутренней сети и компьютеров в VPN, которые не являются экземпляром EC2.
Выполнение команды openssl s_client -connect www.mydomain.tld:443
с любой из этих машин дает ответ:
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = cloud.hss.ac.uk
verify return:1
---
Certificate chain......
[Truncated for brevity]
Однако та же команда, введенная на экземпляре EC2 или с машины за пределами внутренней или VPN-сети, дает ответ:
CONNECTED(00000003)
Итак, соединение есть, но SSL-сертификатов нет?
Установка уровня журнала на отладку в файле конфигурации Apache показывает, что SSL-сертификаты обслуживаются, но по какой-то причине они не достигают экземпляра EC2.
Экземпляр EC2 просто транслирует входящие запросы на портах 80 и 443 на сервер хостинга с помощью IFtables. Вот настройки в/etc/nftables.conf
#!/usr/sbin/nft -f
flush ruleset
table ip nat {
chain prerouting {
meta nftrace set 1
type nat hook prerouting priority -100; policy accept;
iifname "eth0" tcp dport { 80, 443 } dnat to x.x.x.x
counter
}
chain postrouting {
meta nftrace set 1
type nat hook postrouting priority 100; policy accept;
masquerade
}
}
Все это прекрасно работает на порту 80.
У меня заканчиваются идеи, поэтому ищу их здесь.
VPN — это Hamachi VPN, если это имеет значение.
Переадресация IP включена:
sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1