I don’t know how traceroute should help with ‘the routes’.

The command traceroute pings every hop from your system to the given destination. so you can see if the traffic goes though your VPN or not. But only for this particular host.

If we’ll assume an issue within the routes, a more proper command could be ip r

lupus@hope:~$ ip r
default via 192.168.xx.1 dev ens18
192.168.xx.0/24 dev ens18 proto kernel scope link src 192.168.xx.213

The default (alias for 0.0.0.0) is going to the router 192.168.xx.1 on interface ens18
The own subnet 192.168.xx.0/24 doesn’t need a router and can be addressed directly.

lupus@hope:~$ traceroute google.com
traceroute to google.com (142.250.186.110), 30 hops max, 60 byte packets
 1  myown.net (192.168.xx.1)  1.288 ms  1.506 ms  1.732 ms
 2  something-citynearby (yy.103.yy.123)  12.474 ms  12.457 ms  12.489 ms
 3  yy.103.yy.6 (yy.103.yy.6)  12.483 ms  12.499 ms  12.536 ms
 4  kel13.backbone.de (yy.178.yy.145)  12.871 ms  12.802 ms  12.539 ms
 5  ham8.backbone.de (yy.178.yy.233)  12.640 ms  12.657 ms  12.733 ms
[...]
13  142.250.214.191 (142.250.214.191)  14.318 ms  15.294 ms  15.496 ms
14  fra24s06-in-f14.1e100.net (142.250.186.110)  15.851 ms  13.015 ms  13.374 ms
lupus@hope:~$

The first part of the traceroute is important. How the package left your device and fly around to the provider.
My hopper (special entry point for ourside connection) is not behind my VPN. Else the route would have some internal addresses. and Maybe a 192.168.8.xxx address in the traceroute.

But be aware, that google (google.com (142.250.186.110)) is only take this route, because if the route (default via 192.168.xx.1 dev ens18), seen before. It could have gone another way, if there was another route at the device (192.168.xx.213) or the router (192.168.xx.1)