配置QEMU（Guest Debian-9.0 Sparc64 - Host MacOS High Sierra）从guest到host执行ssh-Java 学习之路

首先，使用 QEMU Virtual Machine (Debian Sparc64 Etch 4.0) ，我已成功地从Guest到Host（ MacOS Hight Sierra OS 10.13.3 ）获取 ssh 和 scp 命令 .

我只想在来宾和主机之间传输文件 .

为了得到它，我跟着这个tutorial：

1）我已安装 TUN/TAP drivers

2）像这样启动QEMU：

qemu-system-sparc -boot c -hda debian_etch.img -m 512M -net nic -net tap,script=no,downscript=no

3）VM启动后，在MacOS主机上执行： ifconfig tap0 192.168.10.1

4）在Debian Etch主机上，进入 /etc/network/interfaces ：

auto eth0
iface eth0 inet static
address 192.168.10.2
netmask 255.255.255.0
gateway 192.168.10.1

并做： /etc/init.d/networking restart

5）最后，请客人： $ scp -r dir user_host@192.168.10.1:~/

Now, I would like to get the same thing with a "Debian Sparc64 Stretch 9.0" guest.

似乎 ifconfig 已被最近版本的Debian弃用 .

无论如何，我尝试使用以下命令启动Sparc64映像：

qemu-system-sparc64 \
-drive file=debian-9.0-sparc64.qcow2,if=none,id=drive-ide0-0-1,format=qcow2,cache=none \
-m 1024 \
-boot c \
-net nic \
-net tap,ifname=tap0,script=no,downscript=no \
-nographic

并再次执行步骤1），3），4）但不幸的是，来自客户的 ssh 和 scp 不起作用 .

我必须注意到，对于这个 Debian Sparc64 9.0 来宾，网络逻辑名称正在改变（可能是每次启动） . 例如， /etc/network/interfaces 包含：

auto enp0s5
allow-hotplug enp0s5
iface enp0s5 inet static
address 192.168.10.2
netmask 255.255.255.0
gateway 192.168.10.1

最后，我从客人那里得到以下结果：

# ssh user_host@192.168.10.1
  ssh: connect to host 192.168.10.1 port 22: No route to host

ip a 给出：

# ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.2/24 brd 192.168.10.255 scope global enp0s5
       valid_lft forever preferred_lft forever
    inet6 fec0::5054:ff:fe12:3456/64 scope site mngtmpaddr dynamic 
       valid_lft 86207sec preferred_lft 14207sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever

如果有人可以给我一些线索来解决它并获得 ssh/scp 命令从客户端到主机工作（我没有网络访客和没有 sshd server ，所以我只想 guest-->host 方向 ssh/scp ） .

UPDATE 1:

我继续调试这个问题 .

1）首先，从this link，我在每次启动时重命名guest "Debian 9.0 Sparc64" 的网络接口为 eth0 ：

vi /etc/udev/rules.d/10-network.rules

   SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="52:54:00:12:34:56", NAME="eth0"

与 MAC adress 给出：

$ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.2/24 brd 192.168.10.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever

2）我在主机MacOS High Sierra的TAP接口上使用 tcpdump ：

# tcpdump -vv -i tap0
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:23:06.112155 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:06.112228 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:07.128440 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:07.128499 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:08.152323 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:08.152381 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:11.119346 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:11.119396 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:12.120190 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:12.120250 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:13.145028 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:13.145075 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:16.127525 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:16.127575 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:17.145202 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:17.145272 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28

我应该断定客人（ 192.168.10.2 在客人 /etc/network/interfaces 上）和主持人（ 192.168.10.1 由 ifconfig tap0 192.168.10.1 设置）正在进行通信，因为我看到两个地址都在 tcpdump 之上？

如果我在guest上重新启动networkin时在主机上执行 tcpdump -vv -i tap0 ，我会得到：

00:27:07.648620 IP6 (hlim 1, next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:07.804644 IP6 (hlim 1, next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:08.569140 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) :: > ff02::1:ff12:3456: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::5054:ff:fe12:3456
      unknown option (14), length 8 (1): 
        0x0000:  3bd4 4c86 3dd6
00:27:08.612632 IP (tos 0x0, ttl 255, id 37381, offset 0, flags [none], proto UDP (17), length 118)
    192.168.10.1.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QU)? 6.5.4.3.2.1.e.f.f.f.0.0.4.5.0.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
00:27:09.592322 IP6 (hlim 1, next-header Options (0) payload length: 36) fe80::5054:ff:fe12:3456 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:09.592483 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::5054:ff:fe12:3456 > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 16
      source link-address option (1), length 8 (1): 52:54:00:12:34:56
        0x0000:  5254 0012 3456
00:27:09.616466 IP (tos 0x0, ttl 255, id 18614, offset 0, flags [none], proto UDP (17), length 118)
    192.168.10.1.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QM)? 6.5.4.3.2.1.e.f.f.f.0.0.4.5.0.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
00:27:09.976787 IP6 (hlim 1, next-header Options (0) payload length: 36) fe80::5054:ff:fe12:3456 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]

这些消息中是否有有用的信息，以便从客户端到主机获取ssh / scp？

最后， guest eth0 具有以下状态（ UNKNOWN ）是正常的：

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN

UPDATE 2: 我也尝试使用带有“ -net tap ”标志的 guestfwd 标志启动，如下所示：

qemu-system-sparc64 \
-boot c \
-hda debian-9.0-sparc64.qcow2 \
-net nic \
-net tap,ifname=tap0,script=no,downscript=no \
-net 'user,guestfwd=tcp::22-tcp::22' \
-m 1024 \
-nographic

但仍然没有从客户到主机的ssh访问 .

我不知道是否，进入 -net 'user,guestfwd=tcp::22-tcp::22' ，我必须以哪个顺序放置来宾和主机的IP以及每个用于它们的端口（我这里使用了 22 ）

如果有人可以给我一些关于“ guestfwd ”旗帜的准确性 .

UPDATE 3 :

最后，通过在MacOS主机（以root身份）上执行来解决此问题：

1）使用“ ifconfig bridge0 192.168.10.1 ”在 bridge0 上设置IP 190.168.10.1

2）使用以下命令启动Qemu：

qemu-system-sparc64 \
-boot c \
-hda debian-9.0-sparc64.qcow2 \
-device virtio-balloon \
-net nic,model=virtio,macaddr=52:54:00:12:34:56 \
-vga none \
-net tap,ifname=tap0,script=no,downscript=no \
-m 1024 \
-nographic

MAC地址 52:54:00:12:34:56 非常重要 .

3）启动Qemu后，将 tap0 接口添加到 bridge0 ： ifconfig bridge0 addm tap0

4）最后，从访客Debian Sparc64，我可以用（作为简单的用户或root）连接到MacOS主机：

ssh user_host@192.168.10.1

1 回答

0

一些评论：

是的， ifconfig 已被弃用，但据我所知，至少已有六年左右的时间，而且它仍然在这里......这有其原因 . 我认为你可以毫无良心地使用它 .

关于你的 tcpdump 摘录：你觉得它包含有用的信息是正确的 . 但是，它不显示来宾和主机之间的真实通信，但它显示了 ARP 个查询 . ARP 是地址解析协议，因以下原因需要：

基本上，只要 TCP/IP 堆叠在 Ethernet 之上，计算机（无论它们是否是虚拟的）都需要知道其通信伙伴的以太网硬件地址（ MAC （媒体访问控制）地址） .

因此，如果具有IP地址a.a.a.a的计算机A想要与具有IP地址b.b.b.b的计算机B通信，则A需要首先知道B的 MAC 地址 . 因此，A将以太网广播帧发送到本地以太网段（基本上，广播帧是连接到相应段的所有机器的帧），询问：“我需要与具有IP地址bbbb的人交谈 . 你们中的任何人都有这个IP地址，你的以太网MAC地址是什么？“

您的 tcpdump 摘录显示此 ARP 分辨率失败 . 你的客人一遍又一遍地问，没有得到答案 . 只要是这种情况，guest虚拟机就无法与主机进行任何TCP / IP通信 .

所以你的问题只与SCP / SSH无关，而是与IP协议有关 . 例如，访客将无法显示位于该网站上的网站主办 .

此外，由于主持人不想发送答案，任何其他客人都会遇到同样的问题 . 我强烈认为你的旧debian etch 会以同样的方式失败，如果你以完全相同的方式启动它的VM，并且在完全相同的主机上，配置与具有新debian stretch 的VM完全相同 .

当然，来自guest虚拟机的ARP请求首先进入将无法应答来宾VM _3038559的ARP请求的网桥 . 这个问题通常通过以下方式解决：

在主机上，从物理网络接口取出IP地址并将其分配给网桥 . 然后桥接器回答客户的ARP查询 . 但这还没有让你到任何地方，因为现在你不能再使用主机的物理网络接口（你已经拿走了它的IP地址） .

因此，您还将主机的物理网络接口连接到网桥 . 通常，这是静态配置，即在启动VM时不会动态完成 . 这意味着主机上的操作系统配置为创建网桥，并在启动时将其物理网络接口添加到网桥 . 相比之下，客人的TAP会在客人启动时动态添加到桥上，并在客人关闭时从桥上移除 .

动态添加和删除guest虚拟机' TAPs to the host' s桥通常由 upscript 和 downscript 参数完成，您将为 -tap ... 配置选项提供这些参数 . 显然，您是手动执行此操作（更新3的第3项） .

To summarize, 你的问题是主持人没有回答客人的 ARP 查询 . 发生这种情况是因为这些查询到达了VM查询所要求的桥接器 .

回复于 2024-04-19T17:38:20+08:00

配置QEMU（Guest Debian-9.0 Sparc64 - Host MacOS High Sierra）从guest到host执行ssh

1 回答

相关问题