mmm ... all 192.168.x.0/24 (ethX) traffic should go out without ado due to the network route.

Remove the rule

iptables -A FORWARD -j REJECT

to see if it works without it.

Then add it back, preceded by rules that allow forwarding between tunX and tunY.

You might find something useful at https://www.syslinux.org/wiki/index.php?title=PXELINUX.

If I understand it right, the basic tenet against a published Troll Count is on the line that it's more likely to be (mis-) used by a bunch of dickheads banding together to wield dickheadary against some normal adult member, than that it's used by the normal adult members as (weak) indicator towards the censoring of a dickhead.

Well, perhaps. I'll leave my head where it is for the moment.

You got it right. There is no way you can find out who are ignoring you (short of bribing me to tell you, of course).

Perhaps one of you could spell out a way in which this might be abused, or rather I assume, a way in which this function can be used to abuse someone?

Is it that you think, that by X seeing an elevated troll count for Y, they (X) would be more inclined than otherwise to also nominate Y as troll? Or that Y would be unhappy seeing that so many members see them as a troll?

If Y is trolling in the eyes of some/many, then Y is trolling in the eyes of some/many, whether Y thinks so or not.
Without feedback, Y won't learn or change.

I think you're using the url tag back-to-front; it takes the actual url in the begin tag, and the description between the tags. So if you swap those, it becomes a click-accessible url. As is, one has to copy that url that is seen and paste to follow, rather than clicking it.

Yes, forget my nonsense about masquerading on the output chain, and check routing regarding the ethX network. In particular, the server-vpn return traffic must not be routed through the client-vpn.

Could it be that the outbound traffic through tunY needs NAT (i.e. a MASQUERADE rule)?

Yes, the iso files in https://files.devuan.org/devuan_ascii/desktop-live/ have SHA256 message digests as documented by the SHA256SUMS file in the same directory:

76584ce7183993306af8b00edc8ffce3a1dc69b10f0a97e0a6302d49b0a63858  devuan_ascii_2.0.0_amd64_desktop-live.iso
8f535c235897303a5d55266858ffe9fe6c4d3e830f609c77c406f6e4aed0befa  devuan_ascii_2.0.0_i386_desktop-live.iso

If you get something else, then the downloaded iso has got corrupted, and it's then a good idea to download anew, possibly from an alternative source.

Well, if things work as is, then you may well leave it at that.

Otherwise, the one thing I could pick up was the missing broadcast address in wicd-wired-settings.conf, which might make a difference; perhaps it causes the networking stack to fail in its ARP. You should probably assign that to 192.168.0.255 or whatever is correct for your subnet.

And otherwise^2, I think the "proper" way to avoid wicd managing eth0 would be to avoid the wired_interface = eth0 assignment in wicd-manager-settings.conf, and instead make that wired_interface = (or remove it, perhaps). For myself, I use wicd-curses rather than editing the configuration files directly.

In general, and as you probably know, the interfaces file is used by the ifupdown network management system, whereas wired-settings.conf is used by the wicd network management system. The former is more passive, and only operates on interfaces as explicitly commanded, e.g. # ifup eth0.

wicd is actively managing the interfaces it is told to manage; it's a daemon program that discovers changes to interface status and acts on these. Especially, if you have told wicd to manage eth0 it will do so, but if you haven't, it won't. I think wicd by default will configure itself to manage eth0 upon installation, but it's certainly the first thing to confirm.

If wicd is set to manage eth0, then it will do so according to wired-settings.conf. There's barely any magic involved at all, though in some cases mis-behaviour would be due to some bug rather than configuration mistakes. So let's see yours.