The real question is what are you hoping to achieve/provide by tunneling?
Better for who? Who controls the devices? Are some of them running specific features such as VPN already?
As it stands this feels like a pretty open-ended question. I mean if you just wanted the client to be able to access services on the server, you could just do NAT with port forwarding and that would technically work with the least impact on performance and work required, but this also another can of worms.
Rather than getting deep into it I'm just going to make a few assumptions based on your original question format and provide some general info.
You seem to be asking specifically about the client-side of the tunnel, and the wording suggests that node1 is settled as the server-side. I'm assuming you already have some it set up as a VPN gateway.
If the client is only node4, then you could handle this one of a 2 main ways:
If the tunnel endpoint is node4, this is equivalent to a remote access VPN, in which the tunnel goes directly between node4 & node1; nodes 3 & 2 and anyone else inbetween will have no idea about the nature of the communications over the tunnel, but anything between node1 and node0 may since the tunnel will have ended by then and communications may now be in cleartext.
You will likely need rules/configuration on node1 to accept the connection and define allowed services, as well as a VPN client software & associated configuration to bring up the tunnel. This also means some amount of processing power will be need to be maintaining the VPN tunnel at both nodes 1 & 4. (generally not a big deal in this day and age, but noteworthy).
If you do it with an SSL/TLS VPN, then maybe you may be able to bypass the VPN client software requirement, but you'll also need a certificate(s).
If the tunnel endpoint is node3, then this is akin to a site-to-site VPN. Assuming node2 is a firewall or something capable & already has VPN services running, this would be pretty easy to do. Some amount of processing power would be dedicated towards the tunnel, and you would need rules at both ends defining which client(s) can use the tunnel.
In both cases you would likely also still need rules on node 2 to allow the tunnel connection through to node1, unless there is already a blanket rule for 0.0.0.0/0 --> node1:VPN
Scalability is something to consider as well - for example if you go with the first scenario and then later on a node 5 pops up at 10.1.1.3 who also wants to access the server, now you need to install client software on node 5 too, and it will have its own tunnel to node 1 that it uses to access the server. In the second scenario all you would need to do is modify the existing rules at nodes 3 & 1 to also allow node 5 to use the tunnel, and the number of tunnels would remain at 1 instead of increasing for the number of nodes. By virtue of being a tunnel endpoint, node 3 would also be able to provide features like traffic inspection, antivirus, IDS/IPS, etc. if that's something that's being used.
If the concern is purely security of the channel between client & server, then obviously having the tunnel go directly between node4 and node0 would be "best", but that's more complicated to set up and now any protections against malware/intrusions/etc. would have to be done on the individual hosts.
There's a lot of points to consider specific to the actual scenario/use case to be able to make the "best" decision,