My comments may have been terse and vague because the reasoning behind this subject depends on an understanding of networking concepts as well as how VPNs behave. So here's the long version.
The innermost IP header is my publicly routable IP address that has been encapsulated. The outermost IP header is what is used for routing purposes.
False (you can confirm this with Wireshark). This simply won't work, and we'll see why later.
When you start up a VPN client or server, a special interface is added to your system. On a *nix system, this will typically be called
tun0 (assuming a TUN VPN, and where additional TUN devices follow the scheme
tunN). This special interface is used for communicating over the VPN, and by default (for OpenVPN) is assigned addresses in the
10.8.0.0/8 range. For public, "privacy-providing" VPNs, they will also typically set your computer's default route to use the OpenVPN server on this interface, which is also in
10.8.0.0/8. If this is the case, all of your outbound traffic will have a source address in
10.8.0.0/8 and will be sent to the
tun0 interface. The VPN client will then send the encapsulated traffic over your regular network interface to the VPN server.
This is what both IP headers would look like for a theoretical packet:
Outer Header: SRC=<YOUR_PUBLIC_IP> DST=<VPN_SERVER_IP>
Inner Header: SRC=<YOUR_VPN_CLIENT_IP> DST=<WHATEVER_YOU_ARE_ACCESSING>
The VPN server acts as a router. Once it receives your packet, it will route it depending on its destination address and the server's routing table. If this VPN serves a corporate network and static routes already exist on other routers back to the VPN range, the work is done here.
However, in the case of a public "privacy-providing" VPN, an RFC 1918 source address such as
10.8.0.0/8 cannot be routed back to across the internet, and thus can not be preserved all the way to the destination server. Instead, the VPN server or another router in their network must perform source NAT to rewrite the source address with the VPN provider's public IP address, so that the return traffic will come back to them. A connection tracking table records the original source address and port so that it will make it back to your client machine through the VPN.
While that was long and convoluted, it means that the answer to the following is "no".
This means that the actual identity of the source is never concealed
from the end device. Is that right?
When in doubt with these sorts of things, I highly suggest opening up a tool (e.g. Wireshark) to see how things are actually working.