In che modo il traffico di rete in avanti della VPN? (Livello 3)

Sto cercando alcune informazioni su come la VPN (Virtual Private Network) inoltra il traffico di rete attraverso il suo VPS (Virtual Private Server).

Fai un esempio di dove sei connesso a una VPN. Si effettua una richiesta a un sito Web, che quindi si fa strada verso lo stack di rete fino al Livello 3.

Abbiamo un pacchetto IP: ha le intestazioni, incluso l'indirizzo di destinazione e un payload.

Se si modifica l'indirizzo di destinazione del pacchetto IP con l'indirizzo IP del VPS, in che modo il server inoltra la richiesta all'indirizzo di destinazione originale?

L'unica cosa a cui riesco a pensare è che al Livello 3 (Livello IP), l'indirizzo di destinazione dell'intestazione viene modificato nell'indirizzo IP del VPS e quindi l'indirizzo di destinazione originale viene aggiunto al payload del pacchetto?

Questo non significa che la lunghezza del pacchetto e l'intestazione del checksum del pacchetto dovrebbero quindi essere ricalcolati e il pacchetto IP nuovamente modificato?

E quindi il VPS esegue il mapping inverso del pacchetto per assemblare ed effettuare la richiesta originale sul server.

Sembra che ci sia un tempo di latenza elevato associato ad esso?

Forse mi manca qualche aspetto tecnico di come funziona, qualcun altro può spiegarlo?

Prendiamo ad esempio GRE-Header (GRE è un protocollo utilizzato per realizzare VPN - non è spesso usato in quanto non è sicuro in alcun modo, ma il concetto con incapsulamento è quasi lo stesso in ogni connessione VPN (quindi anche con IPsec per esempio) ):

Come puoi vedere, il pacchetto originale viene incapsulato in un altro pacchetto IP.

Supponiamo che ci siano due reti / router (A e B, un router può essere un VPS) collegati tra loro tramite una VPN (da sito a sito).

Se un host sulla rete A desidera accedere a un server FTP sulla rete B, l'host nella rete A invierà un pacchetto, dove l'indirizzo di destinazione è l'indirizzo IP del server FTP e l'indirizzo di origine è proprio.

Quindi il pacchetto originale arriva al gateway VPN (probabilmente il suo router), che incapsula questo pacchetto originale in ad esempio un pacchetto IPv4 in cui l'indirizzo di destinazione è il gateway VPN (rete B) e l'indirizzo di origine è proprio. In questo modo, il pacchetto può viaggiare su Internet verso l'altro gateway VPN (rete B). Qui, il protocollo / intestazione originale o il tipo di pacchetto non ha importanza, poiché verrà incapsulato con un'intestazione IPv4 per viaggiare su Internet e altri router non si preoccuperanno del protocollo / intestazione originale poiché vedono solo il "nuovo" Intestazione IPv4.

Deve essere calcolato un nuovo checksum per il "nuovo" pacchetto che viene aggiunto, altrimenti non sarebbe in grado di viaggiare su Internet (poiché ad esempio PPP viene talvolta utilizzato tra i punti in Internet, che calcola un checksum). Quindi devono esserci due checksum nell'intero pacchetto.

Con IPsec (che viene utilizzato quasi sempre per le connessioni VPN), il pacchetto originale viene crittografato (principalmente tramite AES) e viene aggiunta un'intestazione di testo semplice (la "nuova" intestazione per viaggiare su Internet). Deve essere in chiaro per poter essere instradato correttamente. Per questo, deve essere calcolato anche un nuovo checksum (poiché il checksum originale è crittografato).

Quando ha raggiunto l'altro gateway VPN (rete B), l'header VPN viene smontato e il pacchetto originale viene inviato nella rete (al server FTP).

Quindi la risposta breve alla tua domanda è l'incapsulamento. Ciò significa che esiste un altro set di intestazioni di pacchetti posizionate attorno al pacchetto che si sta inviando a un sito Web che viene rimosso dall'endpoint VPN.

Pensare in questo modo:

-----------------------------------------------
| src_ip=2.2.2.2, dest_ip=3.3.3.3             |
|---------------------------------------------|
|| src_ip=10.10.10.10, dest_ip=5.5.5.5       ||
|| Data goes here. This could be a HTTP GET  ||
|| or pretty much anything.                  ||
|---------------------------------------------|
-----------------------------------------------

Il tuo client VPN in esecuzione sul tuo computer locale ti fornirà un nuovo indirizzo IP (10.10.10.10) e cambierà la tabella del tuo percorso in modo tale che il percorso predefinito sia diretto verso il tunnel creato. Quindi invierà il traffico al server VPN o nell'esempio un VPS (3.3.3.3). Spesso al pacchetto verrà applicato un NAT quando viene de-incapsulato, quindi sul server di destinazione (5.5.5.5) sembrerà che il traffico provenga dall'IP di destinazione del traffico incapsulato (3.3.3.3) Ecco come il traffico ti ritorna prima andando al server VPN.

Alla tua terza domanda. Poiché stai inserendo un pacchetto aggiuntivo essenzialmente all'esterno della lunghezza e il checksum viene calcolato sul pacchetto risultante. Quindi sì, ci sono due lunghezze e due checksum. Per quanto riguarda la lunghezza massima che viene fatta dal VPS dicendo usa questo MTU o attraverso il rilevamento MTU come normale.

Per quanto riguarda la latenza. Non puoi rompere la fisica. Ti occuperai del sovraccarico di arrivare al VPS e di eseguirlo attraverso il suo stack di rete. Anche se può sembrare che ci sia un'alta latenza, a volte non è così. Se il VPS è topologicamente in linea con il punto in cui il pacchetto è già diretto, è possibile che venga aggiunto un overhead minimo. Ad esempio, se sei a Seattle e il tuo VPS è a New York e il sito web con cui stai cercando di parlare è a Londra. Ma se stai andando da Seattle a New York per tornare a un sito Web a Seattle, c'è ulteriore latenza dal viaggio attraverso gli Stati Uniti.

Un pacchetto viene creato dal livello di trasporto e passato al livello di rete. L'host cerca nella sua tabella di routing e lo invia all'interfaccia virtuale creata dal software VPN.

Il software VPN prende il pacchetto dall'interfaccia virtuale. Potrebbe crittografarlo o aggiungere le proprie intestazioni, quindi passarlo allo stack di rete come payload. A seconda dell'implementazione VPN specifica, può trasferire questo payload al livello di trasporto oppure può bypassare il livello di trasporto e passare direttamente al livello di rete.

Un altro livello di intestazioni di livello di rete viene quindi aggiunto al pacchetto indirizzato verso il server VPN. Il pacchetto viene quindi nuovamente consultato nella tabella di routing e inviato su Internet (se la VPN è una "copertura totale", il software VPN deve aver cura di impostare la tabella di routing in modo che il traffico VPN fuoriesca vera interfaccia rivolta a Internet piuttosto che tornare al software VPN).

Quando il pacchetto incapsulato arriva al server VPN, viene restituito al software VPN. Le intestazioni "esterne" vengono rimosse e il pacchetto viene passato allo stack di rete tramite un'interfaccia virtuale.

Dopodiché spetta allo stack di rete sul server VPN cosa fare con esso. Nel caso di una VPN utilizzata per l'accesso a Internet, lo stack di rete sul server VPN sarà probabilmente configurato per fungere da router NAT, quindi modifica l'origine del pacchetto e lo rimanda su Internet.

Quando la risposta ritorna più o meno, accade lo stesso processo. Il pacchetto arriva, il processo NAT è invertito, è passato al software VPN tramite l'interfaccia virtuale, è incapsulato e rispedito al software VPN sul client che lo de-incapsula e lo passa allo stack di rete in modo che può essere inviato all'applicazione client.