У меня есть виртуальная машина Ubuntu 16.04, и когда я запускаю curl http://192.168.254.42 (IP-адрес eth0) он быстро отвечает отказом в соединении. Однако сервер определенно слушает 0.0.0.0 и могут быть доступны другим компьютерам в сети, используя тот же адрес в браузере. curl http://192.168.254.1 возвращает html страницы администратора моего маршрутизатора.
Конечно, обычно это не будет блокировщиком, но это также означает, что клиенты VPN, подключенные к серверу, не могут получить доступ к самому серверу, используя IP-адрес eth0 (который используют клиенты в сети). Я никогда раньше не сталкивался с этой проблемой, и Google предлагает очевидное «прослушивание на локальном хосте», что здесь не так.
Я могу пинговать ip-адрес eth0 с терминала (т.е. пинговать сам), и он отвечает правильно. Трассировка от VPN-клиента также выглядит правильно. Но доступ к http://192.168.254.42 немедленно отвечает отказом в соединении.
Вот это netstat -tulpn вывод.
$ netstat -tulpn | grep :80
tcp6 0 0 :::80 :::* LISTEN 5724/index-lib
$ netstat -tulpn | grep :85
tcp6 0 0 :::85 :::* LISTEN 1212/server.js
$ netstat -tulpn | grep :81
tcp6 0 0 :::81 :::* LISTEN 1515/apache2
Установка порта 86 работает. Другой сервер NodeJS также работает на 85-м порту, и к нему можно получить доступ. Так что это не проблема со стороной NodeJS.
Веб-сервер - это единственный экземпляр HTTP-сервера NodeJS v10.16.3, который прослушивает 0.0.0.0.
Слушая 192.168.254.42 тоже не работает.
Что еще более важно, веб-сервис Apache, прослушивающий порт 81, может быть легко доступен.
Chrome говорит ERR_CONNECTION_FAILED, но делает это практически мгновенно.
Правила iptables не установлены.
Процесс NodeJS прослушивает порт 85, и к нему можно получить доступ таким же образом.
Вот это netstat -tulpn вывод.
$ netstat -tulpn | grep :80
tcp6 0 0 :::80 :::* LISTEN 5724/index-lib
$ netstat -tulpn | grep :85
tcp6 0 0 :::85 :::* LISTEN 1212/server.js
$ netstat -tulpn | grep :81
tcp6 0 0 :::81 :::* LISTEN 1515/apache2
Чтобы проверить это, я использую команду
$ curl http://192.168.254.42
curl: (7) Failed to connect to 192.168.254.42 port 80: Connection refused
Порт 81 и 85 возвращают ожидаемый HTML.
Настройка прослушивания порта 86 делает его доступным! Так что это не на стороне NodeJS, я не думаю.
У меня нет представителя, который мог бы опубликовать комментарий с просьбой о разъяснении, поэтому я просто собираюсь ответить на этот вопрос. Вы говорите о том, какой IP-адрес прослушивает ваше приложение узла, однако мне никогда не приходилось настраивать его ни в одном из моих приложений узла. Я предполагаю, что у вас есть код, который выглядит примерно так:
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.write('Hello World!');
res.end();
}).listen(8080, 0.0.0.0);
И порт, и ip здесь не являются обязательными, поэтому, если вы хотите прослушивать порт 80, просто отключите их оба. Если вы слушаете другой порт, откажитесь от IP и позвольте Node выяснить это.
Вы упомянули сервер Apache на 81, я предполагаю, что вы пытаетесь подключиться к Node напрямую, и вы не проходите через Apache, чтобы добраться до Node.
Если приведенное выше не помогает опубликовать соответствующий код из вашего приложения узла, cat /etc/hosts, и sudo netstat -tulpn. Если вы используете Apache, опубликуйте также соответствующие конфигурации Apache (т.е. запись виртуального хоста в /etc/apache2/sites-enabled/).
Я нашел эту строку в /etc/rc.local.
iptables -t nat -A OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080
Обнаружена проблема!
В этом ответе говорится, почему правило не появилось в iptables -L: https://serverfault.com/a/685948/32875.
Есть 5 таблиц (фильтр, нат, исключение, сырье, безопасность). Ты звонишь
iptables -L -t tableдля каждого.