Может ли SSH и подключиться к порту 80 (с прослушиванием nginx), но не может пропинговать или подключиться к любому другому порту (похоже?)

Всю неделю ломая голову над этим, и, поскольку пятница подходит к концу, я решил попросить Интернет посмотреть, есть ли у кого-нибудь какие-либо идеи вообще.

Я собираюсь выбросить всю информацию, которую я думаю, что это может быть уместно, но я также опускаю много информации, которая, по моему мнению, не имеет отношения к делу


У меня есть экземпляр в облаке, на котором работает Ubuntu. Инженер из другого отдела настроил его для меня, и для того, чтобы я смог в него войти, мне нужно использовать клавишу .pem

ssh -i mykey.pem ubuntu@IPOMITTED

Чтобы проверить свою работоспособность, я установил nginx, и я успешно попал на страницу приветствия, когда я попал на сервер w /
$ curl http://IPOMITTED:80

Welcome to nginx!

If you see this page, the nginx web server is successfully installed and working. Further configuration is required.

...

Но, если я попытаюсь пропинговать сервер, произойдет сбой

ping IPOMITTED
PING IPOMITTED (IPOMITTED): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
...

Что бы ни было, не может быть проблемой.

Проблема в том, что я пытаюсь запустить сервер Sync Gateway, который прослушивает порт 4984.

Я уверен, что я установил его правильно, так как я могу ударить его, если я сделаю запрос локально. Я не уверен, что мне не хватает какой-то конфигурации, вот две соответствующие строки в файле конфигурации для sync_gateway (но в этом файле больше ничего нет)

"adminInterface": "127.0.0.1:4985",
"interface": ":4984",

Вот моя сеть stat:

sudo netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:4985          0.0.0.0:*               LISTEN      2148/sync_gateway
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1070/sshd       
tcp6       0      0 :::4984                 :::*                    LISTEN      2148/sync_gateway
tcp6       0      0 :::22                   :::*                    LISTEN      1070/sshd       
udp        0      0 0.0.0.0:68              0.0.0.0:*                           921/dhclient    

Вот что я получаю, когда делаю локальный запрос:

$ curl localhost:4984
{"couchdb":"Welcome","vendor":{"name":"Couchbase Sync Gateway","version":"2.0"},"version":"Couchbase Sync Gateway/2.0.0(832;2d8a6c0)"}

Но если я пытаюсь сделать запрос удаленно:

$ curl IPOMITTED:4984
curl: (7) Failed to connect to IPOMITTED port 4984: Operation timed out

У кого-нибудь есть идеи, как я могу дальше отлаживать это? У меня очень мало опыта работы с сетями, я из клиентского инжиниринга, поэтому любая мелкая идея, вероятно, будет полезна.

Спасибо за ваше время!

РЕДАКТИРОВАТЬ: Еще немного информации в соответствии с @Steve:

$ sudo ufw status verbose
Status: inactive

-

$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 276K packets, 17M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DOCKER-USER  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 DOCKER-ISOLATION-STAGE-1  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      br-7d807f03cf39  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  *      br-7d807f03cf39  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  br-7d807f03cf39 !br-7d807f03cf39  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  br-7d807f03cf39 br-7d807f03cf39  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 273K packets, 116M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DOCKER-ISOLATION-STAGE-2  all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0           
    0     0 DOCKER-ISOLATION-STAGE-2  all  --  br-7d807f03cf39 !br-7d807f03cf39  0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      docker0  0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       all  --  *      br-7d807f03cf39  0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain DOCKER-USER (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0      
1
задан 12 May 2018 в 22:19

2 ответа

Да мм, даже при том, что я в основном спросил с этим точным вопросом и информацией, мой администратор сервера сказал мне, что это не была проблема брандмауэра. Но я возвратился им и сказал для проверки снова, и да, это было столь же просто как добавление исключения для порта 4984.

Я полагаю, что беспорядок состоял в том, когда администратор предположил, что я сделал что-то не так и прекратил слушать, когда я объяснил, что смог получить ответ от порта 80, но не 4984

T.T

1
ответ дан 7 December 2019 в 13:24

127.0.0.1:4985 средства только localhost могут получить доступ к нему, который является Вашим первым выпуском.

Для сетевого тестирования можно открыть простое соединение с nc команда:

nc -l -p 4984

Затем соединитесь с ним от удаленного соединения. Попробуйте различные порты. Вероятно проблема сетевого брандмауэра, если это 'в облаке'.

1
ответ дан 7 December 2019 в 13:24

Другие вопросы по тегам:

Похожие вопросы: