towerful

I think 1 big advantage is that rathole can work over a websocket connection.
So, if obfiscating, having to go via HTTP proxies, or whatever... rathole will still work.

Hmm, fair.
I liked it cause i could dockerise it next to nginx and do SNI forwarding.
It had obvious and declarative config, which helped me get a redundant tunnel set up. Its great at auto-reconnecting.
I have never used ssh tunnels. Maybe its just as easy as using rathole. Learning ssh tunnels might have been a better path for me.
But rathole clicked, has been rock solid with 0 tinkering or tweaking, the config files make sense, its easy to in a docker container...

So, i cant really answer your question.

I can recommend rathole ( https://github.com/rapiz1/rathole ).
All it does is port forwarding. Easy to configure, easy to reason about, easy to dockerise.
If you need reverse proxying, you have to set that up either on the public server, or on local infra (chances are, you already have reverse proxy locally so rathole just needs to forward 80/443).

If its only for personal access (ie, you dont want services actually accessible by the internet) i can recommend tailscale for that. Its an auto-configuring wireguard VPN whose main selling point is NAT traversal. Very easy to set up, and very reliable.

Ive used cloudns for ages. They allow this

Decent DNS providers allow you to create NS records for subdomains.
This delegates the subdomain and all of its subdomains to another DNS.

Useful for companies that want to control their own records, but might want to allow a group of developers control over app.example.com and all subdomains, without the developers having to pester the company for record updates.

Also used for acme-dns, which is a self hosted DNS designed to only deal with txt records for acme DNS challenges (ie lets encrypt).
Means you can limit the possible disaster of the DN API keys being leaked (an attacker can only generate TXT records, instead of rewriting all your DNS records)

For example, I'm personally of the opinion ...

Are you replying to the correct person?

I like that its really simple and obvious, with a good confif file structure.
Server forwards a port to a client.
Client forwards that to an ip:port.

If you need to know the real IP, its up to you to run reverse-proxies that support PROXY TCP headers or insert x-forward-for, or whatever.
Rathole does its thing, only its thing, and does it well.

I use rathole https://github.com/rapiz1/rathole
Its been solid.

All ill say is ROS script is a huge PITA.
So, making a script that takes an object of vlan/port assignments, and running the required commands to ensure the config of the mikrotik matches the declared vlan/port assignments.

The besy way ive seen to build/manage them is to use a compile step to go from some sane declarative config in order to build the actual ROS script to make the changes.
I just havent got round to making that a thing.

I hope they are working on a native python API, so i can script in a sane language, and run it directly on the mikrotik.

Config files are easy to import/export/edit/read, tho.
It does mean you have to reset to default when you update a config file (or configure the device live, then export the config)

On a different note, i wouldnt be able to sleep with my feet sticking out.
Those douvets are so short

I guess "no" implies "this is your only chance to permanently decide".
"Remind me later" is obviously going to be an annoying reminder.
"Maybe later" or "Not now" indicates it can be changed later, but might also come with annoying reminders.

steps vs stepCount

God, this fucking API is untennable. Im out!