Is it reasonable to say, any server that I request data from, regardless if I am behind tor, VPN, ect, can in fact, find my source IP contained within the header of the Datagram, and thus, know the true origin of the request.
No on IPv4. A virtual private network works by connecting, between you and the VPN provider, a tunnel such that you can route through a private network - one of the 10.0.0.0/8, 192.168.0.0/24 or 172.16.0.0/16 address spaces. This is why it is a "private network". The virtual bit comes from the fact you are actually routing over the public internet.
Your access to the internet is then "proxied" like a home router i.e. network address translation. Since there is no route to a private IP address, unlike a public one, the public facing router must take responsibility for both forwarding packets out to the internet and tracking where the replies should go to.
One way to do this is via source ports, but it is not the only way. In this case the source port of the packet and hence the port on which replies are received tells the router which private network host to send the packet to.
As such, you will "appear" to have the IP of the exit gateway of the VPN to servers that see your requests.
Tor circuits, simplified, are like the gateway process times 3. Each step knows who to send on to and who to return to, but not anything else, with each taking responsibility for routing. So, between you and the internet you have a tor entry server, a relay server and a tor exit node. The relay server for example knows to relay packets from the entry server to the exit node, but no more - it does not know the eventual destination of the packet which only the exit will know, or the source, which only the entry knows.
This is completely opposed to conventional routing, which on the public internet explcitly has a source and destination IP. Routers do not re-write this, instead they simply try to calculate the most efficient "next hop" (directly connected hardware to which they can send the packet). Multiple such steps happen in a typical internet communication (see traceroute) and since tor nodes are internet communications tor nodes packets will also hop over multiple nodes taking varied routes through the internet with known source and destination (which are crucially only the relays).
I've written a lot of text, so perhaps it's worth recapping with steps what happens to a packet in the VPN scenario. Let's say I'm sending a HTTP get request.
I connect to VPN. The process of doing this preserves my route for VPN traffic but otherwise creates a default route via the VPN gateway and makes me part of their private network. Examples from my VPN provider:
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.0.9.14 netmask 255.255.255.255 destination 10.0.9.13
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 48 bytes 23132 (22.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 55 bytes 12215 (11.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
$ ip -4 route
0.0.0.0/1 via 10.0.9.13 dev tun0
default via 10.0.0.1 dev wlp2s0 proto static metric 1024
10.0.0.0/16 dev wlp2s0 proto kernel scope link src 10.0.0.109
10.0.9.1 via 10.0.9.13 dev tun0
10.0.9.13 dev tun0 proto kernel scope link src 10.0.9.14
notareal.ip.200.165 via 10.0.0.1 dev wlp2s0
188.8.131.52/1 via 10.0.9.13 dev tun0
if you look at this carefully you'll notice some strangeness. The default route remeains in place but has its metric set high (low priority) whereas 0.0.0.0/1 and 184.108.40.206/1 - comprising all IPv4 except the notareal.ip line - are sent via tun0. That line exists so that VPN traffic can still go via the proper original interface.
I craft a packet and send it. According to my above mentioned scheme, when I say I want to send this packet to stackexchange.com my routing table instructs me to forward it to the VPN gateway because that's the highest priority matching route.
- Internally, the VPN software does its crypto thing and writes a packet to the VPN gateway. This too is looked up in the routing table and goes via the actual network. It is unwrapped at the other end.
- At the other end, the packet hits the gateway and is NAT'd, or proxied, or whatever scheme your provider uses. They then leave for the public internet.
- When a reply comes in over an established TCP connection, the reverse process happens.
- UDP is connectionless anyway; inbound UDP and outside initiated TCP connections are not possible because there's no public routes to me.
In essence, this is quite like your home network NAT, except virtual.
I am using OpenVPN in this case; what you see if you try these steps depends on your provider, VPN software etc and are essentially the same.
Now to answer your question "do VPNs really mask your identity?" - well, there are a lot of ifs and buts and ummms to that, but here's the simplest breakdown I can think of:
- If you are an server operator and someone is using a VPN, it's unlikely you'll be able to identify them. You'll see traffic from the VPN provider easily enough, but you won't know who it came from originally unless:
- You are a server operator with some kind of authentication mechanism or the ability to store persistent "tracking" cookies on the target. In the former case, you might even know who they are; in the latter case you know they are a unique individual and you won't know exactly who. However:
- The VPN provider sees all - the DNS requests you make, where your packets are going etc. In this sense they are now your ISP. Even if you paid them anonymously and gave them details to a completely segregated persona, they still know where your packets come from. The upshot of this is that there is a link to your true identity, or at least whoeever pays the internet bill.
Thus, if you give law enforcement sufficient motive, they'll find you easily enough.
IPv6 is an interesting area. I don't know many people who routinely route ipv6 over VPN mostly because the only person I can name with IPv6 connectivity is me... but, it can be done. IPv6 does not have the concept of private address spaces (slight lie, they do exist) as everything is supposed to be world-routable. Indeed some people believe that NAT breaks the original conceptual design of the internet as a single globally routable network.
Anyway, you can read more about it here - you get IPv6 routable blocks assigned to you instead of private ranges.
If you're wondering, though, publicly routable doesn't necessarily mean packets will be accepted, it just means they could be directed there. There can still be firewalls blocking all incoming connections.
Edit: as an interesting educational exercise, try listening for traffic with wireshark on the VPN interface (in my case tun0) versus the actual hardware interface :)