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.

A simple way to download all installed binary packages could the following command:

$ dpkg-query -f '${Package}=${Version}\n' -W | xargs -n 1 apt-get download

Similarly, to download all source packages you would use the following:

$ dpkg-query -f '${Package}=${Version}\n' -W | xargs -n 1 apt-get source --download-only

Both will populate the working directory.

Yes, your IP got classified as "dubious", not so much as a quality assessment of your posts, but automatically because you (or your software) made a spurious "HEAD /req_message HTTP/1.1" request, which is an unserviceable request. All unserviceable requests gain the dubious qualification, and the subsequent lockout from the server. (I shouldn't tell you when it happened to golinux, or myself even ).

Which program did you use?

If you don't know, then you probably haven't set any pin preferences.

You do know that the last image was 116 Mb, I suppose. Please use the text copied into the posts, rather. You can pipe output to file, or use script to get a typescript file.

Anyhow, I'm guesing your iptables (v1.6.1) is from ascii-backports; where's your kernel from?
Do you have the /lib/modules/$(uname -r) sub tree with kernel modules?
Specifically do you have /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko, which is the module concerned?

Isn't that just a matter of choosing which encryption algorithm(s) your server accepts? I.e., it's your choice, and a property of your running server; not a property of the software as such. And based on a rather superficial web search, I believe that the answer is "Yes": there is a sufficient number of algorithms to use to make your ssh service compliant.

I suppose you'll then need to arrange for running /sbin/getty 38400 tty7 in runlevel 3. For example, you add a line for this to /etc/inittab, to let init manage it:. E.g., the following as a line after the tty6 line might do the job:

7:3:respawn:/sbin/getty 38400 tty7