即使暴露了端口也无法访问。拒绝连接 [英] Port not accessible even after being exposed. Connection refused

查看:222
本文介绍了即使暴露了端口也无法访问。拒绝连接的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们创建了一个像这样的docker容器:

we created a docker container like this:

docker container create \
    --name orderer \
    --network dscsa_net \
    --workdir $WORK_DIR \
    --expose=7050 \
    hyperledger/fabric-orderer:1.3.0 ./start-orderer.sh

但无法连接到容器上的端口7050。

but are unable to connect to port 7050 on the container.

root@dcee7e74266f:/home# nc -vz 10.0.0.194 7050
nc: connect to 10.0.0.194 port 7050 (tcp) failed: Connection refused

我们能够ping通容器:

we are able to ping the container:

root@dcee7e74266f:/home# ping 10.0.0.194
PING 10.0.0.194 (10.0.0.194) 56(84) bytes of data.
64 bytes from 10.0.0.194: icmp_seq=1 ttl=64 time=0.810 ms
64 bytes from 10.0.0.194: icmp_seq=2 ttl=64 time=1.30 ms
64 bytes from 10.0.0.194: icmp_seq=3 ttl=64 time=0.668 ms
64 bytes from 10.0.0.194: icmp_seq=4 ttl=64 time=1.10 ms
64 bytes from 10.0.0.194: icmp_seq=5 ttl=64 time=0.631 ms
^C
--- 10.0.0.194 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 0.631/0.902/1.301/0.261 ms

,还可以看到正在侦听的进程在容器上的端口7050上:

and also see a process listening on port 7050 on the container:

root@9756199efefa:/home# netstat -tuplen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 127.0.0.1:7050          0.0.0.0:*               LISTEN      0          10097930    7/orderer       
tcp        0      0 127.0.0.11:34865        0.0.0.0:*               LISTEN      0          10097705    -               
udp        0      0 127.0.0.11:51385        0.0.0.0:*                           0          10097704    -  

这是怎么回事?我们该如何解决呢?

what is going on here? how can we fix this?

编辑:我们在覆盖网络上。答案中建议的发布标志为n / a,因为我们正在进行容器到容器的通信。

we are on a overlay network. The publish flag suggested in the answer is n/a as we are doing container to container communication. Anyway we tried it and it doesn't work.

我们注意到一件事,那就是如果我们运行:

There is one thing we have noticed which is if we run:

docker network inspect <our-network-name> 

在其他情况下,它会打印出容器部分,但在该部分中仅列出执行 docker网络检查的主机上的容器。其他节点上托管的容器未列出(在此处)。

Among other things, it prints out a containers section but in that section only the containers on the host from which docker network inspect is executed are listed. The containers hosted on other nodes are not listed (also mentioned here).

我们验证了是否运行:

docker node ls

所有节点都是集群的一部分。

all the nodes are part of the swarm.

似乎其他人也遇到了这个问题,例如,这里,但是什么是解决方案?

It seems other people have also run into this issue e.g., here but what is the solution?

注意:我们能够连接到另一个在端口7054上运行不同服务的容器。使用 expose 标志。

Note: we are able to connect to another container running a different service exposed on port 7054. This container was created without even using the expose flag.

root@dcee7e74266f:/home# nc -zv 10.0.0.164 7054
Connection to 10.0.0.164 7054 port [tcp/*] succeeded!

使用tcpdump进行进一步调试时,tcpdump的输出与有人尝试连接到a时的输出相同没有进程正在监听的端口。但是如前所示,netstat显示了一个正在侦听的进程,我们可以从本地主机连接到该进程。

Did further debugging with tcpdump and output of tcpdump is identical to the output when someone tries to connect to a port on which no process is listening. But as shown earlier netstat shows a process that is listening and we can connect to the process from localhost.

tcpdump的输出:

Output of tcpdump:

root@dcee7e74266f:/test# tcpdump -s0 host 10.0.0.195 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:44:45.978583 IP dcee7e74266f.52148 > orderer.dscsa_net.7050: Flags [S], seq 3845506108, win 28200, options [mss 1410,sackOK,TS val 4203049443 ecr 0,nop,wscale 7], length 0
23:44:45.979324 IP orderer.dscsa_net.7050 > dcee7e74266f.52148: Flags [R.], seq 0, ack 3845506109, win 0, length 0

R标志告诉客户端重置连接。

The R flag tells client to reset the connection.

traceroute的输出:

Output of traceroute:

root@dcee7e74266f:/test# traceroute 10.0.0.195     
traceroute to 10.0.0.195 (10.0.0.195), 30 hops max, 60 byte packets
 1  orderer.dscsa_net (10.0.0.195)  1.008 ms  0.900 ms  0.872 ms


推荐答案

通过< a href = https://askubuntu.com/a/166106/393311> 1 。服务器监听 127.0.0.1 是问题所在。一旦我们将侦听地址更改为 0.0.0.0 (在 netstat中显示为 ::: 下面的输出),我们能够连接到服务器:

Solved this issue thanks to 1. The server listening to 127.0.0.1 was the problem. Once we changed the listening address to 0.0.0.0 (shows as ::: in netstat output below), we are able to connect to the server:

root@e9766a94d102:/home# netstat -tuplen          
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 127.0.0.11:37641        0.0.0.0:*               LISTEN      0          12821468    -               
tcp6       0      0 :::7050                 :::*                    LISTEN      0          12821696    7/orderer       
udp        0      0 127.0.0.11:51855        0.0.0.0:*                           0          12821467    -       

不需要暴露发布标志。自我提醒:浪费了1.5天。

there is no need for either expose or publish flags. note to self: wasted 1.5 days on this.

这篇关于即使暴露了端口也无法访问。拒绝连接的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆