У меня есть виртуальная машина с двумя общедоступными IP-адресами. Я установил узел контроллера OpenStack на виртуальную машину. У меня есть доступ из внешней сети к службам Horizon и Keystone, работающим на веб-сервере apache2 на портах 80 и 5000 соответственно.
Однако, когда я запускаю службу Node.js Express на порту 3010, я не могу получить к ней доступ из внешней сети. Я могу получить к нему доступ с локального хоста и с других виртуальных машин, работающих на том же хосте.
Я попытался поместить в iptables следующие правила:
sudo iptables -A INPUT -p tcp -m tcp --dport 3010 -j ACCEPT
sudo ip6tables -A INPUT -p tcp -m tcp --dport 3010 -j ACCEPT
Ниже приводится результат работы sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
neutron-linuxbri-INPUT all -- anywhere anywhere
nova-api-INPUT all -- anywhere anywhere
ACCEPT tcp -- anywhere controller tcp dpt:3010
Chain FORWARD (policy ACCEPT)
target prot opt source destination
neutron-filter-top all -- anywhere anywhere
neutron-linuxbri-FORWARD all -- anywhere anywhere
nova-filter-top all -- anywhere anywhere
nova-api-FORWARD all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
neutron-filter-top all -- anywhere anywhere
neutron-linuxbri-OUTPUT all -- anywhere anywhere
nova-filter-top all -- anywhere anywhere
nova-api-OUTPUT all -- anywhere anywhere
Chain neutron-filter-top (2 references)
target prot opt source destination
neutron-linuxbri-local all -- anywhere anywhere
Chain neutron-linuxbri-FORWARD (1 references)
target prot opt source destination
Chain neutron-linuxbri-INPUT (1 references)
target prot opt source destination
Chain neutron-linuxbri-OUTPUT (1 references)
target prot opt source destination
Chain neutron-linuxbri-local (1 references)
target prot opt source destination
Chain neutron-linuxbri-sg-chain (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain neutron-linuxbri-sg-fallback (0 references)
target prot opt source destination
DROP all -- anywhere anywhere /* Default drop rule for unmatched traffic. */
Chain nova-api-FORWARD (1 references)
target prot opt source destination
Chain nova-api-INPUT (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere controller tcp dpt:8775
Chain nova-api-OUTPUT (1 references)
target prot opt source destination
Chain nova-api-local (1 references)
target prot opt source destination
Chain nova-filter-top (2 references)
target prot opt source destination
nova-api-local all -- anywhere anywhere
Ниже приводится результат работы sudo netstat -nap | grep 3010
tcp6 0 0 :::3010 :::* LISTEN 7538/node
что то же самое как sudo netstat -nap | grep 80
tcp6 0 0 :::80 :::* LISTEN 2932/apache2
который также совпадает с sudo netstat -nap | grep 5000
tcp6 0 0 :::5000 :::* LISTEN 2932/apache2
Я даже не могу telnet на 3010 из внешней сети.
У меня есть доступ только к виртуальной машине, но не к ее хосту. Поэтому я не могу установить NAT или переадресацию портов на хосте.
Кроме того, я не думаю, что для портов 80 и 5000 установлены какие-либо правила переадресации портов, поскольку эти службы были автоматически запущены OpenStack после создания на виртуальной машине (и у меня нет доступа к хосту, поэтому я не могу установить эти правила переадресации портов себя).
Ufw также отключен. Я проверил, используя его sudo ufw status, который отображается как неактивный.
Мне нужно знать, что я могу сделать, чтобы получить доступ к службе, работающей на порту 3010, из внешней сети.
Я ненавижу iptables -L вывод. не уверен, как кто-нибудь это читает. iptables-save король и iptables -S обычно подойдет в крайнем случае. (Только личные анекдоты).
Давайте пройдемся по процессу устранения неполадок:
Iptables
Насколько я могу судить, единственное DROP заявление в вашем брандмауэре никогда не упоминается. (Напр .: недоступен). Если порт 80 работает без специальной инструкции брандмауэра, можно с уверенностью сказать, что проблема не в брандмауэре. Если вы хотите быть полностью уверены, отключите брандмауэр. Промыть столы и полностью открыть. Я предполагаю, что соединение по-прежнему не работает.
Прослушивание
Поскольку netstat сообщает, что процесс прослушивает данный порт, мы можем предположить, что порт был привязан к нему.
Это оставляет нам два направления поиска и устранения неисправностей. Внутрь к приложению и наружу к вашему [конечному пользователю] соединению.
Принятие
Приложение необходимо привязать к порту, чтобы LISTEN. Как только это будет сделано, приложение должно ACCEPT любые входящие соединения. Я сомневаюсь, что есть проблема именно в этом виде спорта, но есть вероятность, что здесь есть какая-то ошибка в логике приложения, которая где-то зависает и не позволяет принимать соединения.
ssh user@yourserver.example.com
> telnet 127.0.0.1 3010
Если вы установили соединение, это не проблема ACCEPT в приложении.
Внешние влияния
Если вы можете установить соединение с сервером с сервера, значит, мешает какой-то внешний объект. Изменение приложения для прослушивания на другом порту может позволить трафику проходить, но вы все равно должны определить, находится ли мешающий брандмауэр и т. Д. В вашем помещении или где-то между вашим собственным DMARC и вашим сервером.
Если все это не удается, вы можете попробовать:
-A INPUT -m tcp -p tcp --dport 3010 -j LOG
-A OUTPUT -m tcp -p tcp --sport 3010 -j LOG
просто чтобы посмотреть, не происходит ли что-нибудь странное со стеком TCP, которое может указать вам на решение. tcpdump является альтернативой правилам iptables.