Невозможно получить доступ к Node Server из внешней сети
У меня есть виртуальная машина с двумя общедоступными 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 сообщает, что процесс прослушивает данный порт, мы можем предположить, что порт был привязан к нему.
Это оставляет нас с два направления поиска и устранения неисправностей. Внутрь к приложению и наружу к вашему соединению [конечного пользователя].
Принятие
Приложение должно привязаться к порту для СЛУШАТЬ . Как только это будет сделано, приложение должно ПРИНИМАТЬ любые входящие соединения. Я сомневаюсь, что есть проблема именно в этом виде спорта, но есть вероятность, что здесь есть какая-то ошибка в логике приложения, которая где-то зависает и не позволяет принимать соединения.
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.