我在通过我的公共 IPv4 地址访问我的 SSH 服务器时遇到了问题,但在我的本地网络中一切正常。
该连接将按本地预期工作:
[alex@deathstar ~]$ ssh 192.168.178.86 -p 1338
Last login: Wed Jan 8 12:30:51 2020 from 192.168.178.85
[alex@bielefeld ~]$
但公开而言却致命地失败了:
[alex@deathstar ~]$ ping 62.XXX.XXX.XXX
PING 62.XXX.XXX.XXX (62.XXX.XXX.XXX) 56(84) bytes of data.
64 bytes from 62.XXX.XXX.XXX: icmp_seq=1 ttl=63 time=13.3 ms
(...)
[alex@deathstar ~]$ ssh 62.XXX.XXX.XXX -p 1338
ssh: connect to host 62.XXX.XXX.XXX port 1338: Connection timed out
我将做一个简短的总结:
- 我的服务器正在使用 Arch Linux(2020.01.01)
- 服务器的防火墙已禁用
- 我已经转发了路由器上的端口(Fritz!Box 7590 版本 07.12)
- 我的本地网络内一切正常
- 对公共 IPv4 地址进行 Ping 操作有效
我做的这些检查也可能有用:
防火墙设置:
我在用着简单的防火墙。
[root@bielefeld /]# ufw status
Status: active
To Action From
-- ------ ----
1338/tcp ALLOW Anywhere
1338/tcp (v6) ALLOW Anywhere (v6)
网络连接(服务器):
您还可以看到我的另一台计算机通过本地网络连接。
[root@bielefeld /]# netstat -tupan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:1338 0.0.0.0:* LISTEN 4068/sshd
tcp 0 0 192.168.178.86:1338 192.168.178.85:53868 ESTABLISHED 3326/sshd: alex
本地端口扫描(从服务器):
[root@bielefeld /]# nmap -p 1338 localhost
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-08 13:10 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000043s latency).
Other addresses for localhost (not scanned): ::1
PORT STATE SERVICE
1338/tcp open SSH
Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds
服务器上的端口扫描(来自客户端)
[alex@deathstar ~]$ nmap -p 1338 62.XXX.XXX.XXX
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-08 13:26 CET
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds
SSH 守护进程配置(/etc/ssh/sshd_config)
Port 1338
ListenAddress 0.0.0.0
PermitRootLogin no
MaxAuthTries 3
MaxSessions 6
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords yes
UsePAM yes
AllowAgentForwarding yes
AllowTcpForwarding yes
GatewayPorts yes
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
PermitTTY yes
PrintMotd no # pam does that
AllowUsers alex
提前谢谢你!我已经绝望到这个地步了。
答案1
要建立从互联网到家庭路由器后面的服务器的 SSH 连接,必须正确配置路由和 nat。假设您的客户端可以通过 SSH 成功连接到具有公共 IP 的其他服务器:
- 运营商级 NAT:您的 ISP 必须将传入数据包路由到您的路由器。验证您的 ISP 是否为路由器的 WAN 接口分配了正确的 IP(62.xyz)。一些 ISP 会为客户的路由器分配一个私有 IP 地址,并使用中央广播电视总台以便多个客户通过同一个公共 IP 地址进行路由。
您可以在 FritzBox Web 界面的“在线”或“Internet”页面上检查此信息。如果 WAN 接口上未分配公共 IP,或者配置了另一个公共 IP,则您的 ISP 可能不会将端口 (1338) 转发到您的路由器,或者您的路由器配置错误。某些 ISP 会为客户分配多个 IP。
- 路由器 NAT + 防火墙:您的家用路由器必须正确处理端口转发 (DNAT),并且不得阻止通过防火墙的流量。DNAT 规则应将发往您公共 IP (62.xyz) 端口 1338 的任何地方的 TCP 数据包转发到您家用服务器 (192.168.178.86) 端口 1338 的 TCP 数据包。此外,防火墙不得阻止流量。几乎所有消费者家用路由器都会为转发端口创建隐式防火墙规则,包括 FritzBox。路由器还必须伪装从 LAN 到 WAN 的流量,同样,几乎所有家用路由器都无需额外配置即可做到这一点。
确保在端口转发规则中设置了正确的协议 (TCP),并使用协议的默认端口设置了实际的数字端口,而不是协议名称 (SSH)。还要验证 DNAT 目标是否是正确的目标 LAN IP (192.168.178.86),因为如果手动更改了服务器的 IP,路由器可能会使用指向错误 IP 的缓存 DHCP 租约。目标 IP 必须与路由器位于同一子网,可在 FritzBoxes 的高级网络设置中找到。确保没有规则阻止出站(回复)TCP 流量。
- 服务器防火墙/NAT:一旦传入的 TCP 数据包被路由到服务器,它就不能被任何本地防火墙丢弃或通过 NAT 转发到其他地方以便在本地传送。
iptables -L -v -n
检查中的 INPUT 和 OUTPUT 链以及 中的 NAT 的默认策略iptables -L -v -n -t nat
。
- 服务器路由:由于路由器应用了目标 NAT,因此原始发送方 IP 在 TCP 标头中保持不变。因此,服务器将向原始发送方 IP 发送回复。必须在服务器上配置有效的默认路由(网关),以便通过转发传入 TCP 数据包的同一路由器发送回复,否则原始发送方可能会丢弃服务器的回复,因为它来自与原始目标 IP 不同的 IP。
检查服务器上配置的路由ip route
,确保存在有效的默认路由,并且没有使用多个网络接口的模糊路由(ip rule
)。默认网关必须位于服务器的子网内,显示为ip addr
。
- IPv4/IPv6:确保以上所有条件都适用于 IPv4 和 IPv6,或者禁用其中之一进行测试。一些 ISP 可能只提供公共 IPv6 子网,而公共 IPv4 地址由许多客户共享(“DS-Lite”),因此 IPv6 可能是成功访问服务器的唯一方式。
路由器可能更喜欢其中一个,因此传入的 IPv4 可能会通过 IPv6 在内部发送,反之亦然。您可能需要删除服务器的现有 DHCP 租约,以删除首选但已失效的 DNAT 规则。
最后,不要测试与路由器 WAN IP 的连接,因为路由器很可能未配置发夹形。