можно » t доступ к внешнему IP-адресу вычислителя
Я установил экземпляр вычислительной машины Google и установил nginx, и теперь nginx прослушивает порт 80. У меня есть статический внешний IP-адрес, назначенный моему экземпляру, и я просто не могу получить доступ к своему внешнему IP-адресу.
Почему это должно быть так сложно? Все руководства просто говорят:
установите nginx и перейдите на внешний IP-адрес, и вы должны появиться на экране приветствия nginx.
Я установил правила брандмауэра для http / https, но ничего не работает. Вот несколько вещей, на которые стоит обратить внимание:
Конфигурация сервера nginx:
listen 80;
listen [::]:80;
server_name example.com;
root /var/www/example.com;
index index.html;
location / {
try_files $uri $uri/ =404;
}
снимок экрана экземпляра:
nginx запущен:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3490/nginx
tcp6 0 0 :::80 :::* LISTEN 3490/nginx
Я пытаюсь перейти на: 104.196.111.24 , но он просто говорит, что safari не удалось открыть страницу
, запущенную ifconfig возвращает это:
docker0 Link encap:Ethernet HWaddr 02:42:de:3f:fb:67
inet addr:172.18.0.1 Bcast:0.0.0.0 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth0 Link encap:Ethernet HWaddr 02:42:ac:11:00:02
inet addr:172.17.0.2 Bcast:0.0.0.0 Mask:255.255.0.0
inet6 addr: fe80::42:acff:fe11:2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1
RX packets:3802 errors:0 dropped:0 overruns:0 frame:0
TX packets:2248 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21591383 (20.5 MiB) TX bytes:351275 (343.0 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:54 errors:0 dropped:0 overruns:0 frame:0
TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3568 (3.4 KiB) TX bytes:3568 (3.4 KiB)
Закрытый порт 80
$ nmap -p80 104.196.111.24
Starting Nmap 6.40 ( http://nmap.org ) at 2016-03-09 16:25 CET
Nmap scan report for 24.111.196.104.bc.googleusercontent.com (104.196.111.24)
Host is up (0.14s latency).
PORT STATE SERVICE
80/tcp closed http
Это наводит на мысль, что в конфигурации брандмауэра что-то не так, несмотря на опции "Разрешить http трафик" и "Разрешить https трафик", которые проверяются на скриншоте. Сейчас я не знаю больше о конфигурации брандмауэра GCE.
(NB Несколько позже: на данный момент nmap сообщает, что хост не работает)
О моем первоначальном сообщении
Мое первоначальное сообщение, приведенное ниже, относится к экземпляру nginx, запущенному на реальном хосте. Я пропустил тот факт, что вы на самом деле работаете на виртуальной машине , где может быть нормально, что nginx прослушивает локальные адреса ("что-то другое" на хосте проксирует запросы к ВМ). Однако я не понимаю, почему внутренний IP адрес не отображается в вашем выводе ifconfig.
Начальное пост-контент:
Если я хорошо понимаю, то у вас на сервере запущен экземпляр nginx с адресом 104.196.111.24. И когда вы пытаетесь получить доступ к этому адресу в веб-браузере, вы получаете ошибку.
Так что я не совсем уверен, что это сработает, но я заметил, что ваш экземпляр nginx прослушивает порт 80 на 0.0.0.0 (ipv4), что такое локальный адрес. Википедия говорит об этом:
В интернет-протоколе версии 4, адрес 0.0.0.0 - это немаршрутизируемый мета-адрес, используемый для обозначения недействительного, неизвестного или неприменимая цель.
Более того:
В контексте серверов 0.0.0.0 означает "все IPv4-адреса на локальная машина".
Так что я думаю, что здесь есть что исправить, так как nginx, кажется, доступен только с локальных адресов на вашем сервере.
Более того, если я настрою себя nginx на прослушивание порта 80 на 0.0.0. 0 для любого из моих сайтов, то просмотр этого сайта вернет ошибку (как будто соединение было переинициализировано, а не ошибку от nginx).
Таким образом, я попытаюсь установить nginx для прослушивания порта 80 по внешнему адресу, например:
listen 104.196.111.24:80;
(и, конечно же, после этого проверьте, что это правильно с nginx -t, а затем перезагрузите правила nginx с помощью service nginx reload).
EDIT: дополнительная информация из ifconfig позволяет мне думать, что в сетевой конфигурации действительно что-то не так (или не настроено), но я не могу это объяснить: адрес сетевой карты (eth0, работает) 172.17.0.2, который принадлежит какому-то специальному зарезервированному диапазону адресов IANA. Я бы ожидал, что 104.196.111.24 появится в выводе ifconfig, но это не так. Я даже не понимаю, как можно ssh в 104.196.111.24 без его настройки. В любом случае, я думаю, что nginx не может быть доступен извне, пока он прослушивает 0.0.0.0, это, безусловно, должно быть исправлено, чтобы решить проблему, что может быть сделано путем исправления сетевой конфигурации.
Вы находитесь не в том месте. На основании результата ifconfig выглядит так, будто вы находитесь в google cloud shell, а не ssh в вашем экземпляре shell. Если вы находитесь в вашем экземпляре оболочки, результат ifconfig будет совпадать с внутренним ip адресом, показанным в консоли.
.Проверьте правила брандмауэра для VPC вашего проекта:
$ gcloud beta compute firewall-rules list
Если порт 80 TCP не покрыт, необходимо добавить:
$ gcloud beta compute firewall-rules create default-allow-http80 \
> --direction ingress --action allow --source-ranges 0.0.0.0/0
> --rules tcp:80