我的计算机 B 位于两个网络上 - 10.132.2.* 和 10.132.1.* 10.132.1.* 网络是有线网络;10.132.2.* 网络是无线网络。我在每个网络上都打开了一个 ssh 端口,但无线网络上出现了一些奇怪的情况。ssh 端口已打开,我可以从 10.132.2.* 网络上的其他设备连接到它 - 除了从无线网络上的 WAN 转发的连接。
- 如果我连接 10.132.1.10 上的电缆,计算机 B 将停止响应来自 10.132.2.20 上的 EA6350 的 SSH 请求。如果我断开 10.132.1.10 上的电缆,计算机 B 将响应来自 EA6350 的 SSH 请求。
- 无论哪种情况,计算机 B 都会响应来自计算机 A 的 SSH 请求。
如果我使用 nc 在计算机 B 上设置一个简单的侦听器(因此将 SSH 排除在外)并尝试从互联网上对其进行 telnet,同样,我可以通过使用 tcpdump 看到数据包通过,但是 nc 侦听器实际上什么也不做。
底线是,系统中的某些东西不允许连接通过。
我想知道问题是否与“https://askubuntu.com/questions/166068/port-seems-to-be-open-but-connection-refused”有关。查看这里的一个回复:“您还需要确保“mydomain.com”解析为您的机器的正确 IP 地址,这样连接到它将导致与该机器的外部接口进行通信。”
我真的不知道这在我的上下文中意味着什么。我不明白这是否意味着我需要计算机 B (10.132.2.20) 的 IP 地址?我尝试在 /etc/hosts 中添加一个条目,但似乎没有帮助。这是否意味着我需要一个用于我的域的条目?在我的 LAN 上,我应该为整个域提供什么 IP 地址?
来自“ip route”的输出(我承认,我并不完全理解):
default via 10.132.1.1 dev eno1 proto dhcp metric 100
default via 10.132.2.1 dev wlp1s0 proto dhcp metric 600
10.132.1.0/24 dev eno1 proto kernel scope link src 10.132.1.10 metric 100
10.132.2.0/24 dev wlp1s0 proto kernel scope link src 10.132.2.20 metric 600
169.254.0.0/16 dev wlp1s0 scope link metric 1000
以下是“iptables -L”的输出
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
以下是“ufw status”的输出:
Status: inactive
这是“egrep -v -e ^# -e ^$ /etc/ssh/sshd_config”的输出,但我不认为问题出在 SSH 上,因为 NC 显示了类似的行为(参见上面的评论)。
Port 20
Port 22
Port 80
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
答案1
总结:删除到 10.132.1.1 的默认路由,10.132.2.x 上的传入连接将成功返回到 10.132.2.x 网络。请注意,这依赖于我不使用 10.132.1.1 进行传入连接这一事实。
长版本:
在各种论坛上发布此问题后,有人建议我的配置是所谓的“双主网络”,并且我没有正确设置以支持两个网络。对此进行一些研究后,我找到了“ip route”中的这些条目:
default via 10.132.1.1 dev eno1 proto dhcp metric 100
default via 10.132.2.1 dev wlp1s0 proto dhcp metric 600
这说明该机器目前设置了两个默认路由。在计算机 B 的 10.132.1.10 端放置一个 tcpdump,然后尝试通过 ssh 登录到 10.132.2.20,结果显示计算机 B 尝试在 10.132.1.x 网络上发送 IP 地址为 10.132.2.20 的响应——失败了。
奇怪的是,在此之前,我从未发现此设置存在任何问题。对于我的系统来说,简单的解决方案就是删除 10.132.1.1 上的默认路由。因为路由表还包括以下内容:
10.132.1.0/24 dev eno1 proto kernel scope link src 10.132.1.10 metric 100
与本地设备的任何连接继续工作。