Question

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

我只想在来宾和主持人之间传输文件。

为了得到它，我已经遵循了这个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:~/

现在，我想用＆＃34; Debian Sparc64 Stretch 9.0＆＃34;客。

似乎不推荐使用最新版本的Debian ifconfig。

无论如何，我试图用：

启动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命令从客户端到主机工作（我没有在Guest上联网而没有sshd server，所以我只想要方向{{ 1}} guest-->host}。

更新1：

我继续调试这个问题。

1）首先，从this link开始，我在每次启动时将访客ssh/scp的网络接口重命名为"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

2）我在主机MacOS High Sierra的TAP界面上使用了$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：

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）正在进行通信，因为我看到两个地址都有{{1上面？

如果我在guest上重新启动networkin时在主机上执行了ifconfig tap0 192.168.10.1，我会得到：

tcpdump

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

最后，为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 { }]）是否正常：

UNKNOWN

...

更新2 ：我还尝试使用guest eth0标记与＆＃34; eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN＆＃34;这样的旗帜：

guestfwd

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

我不知道在-net tap中，我必须按照哪个顺序放置来宾和主机的IP以及每个用户的端口（我在这里使用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对于两者而言）

如果有人可以给我一些关于＆＃34; -net 'user,guestfwd=tcp::22-tcp::22'＆＃34;标志。

更新3：

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

1）使用＆＃34; 22＆＃34;

在guestfwd上设置IP 190.168.10.1

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

bridge0

MAC地址ifconfig bridge0 192.168.10.1很重要。

3）启动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界面添加到52:54:00:12:34:56：tap0

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

bridge0

Answer 1

一些评论：

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

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

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

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

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

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

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

当然，来自guest虚拟机的ARP请求首先会到达guest虚拟机的TAP所连接的 bridge 。只要该网桥没有为访客请求分配的IP地址，就不会回答访客的ARP请求。这个问题通常通过以下方式解决：

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

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

通过您为stretch配置选项提供的upscript和downscript参数，动态添加和删除guest虚拟机的TAP到主机的网桥。显然，您是手动执行此操作（更新3的第3项）。

总结一下，您的问题是主持人没有回答来宾的-tap ...次查询。发生这种情况是因为这些查询到达了连接VM的TAP的桥接器，但是您没有为该桥接器分配IP地址（更准确地说，至少不是访客的ARP查询要求的IP地址）。 / p>

配置QEMU（Guest Debian-9.0 Sparc64 - Host MacOS High Sierra）从guest虚拟机到主机

1 个答案: