If your VPN implementation can work with those APIs, then I don’t think it is a high priority to replace the TLS part with something else.
Rustls is written 100% in the safe subset of Rust, designed from the start with modern security practices in mind. native-tls is over a million lines of legacy C code, with a thin layer of Rust on top. So, in some sense, whether to use Rustls vs native-tls depends on how much benefit you think using Rust has over using C, and how much benefit using modern security engineering practices have over what was done in the 90’s.
When you’re further along in your project, Rustls is also likely to be much easier to change to do things to protect against traffic analysis and other things that are especially important to a DPI-fighting VPN. In particular, let’s say you want the VPN traffic to look like modern web browser traffic. Then soon you’ll need a TLS 1.3 implementation that works on every platform your users use. native-tls won’t be able to do that, but Rustls can. But this is a longer-term thing.
It should be possible to change
tokio-tls so that (1) it can use Rustls when requested with a feature flag, and (2) it uses Rustls by default on platforms like Linux that don’t have a native TLS stack. This would be an amazing contribution to the community independently of a VPN stack. (I had thought that that was already done, but I may be confusing it with something else.)