答案 0 :(得分:2)
您可以检查网络ACL配置。 看起来您的PC和服务器之间还有一些其他防火墙阻止了您的9200。
答案 1 :(得分:1)
您可以查看此telnet-to a cloud instance from outside
问题的解决方案是"打开服务并制作telnet手册并右键单击它并选择start"
同时确保实例驻留在公共VPC中
答案 2 :(得分:1)
根据您所描述的内容,没有太多其他工作要做。您从实例远程登录公共IP的能力意味着服务器正在侦听外部接口,并且您的安全组已设置为对所有传入连接打开端口。
除了忽略实际上没有在列出的安全组下的实例之外,我现在能想到的唯一可能性是实例上的活动防火墙。在iptables
或ufw
(它是iptables的接口)的情况下,验证它们是否确实妨碍了它是微不足道的:
// List iptables access rules
sudo iptables -L -v
// List access rules via ufw
sudo ufw status
答案 3 :(得分:1)
如果你可以通过telnet访问端口80,或者你可以在其中使用SSH,那么你可能已经有了network ACL。如果你不能通过telnet访问端口80,但你可以通过浏览器,它就像一个本地配置 - 可能是AV或防火墙。
EC2实例使用安全组作为firewall
另一个缩小问题范围的测试是看你是否可以从同一个子网中同一个子网中的另一个实例远程登录。在同一子网中,您不应受网络ACL的影响。
答案 4 :(得分:0)
默认情况下,Amazon Linux AMI上未安装Telnet服务。
如果您想使用它,您需要自己安装,例如:Install and Setup Telnet on EC2 Amazon Linux or CentOS。
但是,现在建议使用ssh
代替telnet
,因为它更安全。请参阅:Telnet on wikipedia
答案 5 :(得分:0)
只是想一想,检查你电脑的防火墙。
答案 6 :(得分:0)
您说:“这是我的SG”,但是...哪种方式?入站还是出站? 可能只是您的主机无法回复您的PC。 尝试添加一条规则,该规则添加从端口32768到65535(临时端口)的出站 TCP,以便telnet服务器响应数据包可以传输回您的PC。
否则,就像其他人所说的那样,将目光放在VPC级别(网络ACL)上。
答案 7 :(得分:0)
您的接收器进程可能在127.0.0.1:9000
上运行,这意味着只有本地客户端可以连接。这与您的安全组无关,该安全组可能会完全打开。
在Unix上运行lsof -i:9000
。
如果您在NAME
下看到类似的内容,则用于启动接收器的主机IP需要从127.0.0.1更改为0.0.0.0(并通过SG / FW进行安全保护)。
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 2777 ubuntu 148u IPv6 26856 0t0 TCP localhost:afs3-callback (LISTEN)
答案 8 :(得分:-1)
需要确保通过IAM生成并在启动时附加到EC2的SSH密钥已添加到登录名:
ssh-add -K <yourkeyname>.pem
ssh ubuntu@<yourdns or ip>.com == or == ssh ec2-user@<yourdns or ip>