I stopped using the word "upgrade" in reference to Apple's updates a long time ago.
IME kernel extensions (kexts) were definitely related to various kernel panics that I've seen in the past.
In most cases, alternative APIs have been present for quite some time, it's just that some software hasn't been upgraded yet. Deprecation started a few years ago, so it's nothing surprising really.
Similar VPN and virtualization apps work without kexts, so I assume both Tunnelblick and VirtualBox could be rewritten to take the leverage of the new APIs.
At that point just use an iPhone/iPad. The whole point of OSX is that you have enough control over the machine that you can be productive.
I think we are getting close to swapping the machine roles here to have to most utility. Linux on metal and macOS in kvm for when you want to use an appstore app.
The 'tun' (tunnel) interface is user accessible, because it's creating a layer 3 packet/datagram, and programs are expected to need to be able to write these to do their job (web browsers send packets to a web server; email clients send packets to a mail server, et cetera)
The 'tap' (like a viper's fang injecting venom) interface is not user accessible. It requires a privilege escalation to perform the operation of receiving all of the layer 2 frames on a network interface. This allows the software access to greater information, and allows the reception and introduction of broadcast traffic, snooping on frames destined for other stations, and allows for a more comprehensive managing of the local network.
It's been a very long time.
`tap` lets a user-space process send/receive Layer 2 Ethernet frames.
Ethernet is a layer below IP, so it doesn't care about IP addresses, in the same manner that Ethernet switches don't (it cares about MAC addresses instead).
If you want to do virtual switching, you'll use taps.
If you need to deal with a protocol that needs to use Ethernet broadcasts, like DHCP, you'll also use taps.
tap can be user accessible, it just needs to be part of a bridge (at least on Linux). The entire bridge consisting of one or more NICs will have an IP, and the individual interfaces of the bridge function like a switch.
I'd have much more sympathy if it was a cross-platform application or if they had to keep rewriting/refactoring code multiple times because Apple kept changing different APIs from under their feet. That's not the case. Their only platform is macOS and AFAIK this is the only meaningful API migration they are being forced to do in 11 years. I know we cannot demand anything from Open Source maintainers, but is it really too much to ask that if you're the maintainer of a very popular security related application, you either learn how to code for the platform you're targeting or you pass on the torch?
I just don't understand the obsession with clinging on to being the unwilling maintainer for something that you don't master when the option of passing on the torch is always there. Someone willing will always pick up something as important as an OpenVPN client for an extremely popular operating system.
On top of that utun devices seem to add weird 4 bytes of data to the front of layer 3 packets to indicate the protocol (which was also confusing and undocumented AFAICT)
