A tunnel is really just encapsulation of packets within other packets. The outer packets still need to be able to be routed normally to the address of the tunnel source (different than the tunnel address itself. The packets carried inside the outer packets see the tunnel as a single link, but the outer packets may need to be routed over many hops, especially if routed over the public Internet (which requires public addresses for the outer packets). The tunnel source must be able to send traffic that gets routed to the other tunnel source normally.
If you have a tunnel source inside a private network, then you cannot use that over the public Internet because you cannot route packets with private addresses over the public Internet. That is why the tunnel source addresses are usually the public WAN addresses of sites. If both your tunnel endpoints are within the same private network, then you could put the tunnel endpoints on any of the devices, as long as the tunnel source can normally reach each other.
Over a tunnel, you can use routing protocols to let the router on the other end of the tunnel know about any networks at the site, so it doesn't really matter how many networks are on each side of the tunnel. A tunnel is really just like connecting the two sites with a cable because it sets up a single link.
There are different tunnel types, and some cannot carry broadcast/multicast traffic, so some routing protocols or multicast routing may not work over that tunnel type. You could use a GRE tunnel inside that type of tunnel to overcome this, or use a different tunnel type that supports the features you need to support. Another possibility is to use static routes between the sites, but that doesn't scale, and it is not dynamic the way routing protocols are.
You could also have a problem if the private addressing at each of the two sites is using the same private addressing ranges. You may need to use NAT to overcome that.