Devuan image in Qemu
(No. 0) No. 1 No. 2 No. 3 No. 4 No. 5 No. 6 No. 7 No. 8 No. 9 No. 10 No. 11 No. 12 No. 13 No. 14
For the reasons described in this thread on qemu-discuss mailing list, for days I wasn't able to connect to internet with my Qemu:
How to set the network card for qemu to use?,
I'll post on that thread as Aleksei suggests , just let me tell what progress I have made so far.
UPDATE: There's, 20 hours later, another, faster, successful booting of opennebula Devuan image, read further below.
In the first place, since I absolutely use grsecurity-hardened kernel (just remember not NSA Linux, ah I meant SELinux-hardened, but grsecurity-hardened), wouldn't go online without it on a system that I don't intend to throw away, I had to set some learning rules into my policy:
# Role: miro subject /usr/bin/qemu-system-x86_64 ol / h -CAP_ALL bind disabled connect disabled
---
( and one of my motives to step into these VM waters is Use Tor browser on grsecurity-hardened system? )
Now, the command I used in this (primitively) successful (I'm new at [V]irtual [M]achines generally) Qemu deployment:
qemu-system-x86_64 -display gtk -m 1024M \ devuan_jessie_1.0.0-beta_amd64_cloud.qcow2
My qemu install got (the default) pass-through network set up.
I used my (simple) uncenz program:
https://github.com/miroR/uncenz
That is, I plugged in to the router (I'm offline when I don't do things on internet), and started my uncenz.
The network trace, transparent as fresh mountain spring (no SSL), is in this cap-161015-qemu-devuan/ directory where you're at right now:
The screencast of how my
Devuan image:
devuan_jessie_1.0.0-beta_amd64_cloud.qcow2
booted is this one (but you had better use the links below, it's 15 minutes altogether, TL;DR ) :
These open in separate tabs/windows:
This is the pass-through network connection successfully set up (38 seconds):
Screen_161015_0457_g0n.webm#t=00:05:20,00:05:58
here I installed the links package from devuan repositories (1 min):
Screen_161015_0457_g0n.webm#t=00:12:37,00:13:44
and here I connected to my NGO's website (26 seconds):
Screen_161015_0457_g0n.webm#t=00:13:52,00:14:18
---
UPDATE: 20 hours later, a more successful try is here. This is 5 minutes 36 seconds, it's actually fast booting, but it stops unable to connect to the cloud at 10.0.2.2, for which pls. see the trace): dump_161015_2050_g0n.pcap (so you need to only see the first some 30 seconds, realize how it stalls there, and go to just about 4:00 and there's 1minute 36 seconds to end then).
The command I used worked thanks to Aleksei's advice:
qemu-system-x86_64 -machine type=q35,accel=kvm -enable-kvm \ -cpu host -display gtk -m 1024M \ devuan_jessie_1.0.0-beta_amd64_cloud.qcow2
I'll also try and ask on Devuan mailing list about the stalling for 10.0.2.2 (won't necessarily update about it here, find it in the archives there).
---
As I promised, I went back to what the title of the thread on Qemu says, Aleksei's first advice.
First I thought it will work, and wrote this message.
This is the command that I used and it also includes the second suggestion by Aleksei):
qemu-system-x86_64 -machine type=q35,accel=kvm -enable-kvm -cpu host \ -display gtk -m 1024M -device virtio-net,netdev=internet -netdev \ bridge,br=br0,id=internet,helper=/usr/libexec/qemu-bridge-helper \ devuan_jessie_1.0.0-beta_amd64_cloud.qcow2
Unsuccessful, and only in the screencast it can be seen it doesn't work (well, I could probably tell from the dump_161016_0501_g0n.pcap analyzing the (fake, always fake, use macchanger program) by [analyzing the] MAC's):
---
The command that I used is the same as the previous posted uncenz set, just above):
The trace is sanitized for my password and some more dump_161016_1114_g0n.pcap with this command:
tshark -r dump_161016_1114_g0n.pcap -Y \ '!((ip.addr==192.168.1.1)&&(ip.addr==192.168.1.4))' \ -w dump_161016_1114_g0n_noZTE.pcap
and I renamed it:
mv -iv dump_161016_1114_g0n_noZTE.pcap dump_161016_1114_g0n.pcap
The screencast needed to be as precisely as possible sanitized, guess at which stretches and how? Well, forget the first, and as for how: with mkvmerge of Mkvtoolnix the cutting, and the finesse manipulation with FFmpeg of course (but out of time to give you the tips on that; elsewhere, some day):
---
It's not over yet for me, but the topic [Qemu-discuss] How to set the network card for qemu to use? can be considered done. As I say in the last messages of that thread as of the timestamps of the last uncenz set above, I only need to fix iptables policy for this Qemu setup, but that is a question that I need to search elsewhere for solution.
I solved it on my own. Can't give you the rules.sh that I run to create and save my iptables, but usually those rules include these lines (the $ipt being /sbin/iptables or whatever it is on your system):
echo " * Set default policies for INPUT FORWARD OUTPUT" $ipt -P INPUT DROP $ipt -P FORWARD DROP $ipt -P OUTPUT ACCEPT read FAKE
Right after those lines you need to, for an arrangement like mine, add:
echo " * allowing tap0 in" $ipt -A INPUT -m physdev --physdev-in tap0 -j LOG --log-level warning --log-prefix mrfw_tap0_in $ipt -A INPUT -m physdev --physdev-in tap0 -j ACCEPT read FAKE echo " * allowing tap0 out" $ipt -A INPUT -m physdev --physdev-out tap0 -j LOG --log-level warning --log-prefix mrfw_tap0_out $ipt -A INPUT -m physdev --physdev-out tap0 -j ACCEPT read FAKE echo " * allowing tap0 fwd in" $ipt -A FORWARD -m physdev --physdev-in tap0 --physdev-out eth1 -j LOG --log-level warning --log-prefix mrfw_tap0_fwd_in $ipt -A FORWARD -m physdev --physdev-in tap0 --physdev-out eth1 -j ACCEPT read FAKE echo " * allowing tap0 fwd out" $ipt -A FORWARD -m physdev --physdev-in eth1 --physdev-out tap0 -j LOG --log-level warning --log-prefix mrfw_tap0_fwd_out $ipt -A FORWARD -m physdev --physdev-in eth1 --physdev-out tap0 -j ACCEPT read FAKE
I found it at Building Bridges with Linux, and for my setup I needed to modify it like above. YMMV.
Ah, and you may need to recompile the kernel: CONFIG_NETFILTER_XT_MATCH_PHYSDEV=y (or m) is needed.
---
Qemu worked like a charm with Refracta CD:
The trace is sanitized for my password and username (all in one packet) and nothing more dump_161018_0245_g0n.pcap with this command:
tshark -r dump_161018_0245_g0n.pcap -Y '!(frame.number == 20985)' \ -w dump_161018_0245_g0n_NO_login-N.pcap
and you got:
mv -iv dump_161018_0245_g0n_NO_login-N.pcap dump_161018_0245_g0n.pcap
Unfortunately I'm not a wizard to edit and add a modified optimized build of Firefox to the packages of the new Refracta CD, to be able to log SSL keys upon connections... But it's this posting here refractasnapshot 10.0.0 (arrived) that is in the screencast (6 minutes 17sec):
---
And so my Qemu install with all the kernel necessities and other accessories can work fine!
And yet, there is no way for me to get Tails to do its work.
The trace is as was taken, non-modified in any way. I would need anywhere from days to weeks or even months of study to figure out from that trace (and the system logs, not included yet, but they seem to be telling...) why it doesn't work: dump_161018_0337_g0n.pcap.
Is it some trivial reason like it was with Devuan images? Or is it something more sinister, like ISP's blocking some traffic?
The network/internet they have very precise rules, and it is inexorably unforgiving, the lack of precise understanding of all the RFC's that set those particular rules: you can't get into it's secrets.
Open that up in Wireshark. You can also use the SSL keys for some non-related bits of conversation with a site that was open in my browser dump_161018_0337_g0n_SSLKEYLOGFILE.txt
Here is the screencast (3 minutes 47sec):
---
There is also another successful Refracta in Virtual Machine online browsing, but in a separate page (called that page 7th because it's the 7th video, however, there are no pages 1st to 6th), because I think I may need to discuss it with developers.
---
The files necessary for this study are listed in: ls-1 and verify to: ls-1.sum signed by: ls-1.sum.asc
