![RRAS NAT 未转发特定 Hyper-V VM](https://linux22.com/image/680454/RRAS%20NAT%20%E6%9C%AA%E8%BD%AC%E5%8F%91%E7%89%B9%E5%AE%9A%20Hyper-V%20VM.png)
我有 Windows Server 2012 R2 安装,其中有 Hyper-V、RRAS 和 NAT 设置。
我的两个 VM 和 RRAS NAT 出现问题:
本质上,这两个虚拟机不会在本地子网外通信。它们可以与本地网络内的所有东西(其他虚拟机、网关)通信,但无法与本地网络外的任何东西通信。这两个虚拟机与其他虚拟机之间的唯一区别在于它们是基于 Linux 的系统。所有其他虚拟机都是基于 Windows Server 2012 R2 的系统。
Linux 中是否有特定因素会导致此问题?一个是 CentOS 安装,另一个是 Debian 安装。
如果我为任一 Linux 设备分配一个面向公众的接口,那么它们就有外部连接。显然我不想这样做,因为这会浪费我的 IP 寻址空间。
请注意:服务器可以顺利 ping 默认网关 (10.0.0.1)。时间通常约为 0.450ms。
现在,我只想解决 debian 安装的问题,因此这里有一些来自其中的数据:
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:15:5d:91:82:07
inet addr:10.0.4.0 Bcast:10.0.255.255 Mask:255.255.0.0
inet6 addr: fe80::215:5dff:fe91:8207/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1842 errors:0 dropped:0 overruns:0 frame:0
TX packets:7245 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:119697 (116.7 KiB) TX bytes:701216 (684.7KiB)
(不包括环回)
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
localness * 255.255.0.0 U 0 0 0 eth0
# ip route
default via 10.0.0.1 dev eth0
10.0.0.0/16 dev eth0 proto kernel scope link src 10.0.4.0
该/etc/network/interfaces
文件内容如下:
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet static
address 10.0.4.0
netmask 255.255.0.0
network 10.0.0.0
broadcast 10.0.255.255
gateway 10.0.0.1
更多信息:
# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
# iptables -L
Chain INPUT (policy ACCEPT)
target port opt source destination
Chain INPUT (policy ACCEPT)
target port opt source destination
Chain OUTPUT (policy ACCEPT)
target port opt source destination
网络基本设置如下:Hyper-V Windows Server 有一个网络端口,可插入互联网。然后,主机安装 RRAS 和 NAT,并使用我的整个公共 IP 空间为 VM 转换 NAT。每个 VM/24
从该范围内获得不同的 IP 地址块10.0.0.0/16
,但它们保留/16
子网掩码。例如,Debian VM 是10.0.4.0 - 10.0.4.255
。
答案1
因此,事实证明该问题是由于校验和卸载造成的。
由于某种原因,当激活 IPv4 校验和卸载时,Linux 客户机无法通过 NAT 工作。(它们在没有 NAT 的情况下也能正常工作,这很奇怪。)
因此,在物理和虚拟接口上禁用 IPv4 校验和卸载并重新启动服务器后,一切都按预期工作。