I miei commenti possono essere stati chiari e vaghi perché il ragionamento alla base di questo argomento dipende dalla comprensione dei concetti di rete e dal comportamento delle VPN. Quindi, ecco la versione lunga.
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 (puoi confermarlo con Wireshark). Questo semplicemente non funzionerà, e vedremo perché dopo.
Quando avvii un client o un server VPN, viene aggiunta un'interfaccia speciale al tuo sistema. Su un sistema * nix, questo verrà in genere chiamato tun0
(supponendo una VPN TUN e dove dispositivi TUN aggiuntivi seguono lo schema tunN
). Questa interfaccia speciale viene utilizzata per comunicare tramite la VPN e, per impostazione predefinita (per OpenVPN) vengono assegnati indirizzi nell'intervallo 10.8.0.0/8
. Per le VPN pubbliche, che forniscono la privacy, in genere vengono anche impostate la route predefinita del computer per utilizzare il server OpenVPN su questa interfaccia, anch'essa in 10.8.0.0/8
. In questo caso, tutto il traffico in uscita avrà un indirizzo di origine in 10.8.0.0/8
e verrà inviato all'interfaccia tun0
. Il client VPN invierà quindi il traffico incapsulato sulla normale interfaccia di rete al server VPN.
Questo è ciò che entrambi gli header IP dovrebbero avere per un pacchetto teorico:
Outer Header: SRC=<YOUR_PUBLIC_IP> DST=<VPN_SERVER_IP>
Inner Header: SRC=<YOUR_VPN_CLIENT_IP> DST=<WHATEVER_YOU_ARE_ACCESSING>
Il server VPN funge da router. Una volta ricevuto il pacchetto, lo instraderà in base al suo indirizzo di destinazione e alla tabella di routing del server. Se questa VPN serve una rete aziendale e le route statiche sono già presenti su altri router per tornare all'intervallo VPN, il lavoro viene svolto qui.
Tuttavia, nel caso di una VPN pubblica che fornisce la privacy, un indirizzo di origine RFC 1918 come 10.8.0.0/8
non può essere reindirizzato su Internet e quindi non può essere conservato fino al server di destinazione . Invece, il server VPN o un altro router nella loro rete devono eseguire il NAT sorgente per riscrivere l'indirizzo di origine con l'indirizzo IP pubblico del provider VPN, in modo che il traffico di ritorno torni a loro. Una tabella di tracciamento delle connessioni registra l'indirizzo e la porta di origine originali in modo che possa tornare al tuo computer client tramite VPN.
Mentre quello era lungo e contorto, significa che la risposta al seguente è "no".
This means that the actual identity of the source is never concealed
from the end device. Is that right?
In caso di dubbi su questo tipo di cose, consiglio vivamente di aprire uno strumento (ad esempio Wireshark) per vedere come stanno effettivamente funzionando.