Yes, VPN or simply have a daemon run autossh to establish a reverse tunnel up to a bastion host that you can then ssh down. Either should work.
We also found that our mobile data modem would on rare occasions get stuck, so there’s s watchdog process that watches for closed loop connectivity and will eventually power cycle the modem via a USB power switch chip (originally it rebooted the gateway computer, but it turns out that the modem’s stuckedness could survive that, so now it power cycles the modem but if stuck enough will also use the SoC’s hardware watchdog to reboot Linux in a way that bypasses Linux’s occasional ability to get stuck trying but failing to reboot)
How is it possible to troubleshoot the function of a class A LoRa-device? Since those devices are usually battery-powered and in sleep mode, it will probably not be possible to transmit to them or reset them. Has anyone come up with a work around for that already?
For an actual field deployed unit there’s not real way
But you can simulate that situation by connecting a node to a mains powered system you have remote access to - for example another raspberry pi. To test firmware at a distance from the gateway, I have a few such setups - the node’s serial log is collected and saved by the pi, and openocd configured to run on the pi’s GPIOs can be used to load new firmware into the node. A couple setups also have an integrating microamp current meter to measure node power consumption, which is different at long range than when close since the long range datarates require more airtime.