QEMU中虚拟Linux网络配置
baidu: 只有在ping的时候才想起我，对吗
初
刚才使用qemu测试驱动的时候，忽然发现ssh不能顺利的接入到虚拟操作系统之中，原以为是物理机资源紧张导致qemu启动变慢，结果摸鱼半天之后依然无法通过ssh访问。使用vnc接入后发现虚拟机无法上网，没有被分配IP地址。
不知道是哪里出了bug，正常来讲不应该出现问题，之前的博文（Link: https://www.cnblogs.com/polariszg/p/18242190）中提到的qemu-ifup脚本应该会自动创建DHCP服务器，并对该虚拟机分配特定的ip地址。
好在手动配置好ip地址后，可以接通网络并使用ssh连接。
操作系统信息
QEMU中虚拟操作系统的信息如下
- 版本号：
yukikaze@yukikaze-qemu:/etc/systemd$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy
- 网络设备：
在裸机上可能会因为net-tools没有安装所以会麻烦一些，需要访问对应的网络设备，来拿到网络设备的信息，网络设备位于 /sys/class/net/ 路径下，比如在本虚拟Linux中，网络设备仅有ens3
yukikaze@yukikaze-qemu:/sys/class/net/ens3$ ls
addr_assign_type carrier_down_count duplex link_mode phys_port_id speed type
address carrier_up_count flags mtu phys_port_name statistics uevent
addr_len device gro_flush_timeout name_assign_type phys_switch_id subsystem
broadcast dev_id ifalias napi_defer_hard_irqs power testing
carrier dev_port ifindex netdev_group proto_down threaded
carrier_changes dormant iflink operstate queues tx_queue_len
查看设备的mac地址
yukikaze@yukikaze-qemu:/sys/class/net/ens3$ cat address
52:54:00:12:34:56
在物理机中，可以通过抓包查看该设备是否上线，抓包工具就有很多了，wireshark之类的
手动配置ip地址
这里我们就要复习一下计算机网络的知识。本节中会涉及到L3层的如下信息：
-
ip地址：屏蔽到32bit的mac地址的32bit长或128bit长的一个地址，一般来说我们使用简单的ipv4来进行配置。只有拥有了ip地址，更高层的协议（L4及以上）才能够工作
-
子网掩码：每个ip地址分为两个部分，网络号和子网编号，ip地址通过和子网掩码进行
与运算来得到自己所属的子网 -
网关及默认网关：同一个子网中的设备是可以互相通信的，这种通信会直接发送至L2层进行封包转发。但若不属于同一子网，则会将网络包发给网关进行处理。网关承载着子网内和子往外的交互功能
在《wireshark网络分析就是这么简单》这杯书的第一张就提到一道经典的问题，当一台计算机的子网掩码被随机更改后，该计算机还能够自由的连接互联网吗？
-
DNS地址：实际上DNS协议应该就不是在L3层，而是在L4层进行工作。配置好上述参数后，ping命令可以通过写ip地址参数来返回成功，但计算机实际并不能自由的连接互联网。还需要配置DNS解析参数，来保证可以将字符串正确解析为ip地址，来进行L3层的通信。
-
前置参数
你好这是我的千织老婆
该前置参数来自qemu-ifup脚本对物理机的配置。该脚本会在物理机上建立一个网桥，并将qemu虚拟机连接到该网桥上：
-
网桥ip地址：192.168.53.1
-
网桥的子网掩码：255.255.255.0
-
-
配置虚拟机ip地址
本机使用的网络设备名称是ens3，需要根据实际的场景来更改下述命令的参数
sudo ip addr add 192.168.53.77/24 dev ens3 -
配置默认网关
sudo ip route add default via 192.168.53.1 -
测试
此时应该可以通过
ping 192.168.53.1来测试网络的连通性，当然也可以通过ping 8.8.8.8来测试互联网的连通性 -
持久化
这个我没有测试，这里就略过，不过可以通过systemd来自动化启动一个脚本
配置DNS解析地址
上述的配置完成后，明明已经接入的互联网高速路，但使用apt update之后依然无法正常更新软件包仓库，这时候需要检查DNS解析服务是否正常启动
-
配置DNS解析地址
配置该地址之前最好ping一下检查是否可以正常访问，不能的话更换国内DNS服务
sudo resolvectl dns ens3 8.8.8.8 1.1.1.1 -
持久化
关于DNS解析地址的持久化有很多种解决方案，可以修改
/etc/netplan路径下的yaml文件，也可以修改/etc/systemd路径下的resolved.conf文件，我这里采用第二种方案。-
首先需要检查resolved服务是否被正常启动,
active表示已经启动，没启动的话代表操作系统不是使用该服务提供DNS解析的，需要更换方案，yukikaze@yukikaze-qemu:/etc/apt$ systemctl status systemd-resolved ● systemd-resolved.service - Network Name ResolutionLoaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)Active: active (running) since Wed 2024-12-04 09:47:50 CST; 18min agoDocs: man:systemd-resolved.service(8)man:org.freedesktop.resolve1(5)https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managershttps://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients Main PID: 346 (systemd-resolve)Status: "Processing requests..."Tasks: 1 (limit: 2271)Memory: 9.8MCPU: 254msCGroup: /system.slice/systemd-resolved.service└─346 /lib/systemd/systemd-resolved12月 04 09:47:50 yukikaze-qemu systemd[1]: Starting Network Name Resolution... 12月 04 09:47:50 yukikaze-qemu systemd-resolved[346]: Positive Trust Anchors: 12月 04 09:47:50 yukikaze-qemu systemd-resolved[346]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237> 12月 04 09:47:50 yukikaze-qemu systemd-resolved[346]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.1> 12月 04 09:47:50 yukikaze-qemu systemd-resolved[346]: Using system hostname 'yukikaze-qemu'. 12月 04 09:47:50 yukikaze-qemu systemd[1]: Started Network Name Resolution. -
查看当前resolve服务的状态，可以看到并没有配置DNS解析
yukikaze@yukikaze-qemu:/etc/apt$ resolvectl status GlobalProtocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stubLink 2 (ens3) Current Scopes: noneProtocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported -
修改该服务的配置文件
/etc/systemd路径下的resolved.conf，添加两行DNS参数，多个DNS服务器ip地址之间通过空格隔开[Resolve] DNS=8.8.8.8 1.1.1.1 FallbackDNS=8.8.4.4 1.0.0.1之后该文件的内容如下：
yukikaze@yukikaze-qemu:/etc/systemd$ cat resolved.conf # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it under the # terms of the GNU Lesser General Public License as published by the Free # Software Foundation; either version 2.1 of the License, or (at your option) # any later version. # # Entries in this file show the compile time defaults. Local configuration # should be created by either modifying this file, or by creating "drop-ins" in # the resolved.conf.d/ subdirectory. The latter is generally recommended. # Defaults can be restored by simply deleting this file and all drop-ins. # # Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config. # # See resolved.conf(5) for details.[Resolve] # Some examples of DNS servers which may be used for DNS= and FallbackDNS=: # Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com # Google: 8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google # Quad9: 9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net DNS=8.8.8.8 1.1.1.1 FallbackDNS=8.8.4.4 1.0.0.1 #Domains= #DNSSEC=no #DNSOverTLS=no #MulticastDNS=no #LLMNR=no #Cache=no-negative #CacheFromLocalhost=no #DNSStubListener=yes #DNSStubListenerExtra= #ReadEtcHosts=yes #ResolveUnicastSingleLabel=no -
重启服务
sudo systemctl restart systemd-resolved查看服务状态
sudo systemctl status systemd-resolved.service查看服务的DNS配置情况
yukikaze@yukikaze-qemu:/etc/systemd$ resolvectl status GlobalProtocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupportedresolv.conf mode: stubDNS Servers: 8.8.8.8 1.1.1.1 Fallback DNS Servers: 8.8.4.4 1.0.0.1Link 2 (ens3) Current Scopes: DNSProtocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 8.8.8.8 1.1.1.1
-
以上
