У меня возникли проблемы с доступом к службе, работающей в док-контейнере (порт 5005), из Интернета через TCP.
Сервер представляет собой экземпляр ubuntu AWS ec2 с портом 5005, открытым в группе безопасности (адресация как v4, так и v6).
Процессы докеров работают нормально, кажется, что они сопоставляют порт внутри своего контейнера с экземпляром ec2.
ubuntu@ip-172-31-5-89:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
71e620ea2969 rasa/rasa-sdk:latest "./entrypoint.sh sta…" 15 minutes ago Up 15 minutes 0.0.0.0:5055->5055/tcp, :::5055->5055/tcp emma_action_server_1
533010182ca7 rasa/rasa:latest-full "rasa run --enable-a…" 15 minutes ago Up 15 minutes 0.0.0.0:5005->5005/tcp, :::5005->5005/tcp emma_rasa_1
(да, 5005 и 5055 являются допустимыми портами, а не опечаткой, но только 5005 должен быть открыт для экземпляра ec2 и выше через брандмауэр в Интернет. ufw, кажется, сигнализирует о том, что порт в порядке.
Status: active
To Action From
-- ------ ----
5005/tcp ALLOW Anywhere
5005 ALLOW Anywhere
22 ALLOW Anywhere
5005/tcp (v6) ALLOW Anywhere (v6)
5005 (v6) ALLOW Anywhere (v6)
22 (v6) ALLOW Anywhere (v6)
и экземпляр ec2, похоже, нормально слушается:
ubuntu@ip-172-31-5-89:~$ sudo netstat -plunta | grep LISTEN
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 561/systemd-resolve
tcp 0 0 0.0.0.0:5055 0.0.0.0:* LISTEN 6473/docker-proxy
tcp 0 0 0.0.0.0:5005 0.0.0.0:* LISTEN 6451/docker-proxy
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 810/sshd: /usr/sbin
tcp6 0 0 :::5055 :::* LISTEN 6480/docker-proxy
tcp6 0 0 :::5005 :::* LISTEN 6458/docker-proxy
tcp6 0 0 :::22 :::* LISTEN 810/sshd: /usr/sbin
Тем не менее, когда я пытаюсь получить доступ к public.IP.address:5005 с помощью любого онлайн-инструмента проверки портов, он говорит, что порт закрыт. Когда я на самом деле пытаюсь сделать запрос POST через почтальона, я получаю ETIMEDOUT, который я не уверен, является другим способом сказать, что он закрыт, или на самом деле это просто тайм-аут... но когда я делаю тот же запрос POST на сервере, используя локальная адресация работает нормально.
Это работает локально на ec2 (вне контейнера):
curl -XPOST localhost:5005/webhooks/rest/webhook -d '{"message":"hi"}'
это не работает - ETIMEOUT:
curl -XPOST publicIPAddressHere:5005/webhooks/rest/webhook -d '{"message":"hi"}'
ACL и сеть также настроены правильно.
Когда я запускаю анализатор достижимости, он работает, но это, очевидно, происходит изнутри сети с частного IP-адреса... 172... так что проблема явно в том, что порт открыт для всего мира.
Я использую инструменты онлайн-проверки портов. Оба инструмента, которые я пробовал, сказали мне, что порт закрыт для публики.
(что, как я понимаю, может означать либо то, что порт не разрешен — очень трудно поверить, учитывая, что конфигурация прошла проверку нормально), либо служба по какой-то причине не отвечает своевременно снаружи сервера (только изнутри контейнер на сервер, на котором он размещен)
у вас есть какие-либо настраиваемые сетевые ACL? Попробуйте анализатор достижимости, как показано на скриншоте
@SathyajithBhat - анализатор достижимости говорит, что он виден от одного экземпляра к другому на этом порту ..... Назначение i-0f996b5e5fb48e1f6 (rasax86) Входящий заголовок Адрес назначения 172.31.xx.xx/32 Диапазон портов назначения 5005-5005 Протокол TCP Адрес источника 172.31.xx.xx/32 Диапазон исходных портов 0-65535
Я должен сказать - это частный IP-адрес - когда я использую общедоступный IP-адрес в качестве пункта назначения - он недоступен.
Обновлен вопрос, чтобы показать, что ACL также настроен правильно.
Вы можете сделать скриншот анализатора достижимости, когда он терпит неудачу? он должен сказать вам, почему он терпит неудачу. Есть ли балансировщик нагрузки перед инстансом?
Это не терпит неудачу .... я могу использовать только экземпляры amazon ec2, чтобы попытаться получить доступ к службе, и aws использует внутренний частный IP-адрес целевого сервера, а не общедоступный IP-адрес, поэтому я не могу использовать доступность для проверки общедоступного IP-адреса - вот где у меня проблема. Нет балансировщика нагрузки.
Я смог заставить это работать, создав новый экземпляр ec2 в своем собственном VPC/ACL с той же конфигурацией, что и выше.
На самом деле это не ответ, так как это обходной путь - гремлины в системе.
Ваш ответ может быть улучшен с помощью дополнительной вспомогательной информации. Пожалуйста, отредактируйте , чтобы добавить дополнительные сведения, такие как цитаты или документация, чтобы другие могли подтвердить правильность вашего ответа. Вы можете найти больше информации о том, как писать хорошие ответы в справочном центре.
вы пытались отследить маршрут от вашего физического компьютера до экземпляра amazon ec2, sudo traceroute -T --tcp -p 5005 public_ip_here