无法通过 SSH 连接到虚拟机中 FreeNAS 中安装在 iohyve 中的 RancherOS
Can't SSH into RancherOS which is installed in iohyve in FreeNAS within a virtual machine
我正在准备服务器升级，但在这样做之前，我想先在 VM 中进行 dry-运行。
我正在 运行宁 Linux 在笔记本电脑上使用 Mint。目前，我在 QEMU 中安装了 FreeNAS v9.10.2-U6，并通过 iohyve 在虚拟机中安装了 RancherOS v1.5.6。
[laptop]
|_ [QEMU]
|_ [FreeNAS]
|_ [iohyve]
|_ [RancherOS]
我可以毫无问题地通过 SSH 连接到 FreeNAS，但无法通过 SSH 连接到 Rancher。当尝试连接到 Rancher 时，它最终会超时。当我 运行 带有 -vvv 的 ssh 命令时，它似乎在最终超时之前挂在 debug1: Connecting to <RANCHER_IP> [<RANCHER_IP>] port 22. 上。
这是我目前尝试过的方法：
- 已验证可以通过
ping <RANCHER_IP> 从主机访问 Rancher VM
- 已验证 sshd 运行在 Rancher VM 中
ps -ef | grep sshd
- 已验证 Rancher VM 正在侦听 SSH 端口
netstat -nl | grep :22
- 检查了我在主机和来宾上的
iptables 规则，似乎没有阻止通信的规则。
这是我第一次处理嵌套 VM 中的网络，因此我不确定是否遗漏了一些简单的东西。我期待社区可能有的任何见解。
TL;DR，我不得不在 FreeNAS VM 中禁用硬件卸载。为了持久修复，在 FreeNas 的 GUI 中，我转到 Init/Shutdown Scripts 并创建了一个 Post-Init Command 脚本 运行
ifconfig vtnet0 -rxcsum -txcsum -rxcsum6 -txcsum6 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso -tso -tso4 -tso6 -lro -vlanhwtso -vlanhwcsum
完整的故障排除步骤：
- 验证主机、FreeNAS 和 运行cher 的 MTU 都是相同的 (1500)
- 主持人：
ifconfig | grep mtu
- FreeNAS：
ifconfig | grep mtu
- 运行雪儿：
ifconfig | grep MTU
- 已验证 运行cher 具有外部访问权限：
ping google.com
- 验证主机、FreeNAS 和 运行cher 可以通信
- FreeNAS 主机：
ping <FREENAS_IP>
- 主持人 运行cher：
ping <RANCHER_IP>
- FreeNAS 到主机：
ping <HOST_IP>
- FreeNAS 到 运行cher：
ping <RANCHER_IP>
- 运行感谢主持人：
ping <HOST_IP>
- 运行感谢 FreeNAS：
ping <FREENAS_IP>
- 已验证
sshd 在 运行cher 虚拟机中是 运行：ps -ef | grep sshd
- 还尝试重新启动
sshd：sudo system-docker restart console 以防出现某种竞争条件。
- 已验证 运行cher 虚拟机正在侦听 SSH 端口：
netstat -nl | grep :22。
- 已验证路由表，并且有一个默认网关
- 主持人：
route
- FreeNAS：
netstat -r
- 运行雪儿：
route
- 尝试为 运行cher 添加专用 SSH 端口和侦听 IP，并通过
netstat 验证仅侦听该 IP 和端口。这是为了排除任何可能的端口冲突。
- 检查主机和 运行cher 上的
iptables 规则（FreeNAS 没有防火墙），没有任何规则阻止通信。
- 关闭防火墙规则，然后重新启动 运行cher 的 sshd (nadda)，然后重新启动 FreeNAS VM (nadda)。
- FreeNAS 中有一个防火墙工具，但确认没有设置任何内容：
ipfw table all list。
- 在 FreeNAS 中，我检查了网络流量以查看我的 SSH 请求是否到达那里。对于每种情况，我都打开了 2 个终端，一个连接到 FreeNAS，另一个连接到 运行cher。由于 Live 环境中的输出太长（因为 SSH 连接已完成），我只为每种情况添加一个记录项目，因为相关信息在第一个日志中。
- 直播中：
sudo tcpdump -nnvvS '(src <HOST_IP> and dst <RANCHER_IP>) or (src <RANCHER_IP> and dst <HOST_IP>)'。
tcpdump: listening on ix0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:01:53.957264 IP (tos 0x0, ttl 64, id 56881, offset 0, flags [DF], proto TCP (6), length 60)
<HOST_IP>.60648 > <RANCHER_IP>.22: Flags [S], cksum 0xfae8 (correct), seq 468317589, win 64240, options [mss 1460,sackOK,TS val 2321761697 ecr 0,nop,wscale 7], length 0
- 在虚拟机上：
sudo tcpdump -nnvvS '(src <HOST_IP> and dst <RANCHER_IP>) or (src <RANCHER_IP> and dst <HOST_IP>)'
tcpdump: listening on vtnet0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:59:03.029922 IP (tos 0x0, ttl 64, id 25421, offset 0, flags [DF], proto TCP (6), length 60)
<HOST_IP>.45688 > <RANCHER_IP>.22: Flags [S], cksum 0x8403 (incorrect -> 0x69a6), seq 3645881181, win 64240, options [mss 1460,sackOK,TS val 1007017042 ecr 0,nop,wscale 7], length 0
- 注意到
cksum 有很多 incorrect，所以我 运行 在主机 ethtool --show-offload <ETHERNET_INTERFACE_NAME> | grep tx-checksumming 上使用它，它告诉我它已打开。 运行 sudo ethtool -K <ETHERNET_INTERFACE_NAME> tx off 禁用它，re-ran tcpdump 和 ssh 命令，对于 cksum 仍然有 incorrect，所以我重新启用了校验和 sudo ethtool -K <ETHERNET_INTERFACE_NAME> tx on.至少我认为最后一个命令重置了东西，在 FreeNAS 重启后网络不再可用。我最终 运行 sudo ethtool --reset <ETHERNET_INTERFACE_NAME> all，并最终从头开始重新创建 VM 并重新启动我的系统以重置一切。
- 在 Google 搜索
iohyve tap0 or epair 之后终于找到了 the solution in this post。引用相关信息以防 post 在某个时候消失。
I ran into a very similar situation recently. I could ping the jails to & from bhyve guests but I could not pass any actual traffic. From other physical devices I had no issue passing traffic. The problem ended up being the hardware offloaders (TSO, HWSUM, etc) were causing the issue, which I found kind of ironic considering the traffic was not making it to the hardware in my case. I used tcpdump and could see the traffic had checksum errors. I turn off the hardware offloaders and everything started working, took me two weeks to figure this out. In hindsight I should of ran tcpdump on the first day.
Try turning off the hardware offloading, then rerun ifconfig -v if it took effect, then test to see if you can pass actual traffic.
Disable hardware offloading:
ifconfig igb0 -rxcsum -txcsum -rxcsum6 -txcsum6 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso -tso -tso4 -tso6 -lro -vlanhwtso -vlanhwcsum
- 因此对于我的用例，我通过 SSH 进入 FreeNAS，确保 运行cher VM 已停止，禁用 off-loading（将
igb0 替换为 vtnet0 ), 启动 运行cher VM 备份，最后尝试通过 SSH 进入 运行cher... 并成功。基本上我之前禁用卸载的尝试是正确的，但我需要在 FreeNAS 中进行，而不是主机...考虑到它是一个桥接网络，这对我来说有点违反直觉，我正在将我的确切硬件资源传递给虚拟机。
我正在准备服务器升级，但在这样做之前，我想先在 VM 中进行 dry-运行。
我正在 运行宁 Linux 在笔记本电脑上使用 Mint。目前，我在 QEMU 中安装了 FreeNAS v9.10.2-U6，并通过 iohyve 在虚拟机中安装了 RancherOS v1.5.6。
[laptop]
|_ [QEMU]
|_ [FreeNAS]
|_ [iohyve]
|_ [RancherOS]
我可以毫无问题地通过 SSH 连接到 FreeNAS，但无法通过 SSH 连接到 Rancher。当尝试连接到 Rancher 时，它最终会超时。当我 运行 带有 -vvv 的 ssh 命令时，它似乎在最终超时之前挂在 debug1: Connecting to <RANCHER_IP> [<RANCHER_IP>] port 22. 上。
这是我目前尝试过的方法：
- 已验证可以通过
ping <RANCHER_IP> 从主机访问 Rancher VM
- 已验证 sshd 运行在 Rancher VM 中
ps -ef | grep sshd - 已验证 Rancher VM 正在侦听 SSH 端口
netstat -nl | grep :22 - 检查了我在主机和来宾上的
iptables规则，似乎没有阻止通信的规则。
这是我第一次处理嵌套 VM 中的网络，因此我不确定是否遗漏了一些简单的东西。我期待社区可能有的任何见解。
TL;DR，我不得不在 FreeNAS VM 中禁用硬件卸载。为了持久修复，在 FreeNas 的 GUI 中，我转到 Init/Shutdown Scripts 并创建了一个 Post-Init Command 脚本 运行
ifconfig vtnet0 -rxcsum -txcsum -rxcsum6 -txcsum6 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso -tso -tso4 -tso6 -lro -vlanhwtso -vlanhwcsum
完整的故障排除步骤：
- 验证主机、FreeNAS 和 运行cher 的 MTU 都是相同的 (1500)
- 主持人：
ifconfig | grep mtu - FreeNAS：
ifconfig | grep mtu - 运行雪儿：
ifconfig | grep MTU
- 主持人：
- 已验证 运行cher 具有外部访问权限：
ping google.com - 验证主机、FreeNAS 和 运行cher 可以通信
- FreeNAS 主机：
ping <FREENAS_IP> - 主持人 运行cher：
ping <RANCHER_IP> - FreeNAS 到主机：
ping <HOST_IP> - FreeNAS 到 运行cher：
ping <RANCHER_IP> - 运行感谢主持人：
ping <HOST_IP> - 运行感谢 FreeNAS：
ping <FREENAS_IP>
- FreeNAS 主机：
- 已验证
sshd在 运行cher 虚拟机中是 运行：ps -ef | grep sshd- 还尝试重新启动
sshd：sudo system-docker restart console以防出现某种竞争条件。
- 还尝试重新启动
- 已验证 运行cher 虚拟机正在侦听 SSH 端口：
netstat -nl | grep :22。 - 已验证路由表，并且有一个默认网关
- 主持人：
route - FreeNAS：
netstat -r - 运行雪儿：
route
- 主持人：
- 尝试为 运行cher 添加专用 SSH 端口和侦听 IP，并通过
netstat验证仅侦听该 IP 和端口。这是为了排除任何可能的端口冲突。 - 检查主机和 运行cher 上的
iptables规则（FreeNAS 没有防火墙），没有任何规则阻止通信。- 关闭防火墙规则，然后重新启动 运行cher 的 sshd (nadda)，然后重新启动 FreeNAS VM (nadda)。
- FreeNAS 中有一个防火墙工具，但确认没有设置任何内容：
ipfw table all list。
- 在 FreeNAS 中，我检查了网络流量以查看我的 SSH 请求是否到达那里。对于每种情况，我都打开了 2 个终端，一个连接到 FreeNAS，另一个连接到 运行cher。由于 Live 环境中的输出太长（因为 SSH 连接已完成），我只为每种情况添加一个记录项目，因为相关信息在第一个日志中。
- 直播中：
sudo tcpdump -nnvvS '(src <HOST_IP> and dst <RANCHER_IP>) or (src <RANCHER_IP> and dst <HOST_IP>)'。tcpdump: listening on ix0, link-type EN10MB (Ethernet), capture size 65535 bytes 15:01:53.957264 IP (tos 0x0, ttl 64, id 56881, offset 0, flags [DF], proto TCP (6), length 60) <HOST_IP>.60648 > <RANCHER_IP>.22: Flags [S], cksum 0xfae8 (correct), seq 468317589, win 64240, options [mss 1460,sackOK,TS val 2321761697 ecr 0,nop,wscale 7], length 0 - 在虚拟机上：
sudo tcpdump -nnvvS '(src <HOST_IP> and dst <RANCHER_IP>) or (src <RANCHER_IP> and dst <HOST_IP>)'tcpdump: listening on vtnet0, link-type EN10MB (Ethernet), capture size 65535 bytes 14:59:03.029922 IP (tos 0x0, ttl 64, id 25421, offset 0, flags [DF], proto TCP (6), length 60) <HOST_IP>.45688 > <RANCHER_IP>.22: Flags [S], cksum 0x8403 (incorrect -> 0x69a6), seq 3645881181, win 64240, options [mss 1460,sackOK,TS val 1007017042 ecr 0,nop,wscale 7], length 0 - 注意到
cksum有很多incorrect，所以我 运行 在主机ethtool --show-offload <ETHERNET_INTERFACE_NAME> | grep tx-checksumming上使用它，它告诉我它已打开。 运行sudo ethtool -K <ETHERNET_INTERFACE_NAME> tx off禁用它，re-rantcpdump和 ssh 命令，对于cksum仍然有incorrect，所以我重新启用了校验和sudo ethtool -K <ETHERNET_INTERFACE_NAME> tx on.至少我认为最后一个命令重置了东西，在 FreeNAS 重启后网络不再可用。我最终 运行sudo ethtool --reset <ETHERNET_INTERFACE_NAME> all，并最终从头开始重新创建 VM 并重新启动我的系统以重置一切。
- 直播中：
- 在 Google 搜索
iohyve tap0 or epair之后终于找到了 the solution in this post。引用相关信息以防 post 在某个时候消失。I ran into a very similar situation recently. I could ping the jails to & from bhyve guests but I could not pass any actual traffic. From other physical devices I had no issue passing traffic. The problem ended up being the hardware offloaders (TSO, HWSUM, etc) were causing the issue, which I found kind of ironic considering the traffic was not making it to the hardware in my case. I used
tcpdumpand could see the traffic had checksum errors. I turn off the hardware offloaders and everything started working, took me two weeks to figure this out. In hindsight I should of rantcpdumpon the first day.Try turning off the hardware offloading, then rerun
ifconfig -vif it took effect, then test to see if you can pass actual traffic.Disable hardware offloading:
ifconfig igb0 -rxcsum -txcsum -rxcsum6 -txcsum6 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso -tso -tso4 -tso6 -lro -vlanhwtso -vlanhwcsum- 因此对于我的用例，我通过 SSH 进入 FreeNAS，确保 运行cher VM 已停止，禁用 off-loading（将
igb0替换为vtnet0), 启动 运行cher VM 备份，最后尝试通过 SSH 进入 运行cher... 并成功。基本上我之前禁用卸载的尝试是正确的，但我需要在 FreeNAS 中进行，而不是主机...考虑到它是一个桥接网络，这对我来说有点违反直觉，我正在将我的确切硬件资源传递给虚拟机。
- 因此对于我的用例，我通过 SSH 进入 FreeNAS，确保 运行cher VM 已停止，禁用 off-loading（将