KVM 虚拟机网络调试的经历

这次网络问题的场景是，我通过 KVM 技术在一台 Linux 服务器上安装了一台虚拟机，但是从主机到虚拟机的网络不通，虽然通过内网穿透解决了问题，但是排查的过程依然非常有意义，遂记录下来。具体的调试过程基本上参考博客：单网口 ubuntu 主机配置 virt-manager 传统桥接 bridge 网络_enaftgm1i0-CSDN 博客中的步骤

关于 KVM 虚拟化技术，请看《Linux 虚拟化技术 - KVM》

简单的心得体会

网桥、交换机（就是多端口的网桥）工作在二层：链路层，以太网中处理以太头部，转发。如何转发呢，在接收到以太帧之后，检查二层头部里的目的 mac，随后查看本地的 mac 转发表（也可以叫二层转发表，layer 2 FIB，不同厂商名称不一样），找到匹配的 mac 地址条目对应的端口，不对二层头部作任何修改从端口转发出去。arp命令查看的就是链路层的转发

注意，通过arp -s添加了链路层的规则在服务器重启之后会消失

路由route工作在网络层，处理 IP 头部，查路由表，作三层转发。连接在路由器不同端口的设备属于不同的 IP 子网。route 方法查看的，就是路由的转发

一个网络包的传递主要就是看这两块：从域名解析 IP，包发到了网络接口，也就是网卡上，他应该往哪里转发，route 命令查看此网卡的路由规则（其实数据包在不同的网卡之前传递，底层也是用的 Mac 地址），经过路由等包到了目标服务器所在局域网，根据 Mac 地址，确定最终发送的目标服务器，arp命令查看映射。

这个博客教我们做的，实际上是通过arp设置和route路由设置，手动搭建了一个通信链路。

外部机器 a，本机 b，以及本机 b 下的虚拟机 b1

首先 a 在发送数据包到 b1 点时候，首先 a 中，b1 点 IP 对应的 Mac 地址必须是 b 的物理交换机的 Mac 地址，Mac 地址决定了一个数据包的下一站是谁。这样做到目的是让 a 发给 b 中的虚拟机的包，首先都发给 b，然后我们通过配置桥接，将的物理网卡桥接到一个虚拟网卡中，所有发送到 b 的物理网卡的包，都会通过桥接转发到虚拟网卡中，然后刚好，b 中所有的虚拟机都是以桥接方式连接着虚拟网卡的，因此，b 的物理网卡转发到虚拟网卡的包都会被虚拟机接受，然后在虚拟机内部，所有对外发送的 IP 的 Mac 地址，都是虚拟交换机，也就是通过虚拟交换机向外发送数据。虚拟交换机会转发到 b 的物理网卡

上面的配置保证了当 b 的网卡接受到消息的时候，能够通过网桥转发给虚拟机，那在 b 机器中，如何连接虚拟机呢，此时我们就只能通过搭建路由的方式，直接将对 b1 的访问转发到虚拟网卡，

内网穿透方案

现在的场景是，A、B 这两台物理机可以互通，在 B 中通过 KVM 虚拟化出虚拟机 B1，我们的设想是让 B1 以桥接方式与 B 连接，这样 ABC 都能互通，但是我们跟随单网口 ubuntu 主机配置 virt-manager 传统桥接 bridge 网络_enaftgm1i0-CSDN 博客的指引，解决不好这个问题，然后我们准备转变思路，让 B1 以（默认）NAT 方式与 B 连接，然后在 B 中通过 Nginx 进行 SSH 转发，实现 A 和 B1 互通。

步骤如下

在 B 中创建物理网卡的桥接，并设置一个新的 IP（我们可以通过这种方式为一个单网口的机器配置多个 IP），将来 A 就通过这个 IP 来连接 B1
修改 B 的 SSH 的配置文件/etc/ssh/sshd_config。修改ListenAddress为 B 的物理网卡的 IP，这样，B 中的 sshd 服务就只会监听物理网卡的IP:22，其他的 IP（比如桥接的 IP）不会被 sshd 处理，实际上最终会被 Nginx 转发到 B1
通过 KVM 技术创建虚拟机 B1，NAT 模式也是 B1 与 B 默认的网络连接模式，此时 B1 会分配到一个内网 IP，而且此时，B 与 B1 是互通的，而且 B1 到 A 是互通的，但 A 到 B1 不是互通的

安装 Nginx，并且配置 SSH 流量转发，所有访问网桥IP:22的流量都会被转发到 B1 的 22 端口，Nginx 配置文件如下，

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


http {
}
stream {
    upstream ssh {
        server <B1 的 IP>:22;
    }
    server {
        listen <网桥的 IP>:22;
        proxy_pass ssh;
        proxy_connect_timeout 1h;
        proxy_timeout 1h;
    }
}

A 现在可以通过网桥IP:22来 SSH 连接 B1 了

本质上，Ngin 的角色就是一个端口转发工具，实现了内网穿透，B 和 B1 可以看作是一个内网。

而且我发现 Nginx 作为端口转发工具实现内网穿透还挺普遍的，例如技术论坛里的这个帖子：今天整了个活，用纯 http post 做了一个反向代理/内网穿透的工具 - V2EX。这个帖子的作者通过 HTTP 协议实现了内网穿透，而且进行了开源：GitHub - codingmiao/hppt: 一款基于纯 HTTP 协议的内网穿透、反向代理工具，其核心也是用 Nginx 进行 SSH 流量转发。

虽然操作系统本身也可以做端口转发，但是用 Nginx 来实现却很普遍，可能是因为 Nginx 配置起来更简单。

还有一种场景，也适合用 Nginx 进行流量转发，即：服务器上开了防火墙，8080 端口开了，但是 22 端口没开，我们需要通过 SSH 远程连接这台服务器，此时我们同样可以用 Nginx 将 SSH 流量从 80 转发到 22 端口，然后用 80 端口 SSH 登录服务器。

拓展：

其他内网穿透工具：reGeorg 、reDuh、Tunna

其他基于HTTP实现的SSH工具：

GitHub - huashengdun/webssh: :seedling: Web based ssh client，Python编写的
GitHub - nirui/sshwifty: Web SSH & Telnet (WebSSH & WebTelnet client) 🔮，网站：sshwifty-demo，可直接在线使用
GitHub - Jrohy/webssh: 简易在线终端和sftp工具，使用简单
GitHub - NoCortY/WebSSH: 纯Java实现的WebSSH，可用于学习

基于HTTP进行SSH转发：

基于 HTTP 端口的 SSH 包转发 - 虾说全栈