Невозможно получить доступ к контейнеру через локальный хост или IP-адрес хоста, несмотря на правильную привязку, но можно получить доступ к контейнеру через частный IP-адрес
Я пытаюсь создать контейнер Podman, на котором работает мой веб-сервер node-js. Хотя по какой-то причине я не могу получить к нему доступ через localhost:443, но я могу получить к нему доступ через частный IP-адрес контейнера, например (10.88.0.5:443).
Вы можете видеть это, когда я скручиваю частный IP-адрес:
curl https://10.88.0.5
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above
(это не удается только потому, что для моего домена выдан сертификат SSL, но, по крайней мере, он действительно может связаться с веб-сайтом.)
curl https://localhost --connect-timeout 5
curl: (28) SSL connection timeout
время соединения истекло.
Смотря на
sudo netstat -tulp | grep https
вы можете видеть, что веб-сервер правильно привязан к 443:
tcp 12 0 0.0.0.0:https 0.0.0.0:* LISTEN 4991/conmon
Подман сообщает то же самое:
sudo podman port -l
443/tcp -> 0.0.0.0:443
Вот мой файл-контейнер:
FROM node:22.2.0
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 443
CMD ["node", "."]
Вы можете видеть, что порт 443 открыт.
Вот конфигурация сети, в которой работает контейнер:
[
{
"name": "podman",
"id": "2f259bab93aaaaa2542ba43ef33eb990d0999ee1b9924b557b7be53c0b7a1bb9",
"driver": "bridge",
"network_interface": "podman0",
"created": "2024-07-10T12:43:23.144060349-04:00",
"subnets": [
{
"subnet": "10.88.0.0/16",
"gateway": "10.88.0.1"
}
],
"ipv6_enabled": false,
"internal": false,
"dns_enabled": false,
"ipam_options": {
"driver": "host-local"
}
}
]
и моя таблица маршрутизации:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default mynetwork 0.0.0.0 UG 0 0 0 eno2
10.88.0.0 0.0.0.0 255.255.0.0 U 0 0 0 podman0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eno2
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
Я попробовал отключить UFW. Я попробовал полностью переустановить Podman. Ни один из них не сработал. Дайте мне знать, если я делаю что-то не так или вы хотите, чтобы я что-то попробовал. Я пытался это исправить уже 4 дня. Если кто-нибудь может помочь, это будет очень признательно.
К вашему сведению. Я использую последнюю версию Debian.
@DavidMaze Я чувствую себя идиотом. Я использовал Cockpit для запуска контейнера (который работал по большей части), но когда вы запросили MRE, я решил просто попытаться создать команду, которая делала бы то же самое, что и Cockpit. Это сработало, когда я попробовал сделать это сам, никаких проблем. Я так рад и так раздражен одновременно. Также, чтобы ответить на ваш вопрос, контейнер определенно прослушивал 0.0.0.0:443, но я не совсем уверен, в чем на самом деле была проблема. Я буду разглагольствовать об этом в ответе, чтобы отметить это как завершенное.
Ответы 1
Проблемы с кабиной у podman.
Если вы используете Cockpit и задаетесь вопросом, почему контейнер может быть недоступен должным образом за пределами сети, основной причиной может быть Cockpit. По какой-то причине, несмотря на правильную привязку, возникает проблема при инициализации контейнера через Podman.
Решение:
Решение довольно простое: просто убедитесь, что вы создали контейнер и сначала запустили его через Podman. В моем случае мне пришлось использовать эту команду:
sudo podman run -d -p 443:443/tcp --restart always --name webserver localhost/nodeserver
Просто помните, что это синтаксис использования флага публикации (-p):
-p=[[ip:][hostPort]:]containerPort[/protocol]
согласно документации.
Конечный результат:
Теперь у вас есть работающий контейнер, которым можно управлять через Cockpit, поскольку, похоже, вам нужно беспокоиться только об инициализации. Таким образом, вы по-прежнему можете останавливать, запускать и использовать все другие функции управления, предоставляемые Cockpit, как показано на изображении ниже. Я мог бы решить создать отчет об ошибках на официальном Github Cockpit.
Можете ли вы отредактировать вопрос, включив в него минимально воспроизводимый пример? Действительно ли процесс в контейнере прослушивает 0.0.0.0:443 или где-то еще? Какую команду вы выполнили для запуска контейнера?