A bit of explanation on the USB virtual ethernet may help…
When the micro-B USB cable is used on the port the Nano looks like a device to the other side of the cable, and not a host (Nano is not wired to be a host on that port; the other Jetsons can work with either a type-B or a type-A cable and switch modes). Those scripts set up the “device” to appear to be a network device, and the host PC does not know this is a Nano. The host PC thinks this is a USB network/ethernet device.
The scripts also set up a DHCP server on the Nano. If the host PC sees the ethernet device, and then (by default) sends a DHCP query to get an address, then the Nano’s DHCP tells the PC to use address “192.168.55.1”“192.168.55.100”, with a netmask of “255.255.255.0”. The Nano side is scripted to always use “192.168.55.100”“192.168.55.1” on the Nano. So the host PC is more or less not allowed to tell the adapter what to set up as. If your host PC can “ping 192.168.55.1” or “ping 192.168.55.100”, then you know the host PC listened to the Nano’s DHCP response.
Any behavior which forwards traffic via the host PC to the outside world over another connection is up to the host PC. Unless a lot of scripting is rewritten to tell the Jetson to request an address/netmask/route combination, versus its current setting to assign that setup, then “forwarding” or “bridging” within Windows would be the only possibility to make it work. This is trivial in Linux, but as @mdegans mentions, this is not so easy in Windows (and I am the wrong guy to suggest how to do that).